Mehrere Java-threads scheinbar Verriegelung gleichen monitor?

In einer Java-threaddump ich Folgendes gefunden:

"TP-Processor184" daemon prio=10 tid=0x00007f2a7c056800 nid=0x47e7 waiting for monitor entry [0x00007f2a21278000]
   java.lang.Thread.State: BLOCKED (on object monitor)
    at org.apache.jackrabbit.core.state.SharedItemStateManager.getNonVirtualItemState(SharedItemStateManager.java:1725)
    - locked <0x0000000682f99d98> (a org.apache.jackrabbit.core.state.SharedItemStateManager)
    at org.apache.jackrabbit.core.state.SharedItemStateManager.getItemState(SharedItemStateManager.java:257)

"TP-Processor137" daemon prio=10 tid=0x00007f2a7c00f800 nid=0x4131 waiting for monitor entry [0x00007f2a1ace7000]
   java.lang.Thread.State: BLOCKED (on object monitor)
    at org.apache.jackrabbit.core.state.SharedItemStateManager.getNonVirtualItemState(SharedItemStateManager.java:1725)
    - locked <0x0000000682f99d98> (a org.apache.jackrabbit.core.state.SharedItemStateManager)
    at org.apache.jackrabbit.core.state.SharedItemStateManager.getItemState(SharedItemStateManager.java:257)

Der Punkt ist hier, dass beide threads gesperrt-monitor <0x0000000682f99d98> (unabhängig von Ihnen warten jetzt auf zwei verschiedenen Monitoren).

Wenn man bei der Thread-Dump-Analysator, mit diesem monitor wird ausgewählt, es ist wirklich sagt, "Threads sperren monitor: 2" an der Unterseite, und "2 Thread(s) sperren". Bitte sehen https://lh4.googleusercontent.com/-fCmlnohVqE0/T1D5lcPerZI/AAAAAAAAD2c/vAHcDiGOoMo/s971/locked_by_two_threads_3.png für den screenshot, ich bin nicht berechtigt, einfügen von Bildern hier.

Bedeutet dies threaddumps sind nicht atomic mit Respekt zu überwachen, Informationen zu sperren? Ich kann mir nicht vorstellen das wirklich ein schließ-Fehler der JVM (1.6.0_26-b03).

Eine ähnliche Frage wurde bereits gefragt, in Können mehrere threads die Sperre auf dem gleichen monitor in Java?, aber die Antwort mir nicht sehen, der eigentliche Punkt von mehreren threads sperren den gleichen monitor, obwohl Sie warten, für einen anderen.

Update Mai 13th 2014:

Neuere Frage Mehrere threads die gleiche Sperre? - code zum reproduzieren des Verhaltens und @rsxg angemeldet hat, einen entsprechenden bug-report https://bugs.openjdk.java.net/browse/JDK-8036823 entlang der Linien von seine Antwort hier.

  • Keine Rückmeldung auf meine Antwort dude? Ich Schnitt ihn darauf hin, dass spätere Versionen des Codes haben eine wait() on line 1725. Akzeptieren Sie bitte, ob dies richtig ist.
  • Wir sind mit Jackrabbit version 1.6.5. Ein Freund von mir auch gesehen, dass wait() auf der gleichen Zeilennummer in der version 2.3.6, als es auffallend scheint zu passen, aber leider ist das die falsche sourcecode...
