8

ThreadPoolExecutor のワークキューとして LinkedBlockingQueue を使用しています。問題は、境界のある LinkedBlockingQueue または無制限の LinkedBlockingQueue を使用することです。ThreadPoolExecutor の execute メソッドをオーバーライドし、コア プール サイズ後のスレッド作成の問題に直面しなくなりました。

したがって、LinkedBlockingQueue を制限付きと制限なしのどちらで使用するのがよいか教えてください。

ありがとう、トゥシャール

4

3 に答える 3

4

アンバウンド キューは、タスクが拒否されないようにするための安全な方法です。または、非常に大きな容量のバウンド キューを使用して、アプリケーションで受け取ることができるタスクの最大数を保持することができます。これは、アプリケーションの設計によって異なります。アプリケーションの設計を理解すれば (アーキテクトと話し合う)、キューのサイズを決めることができると思います。また、メモリと CPU については、タスクをキューに追加しない限り、それらは増加せず、制限なしまたは制限付きの両方で同じになります。(デモアプリケーションでテスト済み)

public static void main(String[] args)
{
   LinkedBlockingQueue<Runnable> r = new LinkedBlockingQueue<Runnable>(11);

  while(true)
  {
     //    r.offer(new Task(1));
  }
}

サイズをいじって確認してください。

于 2013-10-15T08:21:06.413 に答える
3

アンバウンドLinkedBlockingQueueは基本的に、容量が のバウンド キューですjava.lang.Integer.MAX_VALUE。はい、コメントで述べたように、制限を指定するかどうかに関係なくサイズチェックが行われるため、パフォーマンスではなく、ニーズに基づいて制限付きまたは制限なしのキューを使用してください。

いつものように、事前に容量がわかっている場合は、指定された容量の制限付きキューに対して制限なしキューの使用状況をプロファイリングすることをお勧めしますが、そのキューがパフォーマンスの問題を引き起こしているという証拠がない限り、そのルートを使用することはお勧めしません。応用。

于 2013-10-15T06:49:03.763 に答える
2

保留中のアイテムの最大数をキューに入れることができると見積もることができる場合は、バインドされたキューを使用することをお勧めします。キューに項目を挿入するスレッドは、推定されたキュー サイズの後にキューがいっぱいかどうかを知ることができます。

これはすべて、実行するタスクによって異なります。キュー内の保留中のアイテムの最大数の後に待機するアイテムをキューに挿入するスレッドを作成する場合は、バインドされたキューを検討する必要があります。

制限付きのキューは、メモリと CPU の点で優れています。最大でも制限付きの数のアイテムしかキューに入れることができ (メモリの利点)、キューがいっぱいになると、アイテムをキューに挿入するスレッドを待機させます (CPU の利点)。全体的なパフォーマンスが向上します。

これは、キュー内のキューイングのレートがデキューのレートと等しくない場合に大きな利点があります。

于 2013-10-15T06:32:11.107 に答える