本質的に、私はすべての数値を大きな配列に合計するアルゴリズムをコーディングしています。各数値はパラメーターを受け取ります。そして、実行するパラメーターがたくさんあります。私にとって、すべての数値の合計は、Java で fork/join を活用する良い候補となり、エグゼキューター サービスの固定プールを使用して、異なるパラメーターを使用してアルゴリズムを効果的に実行できます。
しかし、これら2つを組み合わせる方法を知っている人はいますか? それとも、両方ともスレッド プールであり、同時に 2 つのプールを持つべきではないことを考慮して、それらを結合することは可能ですか?
どんな提案でも大歓迎です。
zhong.j.yuが言ったように、プールの数は、それらのプールで同時にアクティブなスレッドの数を合わせたものほど重要ではありません。
ForkJoinPoolは、名前が示すように、細分化/組み合わせスキームに適したタスクに最も適していRecursiveTaskます。これらは、配列値を合計するための最良の選択ではない場合があります。これは、キャッシュ/メモリが制限された種類のタスクのように聞こえます。
キャッシュスラッシングはある時点でパフォーマンスを制限するため、プロファイリングを行うか、少なくともスレッド数を実験する必要があります。
ForkJoinPoolは高度に最適化されており（クラスのコメントを確認してください）、ThreadPoolExecutorよりもはるかに優れていますが、メモリが制限されたジョブの場合、違いに気付くことはありません。
私の経験では、いずれかのプールに送信される各タスクは、最適なバランスをとるために少なくとも100µsかかる必要があります。多くの小さなジョブは最高のスレッド使用率を提供する可能性がありますが、ジョブキュー内のすべてのRunnableを処理するためのオーバーヘッドにコストがかかります。
1 つのプールを使用して、すべてのタスクをこのプールに送信できます。
主な問題は、プールに必要なスレッド数 (並列処理) です。デフォルト (N = プロセッサの数) から始めて、さまざまな並列処理でスループットをテストできます。私の推測では、ピーク スループットは N から 2N の間のどこかにあると思います。
Java 8 には、共通のプールもあります。
静的 commonPool() が利用可能で、ほとんどのアプリケーションに適しています。
FJP の良いところは、パフォーマンスが最適に近く、チューニングの影響を受けないことです (構成が妥当な範囲内にある限り、たとえば 10*N スレッドではありません)。