JVMロック・スレッドのないモニターを含むスレッド・ダンプ

Question

モニター上でロック待ちのスレッドを示すJVMスレッド・ダンプの原因は何ですか？モニターには対応するロック・スレッドがありません。 Windows 2003の

Answer 1

上

のJava 1.5_14ちょうど野生の推測だが、それはスレッドが二度ロックを取得しようとすることで自分自身をロックしていること、できることを？おそらく、あなたがいくつかのコードを投稿できるなら、それは役に立ちます。

Answer 2

はい通常、ロックされている各モニターには所有者スレッドが必要です。スタックダンプが完了していない（長すぎる）か、ダンピングが一貫していない可能性があります。私はそれが世界を止めていないと想像することができるので、ロックされたモニターはダンプされますが、ロックを所有しているスレッドはbeeing（これは単なる推測です）の前にロックを解除します。

検索を容易にするために、ダンプをテキストファイルとしてアップロードし、どのモニタを見ているか教えてください。

Answer 3

あなたのコードは変更によってJNIを使​​用しますか？ （つまり、Javaから起動されたネイティブコードを実行していますか？）

JDK 1.6.0_05と同様の動作が見られました。アプリケーションがデッドロックしているように見えますが、Jstackは他のスレッドが保持していないロックを待っているスレッドを表示します。いくつかのJNIコードがあるので、何かを壊す可能性があります。

解決策が見つかりませんでした。問題は1台のマシンでのみ再現可能です。

Answer 4

待機中のスレッドは永久に待機するのか、それとも最終的に進むのでしょうか？

後者の場合、ガベージコレクタによってロックが保持されている可能性があります。

GCが実行されているときに通知されるjavaコマンドラインに引数-verbose:gc with -XX:+PrintGCDetailsを追加できます。 gcの活動があなたの減速と一致する場合、これが問題であることを示している可能性があります。

ここにあるのはinformation on garbage collectionです。

Answer 5

私は今日も同様の問題を抱えていましたが、静的リソースへのアクセスも含まれていました。

短いバージョンは、AWT TreeLockによってブロックされたAWT-EventQueueスレッドの外側で、静的ブロック内でGUIが変更されたクラスであるため、EventQueueがブロックされたクラスへの参照を作成し、そのクラスのクラスローダのモニタを待つ。

ここで重要なのは、クラスローダーのロックがスレッドダンプにロックされていないことです。

完全な答えはon this threadです。

Answer 6

Java 1.6にアップグレードしようとしましたか？あなたが1.5のみであれば、バグが問題になる可能性があります。