ブロッキング キューについて読んでいて、特定の質問が表示されました。私が読んだすべての例は、1 つのコンシューマー スレッドと 1 つのプロデューサー スレッドしかない状況のみを示しています。問題は、1 つのプロデューサーと 3 つのコンシューマーがあり、現時点ではすべてのコンシューマーが take() メソッドと呼ばれているが、キューが空であるため、最初の要素が表示されるのを待っているとします。最初の要素が表示されたときに、どのコンシューマー スレッドが最初の要素を受け取るか? take() を最初に呼び出した消費者スレッドは?
4 に答える
fair が true かどうかを確認 ArrayBlockingQueue(int capacity, boolean fair)
すると、挿入または削除時にブロックされたスレッドのキュー アクセスが FIFO 順で処理されます。
あなたに言えるかどうかわかりません。本当の問題は、なぜ知る必要があるのかということです。すべてのリスナーは同等である必要があります。どちらがリクエストを処理するかは問題ではありません。知っておく必要がある場合は、設計と実装が正しくありません。
私はダフィーモに同意します。いくつかの新しい要素がキューにポップアップするのを無期限に待機する複数のスレッドを持つという考えは、あまりうまく構造化されていないように聞こえます。
また、消費者のどれが要素を削除したかを知る必要がある場合、消費者がテイクを実行する順序に応じて、消費者は実際にはさまざまなことを行っており、さまざまなシナリオでさまざまな出力に命を吹き込んでいると思います( )。その場合は、スレッドごとに異なるキューが必要になる場合があります。
コードを変更する予定がない場合、定期的にスレッドにポーリングを実行させるのはどうですか?
最初の要素が表示されたときに、どのコンシューマー スレッドが最初の要素を受け取るか? take() を最初に呼び出した消費者スレッドは?
これは、ブロッキング キューの実装と問題の JVM に関連していますが、簡単に言えば「はい」です。各スレッドは条件で待機し、条件が通知されると待機キューの最初のスレッドが起動されます。
とはいえ、問題のブロッキング キューの詳細や JVM と OS のバージョンに大きく依存するため、この機能に依存するべきではありません。