5

私はブログを読みましたが、彼の結論が正しいかどうかはわかりません :

http://www.javacodegeeks.com/2010/09/java-best-practices-queue-battle-and.html#ixzz1seaiSLwp

提供されたパフォーマンス結果からわかるように、LinkedBlockingQueue は (要素の追加と削除) を組み合わせた最高のパフォーマンス結果を達成しており、生産者と消費者のシナリオを実装するための一番の候補になるはずです。

私のコードで lock を使用しない方が速いのではないでしょうか?

では、なぜ LinkedBlockingQueue はロックフリー Queue(ConcurrentLinkedQueue) よりも速いのでしょうか?

ありがとう ！

4

3 に答える 3

4

ConcurrentLinkedQueue はブロッキングキューではありません。これは BlockingQueue インターフェイスを実装していないため、ブロッキング メソッド put() および take() を提供しません。これらのメソッドはプロデューサー/コンシューマーのセットアップに必要です。これは、消費するものが何もないときにコンシューマーがブロックするように調整し、コンシューマーが十分に迅速に消費しないときにプロデューサーがブロックするように調整する必要があるためです。

于 2012-09-05T04:52:56.167 に答える
2

このベンチマークは奇妙です。並行キューをブロッキングキューとして使用しても意味がないか、何かが足りません。このコードは私が推測する惑星を救うつもりはありません：

while(result == null)
   result = concurrentLinkedQueue.poll();

もちろん、以下よりも効率的ではありません。

linkedBlockingQueue.take();
于 2012-09-05T05:08:05.960 に答える
-3

LinkedBlockingQueue は Deque ですが、ConcurrentBlockingQueue は違います。詳細についてはJavadocを確認 してください

于 2012-09-05T04:52:58.030 に答える