1

ThreadPoolExecutor を指定して、従来のスレッド プールを Java に置き換えています。従来のスレッド プールでは、起動時に 600 百のスレッドが作成されます。しかし、ThreadPoolExecutor では、コア スレッド、最大スレッド数、および prestartAllCoreThreads() の概念を使用して、起動時のスレッド数を制限できます。

今、

  1. 実行中のスレッドが corePoolSize よりも少ない場合、Executor はキューに入れるよりも新しいスレッドを追加することを優先します。2 ) corePoolSize 以上のスレッドが実行されている場合、Executor は、新しいスレッドを追加するよりも、要求をキューに入れることを優先します。
  2. 要求をキューに入れることができない場合、これが maximumPoolSize を超えない限り、新しいスレッドが作成されます。この場合、タスクは拒否されます。

最初のシナリオは問題ありませんが、私が望むのは、コア スレッドが使用されているときに、タスクがキューに入れられ (制限されたキューの場合でも、サイズ 100 など)、コア スレッドがアイドル状態になるかキューがいっぱいになるのを待つことではなく、非コア プール クォータから新しいスレッドが作成されます。リアルタイムのように、私のアプリケーションはタスクがキューで待機しているという考えに耐えられません。

だから私が欲しいのは、CoreThreads -> Non-CoreThreads -> CoreThreads -> Queue -> Non-CoreThreads ではなく、CoreThreads -> Non-CoreThreads -> Queue です。

つまり、コア スレッドが使用されている場合は新しいスレッドを作成し、プール サイズが最大の場合は、タスクをキューに入れ、スレッドが解放されるのを待つ必要があります。

さて、これの 1 つの方法は、ThreadPoolExecutor クラスを拡張して execute メソッドをオーバーライドすることですが、その場合、クラス全体をほぼコピーする必要があります。これは私が考えることができる汚い方法です。誰でも他の方法を提案できますか。

注：スレッド数を制限する必要があるため、cachedThreadPool は使用できません。

4

1 に答える 1

3

ここでは、パッケージの問題をスレッド化するよりも、設計上の問題の方が多いと思います。

スレッド化を使用して、遅延を減らすか、スループットを向上させます。600 のスレッドを作成しているとすれば、これはサーバーのスループットを向上させるケースです。ただし、最新のサーバーには 600 個の CPU コアがないため、コンテキスト スイッチが発生して深刻な問題が発生します。一連のキューで作業するスレッドの数を固定する方が簡単で効率的です。

自分のケースが正当であると本当に思う場合は、独自のインターフェイスを作成して、標準のスレッド プールをラップし、別のスレッドで起動するためのカスタム ロジックを少し追加します。ただし、これがシステムのパフォーマンスを向上させるとは思えません。

基本的に、本当に正当化されない限り、新しいスレッドを作成することは、リアルタイム システムでキューに入れるよりも良い解決策だとは思いません。

于 2013-10-09T06:26:43.220 に答える