InformationsquelleAutor jfrantzius | 2012-03-02
  1. 2

    Sind Sie wahrscheinlich laufen in einen kosmetischen Fehler in der stack-trace-Routinen, die in der JVM bei der Analyse von stark umkämpften sperren - es kann oder kann nicht die gleiche sein, wie dieser Fehler.

    Tatsache ist, dass keiner von den beiden threads haben es tatsächlich geschafft, die Sperre auf der SharedItemStateManager, wie Sie sehen können aus der Tatsache, dass Sie die Berichterstattung waiting for monitor entry. Der Fehler ist, dass weiter oben in der stack-trace in beiden Fällen sollte der Bericht waiting to lock statt locked.

    Den workaround bei der Analyse seltsam stack-traces wie dieses ist immer zu überprüfen, dass ein thread für sich beansprucht, ist locked ein Objekt ist nicht auch das warten auf das abrufen einer Sperre auf dem selben Objekt.

    (Leider ist diese Analyse erfordert die cross-verweisen auf die Zeilennummern in stack-trace, mit dem source code, da es keine Beziehung zwischen den Figuren in der waiting for monitor entry header und die locked Zeile in den stack-trace. Als pro diese Oracle-Dokument, die Anzahl 0x00007f2a21278000 in der Zeile TP-Processor184" daemon prio=10 tid=0x00007f2a7c056800 nid=0x47e7 waiting for monitor entry [0x00007f2a21278000] bezieht sich auf eine Schätzung der gültigen stack-region für den thread. So sieht es aus wie eine monitor-ID-ist es aber nicht - und Sie können sehen, dass die zwei Fäden, die Sie gegeben haben, sind an verschiedenen Adressen im stack).

    • Einen kosmetischen Fehler in der stack-trace-Routinen, klingt vernünftig, und ich würde viel besser fühlen, über Sie als überwacht, nicht exklusiv 🙂 Bezüglich Ihrer workaround (für die Entscheidung, was vor sich geht), die beiden threads nicht sperren Sie das gleiche Objekt ( <0x0000000682f99d98> ), dass Sie warten, um zu erwerben, eine Sperre auf ([0x00007f2a21278000])?
    • Leider ist nicht klar, was den hex-string nach 'monitor-Eintrag" zu verstehen ist, wie in der Antwort von Grau und die zugehörigen Kommentare. Ich habe immer ignorieren, wenn Sie der Analyse stack-traces.
    • Oracle veröffentlicht Dokumentation zur Klärung der Bedeutung der verschiedenen Felder in der thread-dump-header, ich aktualisierte meine Antwort.
    InformationsquelleAutor rxg
  2. 3

    Ich glaube nicht, dass dein thread-dump ist zu sagen, dass Ihr zwei threads "warten auf zwei anderen Monitoren". Ich denke, es ist zu sagen, dass Sie warten beide auf den gleichen monitor aber bei zwei verschiedenen code-Punkte. Das könnte ein stack-Position oder ein Objekt Instanz Lage oder so etwas. Dies ist ein großartiges Dokument über die Analyse der Stapel dumps.

    Können mehrere threads die Sperre auf dem gleichen monitor in Java?

    Nicht. Ihr stack dump zeigt zwei threads gesperrt, auf dem gleichen monitor mit dem gleichen code Ort, sondern in verschiedenen stack-frames -- oder was auch immer das Wert ist, das scheint OS abhängig.

    Edit:

    Ich bin mir nicht sicher, warum der thread-dump scheint zu sagen, dass beide threads eine Zeile gesperrt, da scheint nur zulässig, wenn Sie in einer wait() Methode. Ich bemerkte, dass Sie einen Link zu der version 1.6.5. Ist das wirklich die version, die Sie verwenden? In der version 2.3.6 (die neueste), die 1725 line ist eigentlich ein wait.

    1722        synchronized (this) {
1723            while (currentlyLoading.contains(id)) {
1724                try {
1725                    wait();
1726                } catch (InterruptedException e) {

    Konnte man auch sehen diese Art der stack-trace, auch wenn es war eine exklusive synchronized sperren. Zum Beispiel, die folgende stack dump unter Linux ist für zwei threads gesperrt, die auf das gleiche Objekt aus der gleichen code-Zeile, sondern in zwei verschiedenen Instanzen des Runnable.run() Methode. Hier ist meine dummes kleines test Programm. Beachten Sie, dass der monitor-Eintrag zahlen unterschiedlich sind, dachte sogar, es ist das gleiche, sperren und der gleichen code-Zeile, die Anzahl.

    "Thread-1" prio=10 tid=0x00002aab34055c00 nid=0x4874
  waiting for monitor entry [0x0000000041017000..0x0000000041017d90]
java.lang.Thread.State: BLOCKED (on object monitor)
    at java.lang.Object.wait(Native Method)
    - waiting on <0x00002aab072a1318> (a java.lang.Object)
    at com.mprew.be.service.auto.freecause.Foo$OurRunnable.run(Foo.java:38)
    - locked <0x00002aab072a1318> (a java.lang.Object)
    at java.lang.Thread.run(Thread.java:619)

"Thread-0" prio=10 tid=0x00002aab34054c00 nid=0x4873
  waiting for monitor entry [0x0000000040f16000..0x0000000040f16d10]
java.lang.Thread.State: BLOCKED (on object monitor)
    at java.lang.Object.wait(Native Method)
    - waiting on <0x00002aab072a1318> (a java.lang.Object)
    at com.mprew.be.service.auto.freecause.Foo$OurRunnable.run(Foo.java:38)
    - locked <0x00002aab072a1318> (a java.lang.Object)
    at java.lang.Thread.run(Thread.java:619)

    Auf meinem Mac, das format ist anders, aber wieder der Reihe nach die "monitor-Eintrag" ist nicht das gleiche für die gleiche Zeilennummer.

    "Thread-2" prio=5 tid=7f8b9c00d000 nid=0x109622000
  waiting for monitor entry [109621000]
java.lang.Thread.State: BLOCKED (on object monitor)
    at java.lang.Object.wait(Native Method)
    - waiting on <7f3192fb0> (a java.lang.Object)
    at com.mprew.be.service.auto.freecause.Foo$OurRunnable.run(Foo.java:38)
    - locked <7f3192fb0> (a java.lang.Object)

"Thread-1" prio=5 tid=7f8b9f80d800 nid=0x10951f000
  waiting for monitor entry [10951e000]
java.lang.Thread.State: BLOCKED (on object monitor)
    at java.lang.Object.wait(Native Method)
    - waiting on <7f3192fb0> (a java.lang.Object)
    at com.mprew.be.service.auto.freecause.Foo$OurRunnable.run(Foo.java:38)
    - locked <7f3192fb0> (a java.lang.Object)

    Diese Oracle-Dokument beschreiben, dass ein Wert wie die folgenden:

    Adressbereich, wodurch eine Schätzung der gültigen stack-region für den thread

    • Interessante Sachen! Ich würde immer davon ausgegangen, die zahlen für die Monitore waren Adressen der Objekte, die gesperrt sind, aber offenbar nicht. Es wäre wahrscheinlich nicht das schwer zu Graben, in die JVM-Quellcode, den Ort zu finden, wo diese Spuren sind konstruiert, und sehen, wo diese zahlen herkommen. Ich muss gestehen, ich habe nicht das Gefühl, wie es zu tun rechts in dieser minute, though.
    • Vielen Dank für diesen test! Die zwei Fäden, die im Loch sind wait()ing für das gleiche Objekt, das Sie abgeschlossen hatte, bevor, obwohl, so dass Sie beide haben tatsächlich die Sperre. Das ist ein Beispiel, wie zwei "gesperrt" - Veranstaltungen gezeigt werden können, in einem threaddump für zwei verschiedene threads für den gleichen monitor, aber immer noch anders aus als mein thread dump. Die threads dort nicht warten() und nicht loslassen sperren (auf dem gleichen monitor) beide scheinen erhalten zu haben, und das ist gegen die JVM spec. Du hast Recht über meine Fehlinterpretation der "monitor-Eintrag" Adresse, nur die Sonne scheint genau zu wissen, was es bedeutet...
    • Anderson ja stimmt ich auch nicht, vielleicht morgen 😉
    • Ich Stimme @jfrantzius. Ich denke, dass Ihr stack-trace ist die gleiche. Die threads gesperrt, die gleiche Sperre (0x0000000682f99d98) und haben darauf gewartet. Da Sie nun BLOCKED ich denke, das bedeutet, dass Sie aufgehört haben zu warten -- entweder benachrichtigt werden, oder timeout warten. Wenn Sie mein kleines test-Programm und stellen die timeouts können Sie sehen, die threads verschieben warten auf gesperrt.
    • es gibt keine wait() in der sourcecode wie es ist in dir. Es ist ein synchronisierter block nur.
    • Zu ignorieren, daß der Widerspruch von der JVM-Spezifikation, die nächste Frage ist: was zum Teufel werden die threads warten dann? Oracle-Forum es vermuten lässt, ist die Garbage Collection putting threads im GESPERRTEN Zustand, wie dieser Stack-Overflow-Frage. Aber das ist nur raten im moment.
    • Also @jfrantzius, das Schloss sieht readLock = acquireReadLock(id); auf der Linie 253. Ich aktualisiert meine Antwort mit den details, die Sperre. Die Art der Sperre, es ist versteckt durch eine Schnittstelle. Ich bin beeindruckt, dass gemeinsame sperren in der stack-trace so.
    • die Schlösser berichtet von einem thread-dump sind JVM-level-Objekt überwacht, und kann nur erworben werden durch die Eingabe eines synchronisierten Blocks bzw. der Methode. Sobald so ein block oder eine Methode übrig ist, wird die Sperre aufgehoben. Also ein Aufruf einer Methode wie "acquireReadLock()", sobald es zurückgegeben hat, nicht verlassen kann ein gesperrtes Objekt zu überwachen, weil einfach die Methode ist nicht auf den call-stack nicht mehr. Der Anruf kann lassen Sie änderungen an anderen Objekt Zustand, aber nicht Objekt überwacht.
    • Ja @jfrantzius, du hast Recht. Ich entfernte die readlock Bearbeiten. Das war es nicht. Ich habe gerade einen längeren Blick auf Ihren code. Ich Wette, Sie sind nicht mit der version 1.6.5 von Ihrem code. Line 1725 in version 2.3.6 eigentlich ist ein wait Linie. Siehe: grepcode.com/file/repo1.maven.org/maven2/org.apache.jackrabbit/...
    • Wir sind auch vor ähnlichen Fragen. Ich habe versucht zu posten details als Kommentar hier, aber es ist zu lang. So, ich habe gepostet, als eine neue Antwort. Bitte lassen Sie uns wissen Sie Ihre Gedanken.
    • Fügte hinzu, es als eine neue Frage @ stackoverflow.com/questions/17464152/...

    InformationsquelleAutor Gray
  3. 2

    Wenn ein thread ein Objekt sperrt, aber wait()s ein anderer thread sperren kann das gleiche Objekt. Sie sollten in der Lage sein, um zu sehen, eine Anzahl von threads, "holding", die gleiche Sperre, die alle darauf warten.

    AFAIK, die einzige andere Gelegenheit ist, wenn mehrere threads gesperrt und wartete und bereit sind, neu zu erwerben, der die Sperre z.B. auf einem notifyAll(). Sie warten nicht mehr, sondern können erst fortfahren, wenn Sie erhalten haben, die Sperre wieder. (nur ein thread zu einem Zeitpunkt kann die Zeit dies zu tun)

    • Nur zur Klarstellung @Peter, meinst Du: "Wenn ein thread ein Objekt sperrt, aber wait()s on_that_same_object einem anderen thread..."
    • genau, und die threads werden nicht wartet auf das gleiche Objekt, sondern auf zwei verschiedene, wenn diese hexadezimale Zahl bedeuten, die Speicheradressen von Objekten ist...)
    • OK, Sie sind noch nicht warten()ing auf das gleiche Objekt, aber Sie warten darauf, für etwas (maybe GC)... wie auch immer, Sie haben nicht die Sperre durch Aufruf von wait(), aber Sie scheinen beide in "synchronized (this)" für das gleiche Objekt "dieses".
    InformationsquelleAutor Peter Lawrey
  4. 0
    "http-0.0.0.0-8080-96" daemon prio=10 tid=0x00002abc000a8800 nid=0x3bc4 waiting for monitor entry [0x0000000050823000]
    java.lang.Thread.State: BLOCKED (on object monitor)
    at org.apache.lucene.search.FieldCacheImpl$Cache.get(FieldCacheImpl.java:195)
    - locked <0x00002aadae12c048> (a java.util.WeakHashMap)

"http-0.0.0.0-8080-289" daemon prio=10 tid=0x00002abc00376800 nid=0x2688 waiting for monitor entry [0x000000005c8e3000]
    java.lang.Thread.State: BLOCKED (on object monitor)
    at org.apache.lucene.search.FieldCacheImpl$Cache.get(FieldCacheImpl.java:195)
    - locked <0x00002aadae12c048> (a java.util.WeakHashMap

"http-0.0.0.0-8080-295" daemon prio=10 tid=0x00002abc00382800 nid=0x268e runnable [0x000000005cee9000]
     java.lang.Thread.State: RUNNABLE
     at org.apache.lucene.search.FieldCacheImpl$Cache.get(FieldCacheImpl.java:195)
     - locked <0x00002aadae12c048> (a java.util.WeakHashMap)

    In unserem thread-dump, wir haben mehrere threads lock gleichen monitor, aber nur ein thread runnable. Ist es wahrscheinlich, weil der lock Wettbewerb, wir haben 284 andere threads warten auf die Schleuse. Mehrere threads die gleiche Sperre? sagte, dies existiert nur in der thread-dump für thread-dump ist keine Atomare operation.

    InformationsquelleAutor
Schreibe einen Kommentar