私はLinkedBlockingQueueをThreadPoolExecutorのワークキューとして使用しています。問題は、私は有界のLinkedBlockingQueueまたは無限のLinkedBlockingQueueを使用しなければなりません。私はThreadPoolExecutorのexecuteメソッドをオーバーライドしており、コアプールサイズの後にスレッド作成の問題に直面していません。どちらが良いですかLinkedBlockingQueue無制限またはLinkedBlockingQueue with容量
だから、LinkedBlockingQueueを有限または無限に使用する方がいいでしょうか教えてください。
おかげで、 Tushar
無制限のキューは、タスクが拒否されないようにするための安全な方法です。また、アプリケーションに入ってくるタスクの最大数を保持できるほど大きな容量の有界キューを使用することもできます。それはアプリケーションの設計によって異なります。私はあなたが（設計者と話し合う）アプリケーション設計を理解すれば、キューのサイズを決めることができると思います。また、メモリとCPUについては、タスクをキューに追加しない限り、増加することはありません。また、無限または境界の両方で同じになります。 （デモアプリケーションでテスト済み）
public static void main(String[] args)
{
LinkedBlockingQueue<Runnable> r = new LinkedBlockingQueue<Runnable>(11);
while(true)
{
// r.offer(new Task(1));
}
}
ちょうど調べるサイズで遊んでください。
あなたは保留中のアイテムの多くの最大数はキューに入れることができますどのように見積もることができる場合は、より良い有界キューを使用するようになります。キューにアイテムを挿入するスレッドは、キューの推定サイズの後にキューがいっぱいであるかどうかを知ることができます。
これはすべて実行するタスクによって異なります。待ち行列内のアイテムを挿入するスレッドをキュー内の保留中のアイテムの最大数の後に待機させる場合は、有界待ち行列を考慮する必要があります。
バインドされたキューは、最大限の数のアイテムがキューに入る（メモリの利点がある）だけであり、キューがいっぱいになるとキューにアイテムを挿入するスレッドを作成するため、メモリとCPUの点で優れています利益）。全体のパフォーマンスが改善されます。
これは、キュー内のキューイングのレートがデキューのレートと等しくない場合に大きな利点があります。
無制限のLinkedBlockingQueueは、基本的にはjava.lang.Integer.MAX_VALUEの容量を持つ制限キューです。したがって、コメントに記載されているように、制限を指定したかどうかにかかわらず、サイズチェックが行われるため、パフォーマンスにではなく、必要に応じてバインドされたキューまたは無制限のキューを使用します。
いつものように、容量を事前に知っていれば、キューが制限されているという証拠がない限り、そのルートに進まないことをお勧めしますが、アプリケーションのパフォーマンス上の問題。
あなたの答えが –
の場合は、関連するコードを投稿すると役に立つかもしれません。境界が必要な場合はboundを使用し、そうでない場合は無制限を使用してください。 あなたの意味は**より良い**ですか？どちらも1つのことですが、物事には限界があり、もう1つは無制限です！ あなたの質問を明確にしてください:) –
CPU使用率、メモリ使用量、スループット、つまり全体的な効率という点では、意味があります。 ポーリング操作とオファー操作の間に、バインドされたリンクブロッキングキューとバインドされていないリンクブロッキングキューのパフォーマンス統計が異なるかどうか。 – Scientist