私のアプリケーションでは、多くのnetwork-ioバウンドタスクといつかは1つのioバウンドタスクを実行して、問題を解決しなければなりません。これらのタスクは現在、Javaの標準スレッドプールメカニズムを使用して実行されています。私はfork-and-joinフレームワークに移行できるかどうか疑問に思っていますか？しかし、問題は、forkされたフレームワークは、通常、バインドされた操作やCPUバインドを解決するために使用されているということですか？私は彼らが主にCPUバインド操作のためであると仮定します。fork-and-joinフレームワークはマルチコアプロセッサを使用するために仕事を盗むテクニックを使用しますが、IOバインドされたタスクに使用すると悪影響がありますか？Javaのfork-and-joinスレッドプールはIOバインドタスクの実行に適していますか？
フォークジョインは、計算に基づくタスク用に設計されているため、一般的にはノーと言います。 Forkフレームワークには、スレッドがしばらくブロックされていて新しいタスクが並んでいないことをFJフレームワークに伝えるためのAPI（ManagedBlocker API）がありますが、実際にはロックを取得するなどの短い待ち時間のために設計されていますIOを待ちます。
フォークジョインを使用するシステムがあり、IOバインドされたタスクを別のエクゼキュータプールにシャントします。データが到着すると、タスクがfork-joinプールにトリガーされ、そこでCPUバインドされた作業だけが発生します。
問題の "I/O bound"の問題に対処しようとしている場合、標準スレッドからfork-and-joinに切り替えることは、ものを改善することになります...あなたが現在のスレッドベースのソリューションを適切に使用できます。
を（アレックス・ミラーの回答に基づいて、スイッチは実際に。物事が大幅に悪化させる可能性が）それとも別の言い方をするために、あなたのI/Oバウンドアプリケーションはより速く行くようにする方法は、I作る問題に対処することです/ O bound ...またはシステムのI/O帯域幅を増やします。
この場合、フォークジョインには魅力的な利点はないようです。
いくつかのリソースをあまりにも激しく動かすことはないので、どちらの面でも不利な点はないようです。
このスレッドプールは、他に重要な開発がない限り残っています。
「良い」とはどのような基準ですか？どのような種類のI/Oですか？ネットワーキング？ディスク？コンソール？ GUI？ fork-and-joinは本当に「スレッドプール」ですか？ – EJP
そのネットワーク接続タスク。 – Shamik
洞察力のある質問; upvoted – necromancer