Java 5 の ThreadPoolExecutor に個別のコア サイズと最大プール サイズを指定するポイントを理解しようとしています。私の理解では、スレッドの数は、キューがいっぱいになったときにのみ増加しますが、これは少し遅れているようです (少なくともキューが大きい場合)。
より多くのスレッドをタスクに割り当てることができてよかったのではないでしょうか。その場合は、コア プールのサイズを増やすだけです。または、あまりそうしたくない場合は、キューを大きくする必要がありますか? 個別のコア サイズと最大プール サイズが役立つシナリオは何ですか?
これについてはここで議論されています。
プールは、corePoolSize の通常の負荷の下で動作するように意図されています (事前開始が使用されない限り、この値まで増加します)。過負荷状態が発生すると (ワーカーよりも多くの保留中/処理中のタスクがあることによって定義されます)、通常のワークロードが近い将来に復元されることを期待して、キューを使用してバッファーとして機能します。過度の過負荷が心配な場合は、制限付きキューを使用できます。これは、「キューがいっぱいになったら、ワーカーを maxPoolSize まで追加する」ことを意味します。無制限のキューを使用する場合、過剰な過負荷は予想されない (または気にしない) と言えます。
その目的は、一時的な過負荷下であっても、過剰なスレッドの作成や過度のスレッド チャーン (つまり、create-work-die-create) を発生させずに、予想されるワークロードを処理する能力のバランスを取ることです。
違いは、コア プール サイズを下回ると、プール内のアイドル スレッドに関係なく、新しいタスクごとに新しいスレッドが作成されることです。スレッドの数は、コア プール サイズに既に達しているが、まだ最大値を下回っている場合にキューがいっぱいになったときにのみ増加します。
これの完璧な例は、同時負荷がどれくらいあるのか正確にわからないシステム (Web サーバーなど) がある場合です。この関数を使用すると、おそらくマシンのコア数に基づいてスレッドのコア セットを指定できますが、予想よりも多くの負荷が許容されます。
これは、予想よりも多くの I/O 負荷があり、プール内のスレッドがブロックに多くの時間を費やしている場合に特に役立ちます。このシナリオでは、大きな同時負荷がなくてもキューが簡単にいっぱいになる可能性があります。いくつかの新しいスレッドを追加して、より多くの同時リクエストを処理することで簡単に修正できます。