4

私が取り組んでいるロギング機能では、ジョブを待機し、カウントが特定の数に達するか超えたときにバッチで実行する処理スレッドが必要です。これはプロデューサ コンシューマの問題の標準的なケースなので、 BlockingQueuesを使用するつもりです。add()メソッドを使用してキューにエントリを追加する多くのプロデューサーがいますが、キューで待機するためにtake()を使用するコンシューマー スレッドは 1 つしかありません。

LinkedBlockingQueueはサイズ制限がないため、適切なオプションのようですが、ドキュメントからこれを読んで混乱しています。

通常、リンクされたキューはアレイベースのキューよりもスループットが高くなりますが、ほとんどの同時実行アプリケーションではパフォーマンスが予測しにくくなります。

この声明が何を意味するのかは明確に説明されていませんでした。誰かがそれに光を当ててくれませんか？LinkedBlockingQueue がスレッドセーフではないということですか? LinkedBlockingQueue を使用して問題に遭遇した人はいますか。

プロデューサーの数がはるかに多いため、追加される多数のエントリでキューが圧倒されるシナリオが常に発生する可能性があります。代わりに、キューのサイズをコンストラクターのパラメーターとして受け取る ArrayBlockingQueueを使用すると、容量がいっぱいになることに関連する例外が常に発生する可能性があります。これを回避するために、ArrayBlockingQueue をインスタンス化する必要があるサイズを決定する方法がわかりません。ArrayBlockingQueue を使用して同様の問題を解決する必要がありましたか?

4

1 に答える 1

7

LinkedBlockingQueue がスレッドセーフではないということですか?

それは確かにそれを意味するものではありません。「パフォーマンスが予測しにくい」という言葉は、まさにパフォーマンスのことを指しており、スレッド セーフや Java コレクションの規約に違反するものではありません。

これは、リンクされたリストであるため、コレクションに対する反復やその他の操作が遅くなるため、クラスがロックをより長く保持するという事実に関連していると思われます。また、配列内の単なるエントリではなく、各要素が 1 つのリンク リスト ノードであるため、より多くのメモリ構造を処理する必要があります。これは、同期時にプロセッサ間でより多くのダーティ メモリ ページをフラッシュする必要があることを意味します。繰り返しますが、これはパフォーマンスに影響します。

彼らが言おうとしているのは、できるなら を使うべきだということですが、ArrayBlockingQueueそうでなければ私は気にしません。

LinkedBlockingQueue を使用して問題に遭遇した人はいますか。

私はそれをたくさん使ってきましたが、問題は見られませんでした。また、ExecutorServiceどこでも使用されるクラスでも多く使用されます。

于 2012-08-30T23:08:10.987 に答える