FixedThreadPoolとCachedThreadPool：2つの悪の小さい方

たくさんのタスクを実行するスレッド（約5〜150）を生成するプログラムがあります。もともと、私が使用しFixedThreadPoolているため、この類似した質問は、彼らがより良い、より長い寿命のタスクに適した提案とマルチスレッドの私の非常に限られた知識で、私は、スレッド（数分）の平均寿命は「とみなさ長く住んでいました」。

ただし、最近、追加のスレッドを生成する機能を追加しました。これにより、設定したスレッド制限を超えてしまいます。この場合、許可できるスレッドの数を推測して増やすか、スレッドをCachedThreadPool無駄にしないように切り替える方が良いでしょうか？

両方試してみて、違いはないようですのでCachedThreadPool、ムダを避けるためだけに行きたいと思います。ただし、スレッドの寿命は、代わりにを選択FixedThreadPoolして未使用のスレッドを処理する必要があることを意味しますか？この質問では、これらの余分なスレッドが無駄になっていないように見えますが、明確にしていただければ幸いです。

CachedThreadPoolは、実行時間の長いスレッドに使用してもマイナスの影響がないため、状況に応じて使用する必要があります。CachedThreadPoolsが短いタスクに適していることに関するJavaドキュメントのコメントは、それらがそのような場合に特に適切であることを示唆しているだけであり、実行時間の長いタスクを伴うタスクに使用できない、または使用すべきではないということではありません。

さらに詳しく説明すると、Executors.newCachedThreadPoolとExecutors.newFixedThreadPoolは両方とも、パラメーターが異なるだけで、同じスレッドプールの実装（少なくともオープンなJDKでは）によってサポートされています。違いは、スレッドの最小値、最大値、スレッドキル時間、およびキュータイプだけです。

public static ExecutorService newFixedThreadPool(int nThreads) {
     return new ThreadPoolExecutor(nThreads, nThreads,
                                   0L, TimeUnit.MILLISECONDS,
                                   new LinkedBlockingQueue<Runnable>());
 }

public static ExecutorService newCachedThreadPool() {
    return new ThreadPoolExecutor(0, Integer.MAX_VALUE,
                                 60L, TimeUnit.SECONDS,
                                 new SynchronousQueue<Runnable>());
}

FixedThreadPoolは、実際に固定数のスレッドを操作する場合に利点があります。これは、指定したレベルでスレッド数が維持されることを認識しながら、任意の数のタスクをエグゼキューターサービスに送信できるためです。スレッド数を明示的に増やしたい場合は、これは適切な選択ではありません。

ただし、これは、CachedThreadPoolで発生する可能性がある1つの問題が、同時に実行されるスレッドの数を制限することに関することを意味します。CachedThreadPoolはそれらを制限しません。そのため、あまり多くのスレッドを実行しないように、独自のコードを作成する必要がある場合があります。これは、実際にはアプリケーションの設計と、タスクがエグゼキューターサービスにどのように送信されるかに依存します。

FixedThreadPoolとCachedThreadPoolは両方とも、負荷の高いアプリケーションでは悪です。

CachedThreadPool より危険です FixedThreadPool

アプリケーションの負荷が高く、レイテンシを短くする必要がある場合は、以下の欠点のため、両方のオプションを取り除く方が良い

1. タスクキューの無制限の性質：メモリ不足または高遅延が発生する可能性があります
2. 実行時間の長いスレッドはCachedThreadPool、スレッドの作成を制御できなくなります。

両方が悪であることを知っているので、小さな悪は良くありません。多くのパラメーターをきめ細かく制御できるThreadPoolExecutorを優先します。

1. より適切に制御できるように、タスクキューを境界キューとして設定します
2. 適切なRejectionHandler-JDKが提供する独自のRejectionHandlerまたはデフォルトのハンドラー
3. タスクの完了前/完了後に行う必要がある場合は、オーバーライドbeforeExecute(Thread, Runnable)してafterExecute(Runnable, Throwable)
4. スレッドのカスタマイズが必要な場合はThreadFactoryをオーバーライドします
5. 実行時にスレッドプールサイズを動的に制御する（関連するSEの質問：動的スレッドプール）

だから私はたくさんのタスクを実行するスレッド（〜5-150）を生成するプログラムを持っています。

選択したOSおよびハードウェアによってスレッドが実際にどのように処理されるかを理解していますか？JavaがスレッドをOSスレッドにマップする方法、スレッドがCPUスレッドにマップする方法など。1つのJRE内に150のスレッドを作成するのは、その下に大規模なCPUコア/スレッドがある場合にのみ意味があるため、たぶんそうではありません。使用しているOSとRAMによっては、nを超えるスレッドを作成すると、OOMエラーが原因でJREが終了する場合もあります。したがって、スレッドとそれらのスレッドによって実行する作業、実際に処理できる作業の数などを本当に区別する必要があります。

そして、それがCachedThreadPoolの問題です。これらのスレッドを処理できるCPUコアが2つしかないため、実際には実行できないスレッドで長時間実行されている作業をキューに入れるのは意味がありません。スケジュールされたスレッドが150になると、JavaとOS内で使用されるスケジューラがそれらを同時に処理するために、多くの不要なオーバーヘッドが発生する可能性があります。CPUコアが2つしかない場合、スレッドが常にI / Oなどを待機していない限り、これは単に不可能です。しかし、その場合でも、多くのスレッドが大量のI / Oを作成します...

そして、その問題は、たとえば2 + nスレッドで作成されたFixedThreadPoolでは発生しません。もちろん、nはかなり低い値です。そのハードウェアとOSリソースは、実行できないスレッドを管理するためのオーバーヘッドがはるかに少ないためです。