java - ThreadPoolExecutor のコア プール サイズと最大プール サイズ

Question

という観点から言うと、コア プール サイズと最大プール サイズの正確な違いは何ThreadPoolExecutorですか?
例を使って説明できますか？

Answer 1

ThreadPoolExecutorファクトリ クラスを使用する代わりに手動で作成することにした場合Executorsは、そのコンストラクタの 1 つを使用して作成および構成する必要があります。このクラスの最も広範なコンストラクターは次のとおりです。

public ThreadPoolExecutor(
    int corePoolSize,
    int maxPoolSize,
    long keepAlive,
    TimeUnit unit,
    BlockingQueue<Runnable> workQueue,
    RejectedExecutionHandler handler
);

ご覧のとおり、次のように構成できます。

• コア プール サイズ (スレッド プールが保持しようとするサイズ)。
• プールの最大サイズ。
• キープアライブ時間。アイドル状態のスレッドが破棄できるようになるまでの時間。
• 実行待ちのタスクを保持するワーク キュー。
• タスクの送信が拒否されたときに適用するポリシー。

キューに入れられるタスクの数を制限する

実行中の同時タスクの数を制限し、スレッド プールのサイズを調整することは、予測可能性と安定性の点で、アプリケーションとその実行環境にとって大きなメリットとなります。制限のないスレッドの作成は、最終的にランタイム リソースを使い果たし、結果としてアプリケーションが経験する可能性があります。 、アプリケーションの不安定性にさえつながる可能性のある深刻なパフォーマンスの問題。

これは、問題の一部に対する解決策です。実行されるタスクの数を制限していますが、送信して後で実行するためにキューに入れることができるジョブの数を制限していません。アプリケーションでは後でリソース不足が発生しますが、送信率が常に実行率を上回っている場合、最終的にはリソース不足になります。

この問題の解決策は次のとおりです。エグゼキュータにブロッキング キューを提供して、待機中のタスクを保持します。キューがいっぱいになった場合、送信されたタスクは「拒否」されます。はRejectedExecutionHandler、タスクの送信が拒否されたときに呼び出されます。そのため、前の項目で拒否された動詞が引用されています。独自の拒否ポリシーを実装するか、フレームワークによって提供される組み込みポリシーのいずれかを使用できます。

デフォルトの拒否ポリシーでは、executor がRejectedExecutionException. ただし、他の組み込みポリシーを使用すると、次のことができます。

• 黙ってジョブを破棄します。
• 最も古いジョブを破棄し、最後のジョブを再送信してみてください。
• 拒否されたタスクを呼び出し元のスレッドで実行します。