オブザーバー-BlockingQueue

Question

オブザーバーパターンとBlockingQueueを使用してインスタンスを追加しています。別のメソッドでキューを使用していますが、次のように実行しているにもかかわらず、take（）が永久に待機しているようです： ジェネラコディセタグプレ

mDiffQueueはLinkedBlockingQueueであり、私は次のように使用しています： ジェネラコディセタグプレ

しかし、mDoneがtrueではないのに最初の式がチェックされていると思うので、mDoneがtrueに設定されている可能性があります（オブザーバーは常にマルチスレッドですか？）が、すでにmDiffQueue.take（）を呼び出していますか？ ：-/

編集：今は本当にわかりません。最近、次のように変更しました： ジェネラコディセタグプレ

デバッガーで少し待つと動作しますが、mDoneがfalseに初期化されるため、「リアルタイム」でも動作するはずです。したがって、while条件はtrueになり、本体が実行されます。>

mDiffQueueが空で、mDoneがtrueの場合、whileループの本体をスキップする必要があります（つまり、キューはもういっぱいになりません）。

編集：次のようです： ジェネラコディセタグプレ

peek（）が必須である理由がわかりませんが。

編集：

私が行っているのはツリーを反復処理することであり、挿入されたすべてのノードをスキップしたい： ジェネラコディセタグプレ

基本的に、ツリーの別のリビジョンで削除されたノードを考慮せずに、ツリーの最大深度またはレベルを計算します（サンバーストの視覚化の比較のため）が、それは範囲外である可能性があります。最大深度を調整しているだけでも、挿入されていないノードで何かをしていることを説明するためだけに。

よろしく

ヨハネス

Answer 1

最初のアドバイス：ジェネラコダイスタグコードを生成しないでください。 LinkedBlockingQueueにsynchronized (mDiffQueue)メソッドがあると、デッドロックが発生します。ここではそうではありませんが、避けるべき習慣です。とにかく、その時点で同期している理由がわかりません。

synchronizedが設定されているかどうかを確認するのを待つ間、定期的に「ウェイクアップ」する必要があります。 ジェネラコディセタグプレ

これは、mDoneを使用する場合とほぼ同じですが、peekは基本的にナノ秒待機します。 peekの使用は「ビジー待機」（スレッドはwhileループをノンストップで実行）と呼ばれ、peekの使用は「セミビジー待機」（スレッドを一定の間隔でスリープさせる）と呼ばれます。

あなたの場合、poolがprocess(diff)タイプでない場合、diffはループから抜け出すことになると思います。それがあなたが達成しようとしていることであるかどうかはわかりません。基本的に、適切なタイプの単一の要素を取得するまでコンシューマースレッドを停止し、その後は何もしないため、これは奇妙に思えます。また、whileループから外れているため、将来の着信要素を受け取ることはできません。

Answer 2

take()は「ブロッキングコール」です。つまり、キューに何かが入るまでブロック（永久に待機）し、追加されたものを返します。もちろん、キューに何かがある場合は、すぐに戻ります。

peek()を使用して、take()によって返される ものを返すことができます。つまり、peek()は、キューから削除せずに次のアイテムを 返すか、存在する場合はnullを返します。キューには何もありません。テストでは、代わりにpeek()を使用してみてください（ただし、nullも確認してください）。