invokeAllの引数（コレクション）はキューサイズに依存しますか？

Question

私が知る限り、呼び出し可能なスレッドのコレクションをinvokeAllに提出することができ、スレッドプールはすべてのタスク（任意の時点でスレッドプールサイズに等しいタスクを実行する）を実行します。

しかし、私はinvokeallを使用している間、キューのオーバーフローを本当に処理する必要がありますか？

Answer 1

すべては、お客様のコードとビジネス要件によって異なります。 javadoc for ThreadPoolExecutor状態キューへに関して以下の使用例：

直接ハンドオフ：

は、キューイングのための3つの一般的な戦略があります。 A 作業キューのデフォルトの選択肢は、 タスクをスレッドに他の方法で保持しないで渡すSynchronousQueueです。ここで、 を実行する試みがすぐに利用できない場合、タスクをキューに入れる試みが失敗し、新しいスレッドが構築されます。このポリシーは、内部で の依存関係を持つ可能性のある一連の要求を処理するときに、 ロックアップを回避します。直接のハンドオフでは、一般に、新しいサブミットされたタスクの拒否を避けるために、無制限の maximumPoolSizesが必要です。これは で、コマンド が処理可能な速度よりも平均的に速く到着し続ける場合、無限のスレッドが成長する可能性があることを認めています。

無制限のキュー。バインドされていないキュー（たとえば、事前定義された容量を持たない LinkedBlockingQueue）を使用すると、新しい タスクはすべてのcorePoolSizeスレッドがビジー状態のときにキュー内で待機します。 したがって、corePoolSize以上のスレッドは作成されません。したがって、 のmaximumPoolSizeの値は効果がありません。この は、各タスクが完全に他のタスクと独立している場合には適切です（ ）。例えば、ウェブ ページサーバ内にある。このタイプのキューイングは、 の要求の一時的なバーストをスムージングするのに役立ちますが、処理できる平均速度よりも速く平均で にコマンドが到着すると、 無制限の作業キューの増加の可能性があります。

制限付きキュー。バインドされた キュー（ArrayBlockingQueueなど）は、有限のmaximumPoolSizesとともに使用するとリソース が使い果たされるのを防ぐのに役立ちますが、チューニングと制御が難しい場合は になります。大きなキューと小さなプールを使用する は、CPU使用率、OSリソース、およびコンテキスト切り替えのオーバーヘッドを最小限に抑えますが、 は人為的に低いスループットにつながります。タスクが頻繁に をブロックする場合（たとえばI/O制限の場合）、システムは の時間を他の方法で許可するよりも多くのスレッドをスケジュールすることができます。小さなキューの使用 は、一般的に、より大きなプールサイズを必要とするため、CPUをより繁雑に保ちますが、 は受け入れられないスケジューリングオーバーヘッドに遭遇し、 スループットも低下します。