java.util.concurrent.ConcurrentLinkedQueue頭に浮かびますが、この2スレッドのシナリオには本当に最適ですか？両側（プロデューサーとコンシューマー）で可能な最小のレイテンシーを探しています。キューが空の場合はすぐにnullを返すことができ、キューがいっぱいの場合は提供しているエントリをすぐに破棄できます。
ConcurrentLinkedQueueは超高速で軽いロック（AtomicBoolean）を使用しますか？誰かがConcurrentLinkedQueueのベンチマークを行ったことがありますか、それを行うための究極の最速の方法を知っていますか？
追加の詳細：キューは公平なものである必要があると思います。つまり、コンシューマーは、必要以上に（フロントランニングによって）コンシューマーを待たせてはならず、その逆も同様です。
私が知っているJavaのレイテンシーを最小にするには、LMAXによって開発されたDisruptorパターンを使用できます。
基本的に、それらはすべての待ち時間を短縮します。これは、十分に確立された問題に対する多くのかなりユニークなソリューションを意味します。たとえば、可能な限り事前に割り当ててオブジェクトを再利用します（ガベージコレクションによってレイテンシが追加されるのを防ぐため）。
彼らのソリューションは、特定のチェックポイントを通過するコードフォームのアウトオブオーダー実行を防ぐメモリバリアに基づいています。これにより、1つのプロデューサースレッドと複数のコンシューマースレッド間の適切な同期を確保できます。
これは、問題とLMAXの解決策を説明するホワイトペーパーと、解決策の理論的根拠と設計の詳細を説明する最近のYouTubeビデオです。使用するには多くのコードの再構築が必要になりますが、現在のところ、これは町で最も速く、最も待ち時間が短いものです。