JVM Thread-Dumps, die Monitore ohne sperrende Threads enthalten

Verwendet Ihr Code bei jeder Änderung JNI? (d. h. führen Sie einen systemeigenen Code aus, der von Java gestartet wurde?).

Wir haben ein ähnliches Verhalten gesehen, aber JDK 1.6.0_05. App scheint Deadlock zu sein, aber Jstack zeigt Threads, die auf eine Sperre warten, an der sich keine anderen Threads festhalten. Wir haben einen JNI-Code, also ist es möglich, dass wir etwas korrumpieren.

Wir haben dafür keine Lösung gefunden und das Problem ist nur auf einer Maschine reproduzierbar.

Falls Letzteres zutrifft, kann es sein, dass die Sperre vom Garbage Collector gehalten wird.

Sie können die Argumente -verbose:gc with -XX:+PrintGCDetails in Ihrer Java-Befehlszeile hinzufügen, um informiert zu werden, wenn GCs auftreten. Wenn die GC-Aktivität mit Ihren Verlangsamungen zusammenfällt, kann dies darauf hindeuten, dass dies das Problem ist.

Hier finden Sie einige Informationen zur Garbage Collection .

Das ist nur eine wilde Vermutung, aber könnte es sein, dass ein Thread sich selbst blockiert, indem er versucht, zweimal eine Sperre zu erhalten? Wahrscheinlich würde es helfen, wenn Sie etwas Code schreiben könnten.

Ja, normalerweise muss jeder Monitor, der gesperrt ist, einen Besitzer-Thread haben. Vielleicht war Ihr Stack Dump nicht vollständig (zu lang) oder das Dumping war nicht konsistent. Ich könnte mir vorstellen, dass es die Welt nicht stoppt, also wird ein gesperrter Monitor weggeworfen, aber der Thread, dem die Sperre gehört, gibt ihn frei, bevor er gelöscht wird (das ist nur eine Vermutung).

Können Sie den Dump als Textdatei hochladen, um die Suche zu erleichtern und uns sagen, welchen Monitor Sie betrachten.