通常のスレッドプールのような形で終わったものから新しいタスクを割り当てる、というものではない。各アクターに決まった番号のタスクを割り当てるような形になっている。main()実行結果は次の通り。各タスクが順番バラバラで実行されているのが分かる。19出力の最後を見て分かる通り、実行結果として得られる配列の順番は変わっていない。していく、という処理だからだ。いえ、最終的に得られる結果の順番が入れ替わらないという特性は並行処理をする上で優れた特徴だと思う。場合によっては終わったものから返ってきて、後からソートし直さないといけないことなんかもあるし。ラウンドロビンで処理するメッセージルータを実装してみる次は、お試しで作ってみたメッセージルータについて。これはほんとに試しに作ってみただけなのでプルーフオブコンセプトと思ってほしい。プロキシを複数生成して、処理を振り分ける。先ほどのべた書きのスレッドプールを、もうちょっと洗練させた感じ。メソッドに呼び出したいメソッド名と引数を指定するだけ。main()上記の実行結果は次の通り。タスクを処理したアクターの識別子も同時に出力するようになっている。つの周期で同じアクターによって処理されていることが分かる。上手く動作しているようだ。アクターモデルというのは、並行処理のプログラミングモデルの一つ。マルチスレッドやマルチプロセスよりも、抽象度の高い概念になっている。アクターモデルの概念を理解する上で重要なのは、アクターを構成する三つの要素を理解すること。一つ目がメッセージキュー、二つ目がメッセージハンドラ、三つ目がそれらをディスパッチするスレッド。生成されたアクターには、それぞれにこの三つの要素が必ず備わっている。メッセージキューとスレッドはあらかじめアクターごとに一つずつ生成されるし、メッセージハンドラは自分で定義する。アクターモデルでは、内部で競合を起こさないようにアクターの内外が非同期の壁で分断されている。アクターの内部に、外側から同期的に直接触れることはできない。同期的に触っているように見えたとしても、内部的には必ず経由している。アクターモデルで並行処理を実現するには、アクターを横にたくさん並べてタスクを割り当てていく。それぞれのタスクはアトミックに作られていないといけない。アクターモデルで競合が起こらないというのは、あくまで「低レイヤーで内部的には」という但し書きがつく。ロックがないからといって、デッドロックが起こらないというわけでもない。機能を全て揃えているわけではないので、割りとよく使いそうな機能でも自分で書く必要がある。使うというシチュエーションは、あまり無いのかもしれないと思った。使うにはあまりに低レイヤーすぎるからだ。ベースにした何らかのフレームワークをまず書いて、その上でアプリケーションを組むことになりそうな印象を受けた。未処理の例外が上がったときの処理をオーバーライドする注目記事スポンサードリンクスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。