私の知る限り、Akkaでは、すべてのアクターがスレッドのプールでスケジュールされています。ブロッキング IO を同時に実行するアクターが多すぎると、各ブロッキング呼び出しが 1 つのスレッドをブロックし、スレッドの停止につながります。
現在、私は JVM での興味深いファイバーの実装 ( Quasar ) を検討しています。これは、多くのユーザー スレッド (ファイバー) を許可し、スレッド プールを使用してそれらをスケジュールします。ただし、多くのファイバーが従来のブロッキング API を呼び出すことに利点があるかどうかは疑問です。
ブロッキング API は依然としてシステム スレッドをブロックし、Quasar はそれを魔法のようにファイバーのみをブロックするように変えることができなかったので、それは役に立たないと思います。あくまで私の推測ですので、間違っていたらご指摘ください。
クエーサー ファイバーは、ForkJoinPool.
おっしゃるとおり、Quasar は JDK/JVM スレッドをファイバーに「魔法のように」変換するわけではないため、現時点では、スレッド ブロック呼び出しはスレッド プール内のスレッドをブロックします (そして、それが発生した場合、Quasar は警告を出力します)。それが短時間でまれにしか発生しない場合、これは大きな問題ではありません。
運が良ければ、それは可能性が高く、ますます可能性が高まっています 、誰かがすでにスレッドブロッキングAPIの統合モジュールを作成し、それのファイバーブロッキング実装を提供しています。この場合、非効率的なスレッド ブロッキングから効率的なファイバー ブロッキングに切り替えるには、コードを少し変更するだけで済みます (もしあれば)。
それ以外の場合は、独自の運を構築し、自分で統合を作成できます。通常、これは非常に 簡単です。その場合は、Comsat に統合することを検討してください。