最近、Java 7 の fork/join フレームワークについて知りました。私が学んだことは、それが分割統治のような問題に役立つ可能性があるということです。
私の質問は、フレームワークが別々の CPU でスレッドを実行することを保証するかどうかです。または、並行パッケージのクラスを使用して作成したスレッドに、サーバーで使用可能な別の CPU で実行するように指示することはできますか?
最近、Java 7 の fork/join フレームワークについて知りました。私が学んだことは、それが分割統治のような問題に役立つ可能性があるということです。
私の質問は、フレームワークが別々の CPU でスレッドを実行することを保証するかどうかです。または、並行パッケージのクラスを使用して作成したスレッドに、サーバーで使用可能な別の CPU で実行するように指示することはできますか?
これは、標準の JVM 同時実行プリミティブに基づいて構築されます。この場合、それらは (最終的に) 実際の OS スレッドにスケジュールされます。OS スケジューラーがスレッドを個別の CPU にスケジュールすることを保証することはできませんが、ほとんどの場合、そうなる可能性は非常に高くなります。
並行スケジューラが実行時に何をするかを推測しようとするのは、本当に悪い考えです。アクティブなスレッドと同じ数の CPU しか使用できないと仮定してください。特定の種類の非常に低レベルのことをしようとしている場合を除き、実行時の動作を推測しようとしないでください。最適化。
少なくともそれは最善を尽くします。fork/join フレームワークは、複数のプロセッサを利用するように設計されています。デフォルトでは、ForkJoinPool はプロセッサの数と等しい数のワーカー スレッドで作成されます。
フレームワークは、別々の CPU でスレッドを実行することを保証しますか?
いいえ、保証はありません。
または、並行パッケージのクラスを使用して作成したスレッドに、サーバーで使用可能な別の CPU で実行するように指示することはできますか?
標準 Java ライブラリを使用しない。理論的には、JVM のネイティブ レイヤーを掘り下げたいと思えば、何でも可能です (OS が許可する限界まで)。しかし、あなたは多くの不必要な仕事/苦痛に直面することになります.
私のアドバイス:
おそらく、そのレベルの制御は必要ありません。(IMO)ネイティブスレッドスケジューラのデフォルトの動作は、満足のいくパフォーマンスを達成するのに「十分」である可能性があります。
そのレベルの制御が本当に必要な場合は、別のプログラミング言語を使用する方がよいでしょう。つまり、ホスト OS のネイティブ スレッド スケジューラと直接対話できる場所です。別のオペレーティングシステムが必要になることさえあります...