私のアプリケーションでは、多くのネットワーク io バインド タスクを実行し、場合によっては 1 つの io バインド タスクを実行して、より小さな io バインド タスクに分割して問題を解決する必要があります。これらのタスクは現在、Java の標準スレッドプール メカニズムを使用して実行されています。フォーク アンド ジョイン フレームワークに移行できるかどうか疑問に思っています。しかし問題は、forkanandjoin フレームワークは通常、io バウンド操作または CPU バウンドの解決に使用されているのでしょうか? それらは主にCPUバウンド操作用であると思います.fork-and-joinフレームワークはワークスティーリング技術を利用してマルチコアプロセッサを利用しますが、IOバウンドタスクに使用すると悪影響はありますか?
5274 次
3 に答える
30
fork-join はコンピューティング バウンド タスク用に設計されているため、通常はノーと言います。Fork-join には API ( ManagedBlocker api) があり、FJ フレームワークに、スレッドがしばらくブロックされ、新しいタスクを整列させないことを伝えますが、これは実際には (ロックの取得などの) 短い待ち時間用に設計されており、恣意的な長さではありません。 IO を待ちます。
fork-join を使用するシステムがあり、IO にバインドされたタスクを別のエグゼキューター プールに振り分けます。データが到着すると、fork-join プールへのタスクがトリガーされ、CPU バウンドの作業のみがそこで発生します。
于 2011-11-21T02:01:47.597 に答える
2
問題の「I/Oバウンド」の側面に対処しようとしている場合、標準スレッドからフォークアンドジョインに切り替えることで状況が改善されるとは思えません...現在のスレッドベースのスレッドを実装していると仮定します適切に解決します。(そして、Alex Miller の回答に基づいて、スイッチは実際には事態を大幅に悪化させる可能性があります。)
別の言い方をすれば、I/O バウンドのアプリケーションを高速化する方法は、I/O バウンドの問題に対処すること、またはシステムの I/O 帯域幅を増やすことです。
于 2011-11-21T02:00:44.863 に答える
1
この場合、fork-join に説得力のある利点はないようです。
一部のリソースを過度に駆動しないため、重大な欠点もないようです。
全体として、他に重要な開発を行う必要がなくなるまで、スレッド プールにとどまります。
于 2011-11-21T02:07:28.697 に答える