「1つのデッドロックを発見」が、トレースは任意のデッドロックが発生したことを

Question

JVMが私に語ったスレッドによってロックされていないことを示しています

Found one Java-level deadlock: 
============================= 
"TP-Processor107": 
    waiting for ownable synchronizer 0x00002aaaf58e70f0, (a java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync), 
    which is held by "indexTrackerThread3" 
"indexTrackerThread3": 
    waiting for ownable synchronizer 0x00002aaaf4394580, (a java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync), 
    which is held by "TP-Processor16" 
"TP-Processor16": 
    waiting for ownable synchronizer 0x00002aaaf58e70f0, (a java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync), 
    which is held by "indexTrackerThread3" 

我々はindexTrackerThread3がTP-Processor16が保有するリソースを待っていることを見ることができ、かつ副-versa。それは確かにデッドロックです。

我々はindexTrackerThread3が0x00002aaaf4394580を待っていることがわかります。

"indexTrackerThread3": 
    - parking to wait for <0x00002aaaf4394580> 

私の質問：the threads dumpで

、なぜ何のライン- locked <0x00002aaaf4394580>はありませんか？

0x00002aaaf58e70f0は実際にはどのスレッドでもロックされていないようです。何がそれをロックすることができますか？

すべての異なる- parking to wait for <0x123>行に対して、私が読んだデッドロックのドキュメント（example）には常に- locked <0x123>という行が1つあります。だから私はJVMのバグを疑うようになる。私は何かを誤解していますか？

注：pastebinにリンクして申し訳ありませんが、完全なダンプを実行しないと問題は解決できません。簡潔にするため、「at」を含むすべての行を削除しましたが、ロック情報は含まれていません。

Answer 1

java.util.concurrentパッケージは、非局所的なネイティブのパーキング機構（アトミックの比較とスワップなどの他のネイティブメカニズムと同様）を使用します。私が何を言っているのかを見ることができます。here。

通常、スレッドダンプで発生すると記述されているパターンは、従来のJavaイディオムsynchronized(lock) { lock.wait(); }に由来します。

Answer 2

Marko Topolnikの答えは正しいです。

問題の解決策として、JProfilerは、java.util.concurrentパッケージからのロックを含むロック状況のスレッドとモニタの完全なグラフを表示します。

免責事項：私の会社はJProfilerを

Answer 3

異なる事がJavaスレッドをデッドロックすることができます開発し、モニターは、synchronizedキーワード別名、ただ一つのことです。

A lock can be a built-in object monitor, an ownable synchronizer, or the Condition object associated with synchronizers.

また、詳細についてThreadMXBean.findDeadlockedThreadsとThreadMXBean.findMonitorDeadlockedThreadsの定義で掘ることができます。

私の心配するところでは、モニタのロックとjavaのロックです。

スレッドダンプでは、waiting to lock <0x123>とlocked <0x123>の組み合わせは、モニタロック用です。 java 5のロックでは、最初の部分だけを取得します。 何かのようなparking to wait for <0x456>。次に、スレッドダンプで0x456を検索しますが、見つからない場所はありません。これは混乱しています。

Answer 4

この種のデッドロックのスレッドダンプ解析の複雑さは、主にjava.util.concurrentパッケージの使用によるものです。これは、Javaオブジェクトを同期させる古典的な方法から遠ざかるように作られました。このパッケージは、たとえば、WRITE操作を単一のスレッドモデルに制限し、同時にREAD操作を許可したい場合に非常に便利です。このアプローチはパフォーマンスチューニングの観点からは優れていますが、同時実行の問題に対処する場合、スレッドダンプ解析プロセスの複雑さが増します。

また、次の記事もご覧ください。これは、JVMがデッドロックを検出することさえできない（通常は所有権の概念を持つように設計されていないREADロックのために）hidden Java deadlockシナリオなどの問題を記述します。サンプルJavaプログラムが例として提供されています。

Answer 5

スタックトレースは、0x00002aaaf4394580がスレッドによってロックされていないことを示しています。これはJava bug #6822370のために発生します。この観察結果は、voted answerにクロージャを追加する必要があります。