JStack wird verwendet, um die Java -Stack -Informationen einer bestimmten Java -Prozess -ID oder einer Kerndatei oder eines Remote -Debugging -Dienstes auszudrucken. Wenn es sich auf einer 64-Bit-Maschine befindet, müssen Sie die Option "-J-D64" angeben. Die Verwendung von Windows JStack unterstützt nur die folgenden Methoden:
JStack [-l] [f] PID
Wenn ein Java -Programm zum Generieren einer Kerndatei abstürzt, kann das JStack -Tool verwendet werden, um Informationen über den Java -Stack und den nativen Stack der Kerndatei zu erhalten, damit Sie leicht wissen können, wie das Java -Programm abstürzt und wo das Programm problematisch ist. Darüber hinaus kann das JSTACK -Tool dem laufenden Java -Programm angehängt werden und sehen die Informationen über den Java -Stack und den nativen Stack des Java -Programms, das zu diesem Zeitpunkt ausgeführt wurde. Wenn das laufende Java -Programm jetzt den Zustand des Hängen macht, ist JStack sehr nützlich. Wenn sich der Prozess in einem toten Hung -Zustand befindet, können Sie Stapel erzwingen, mit -F gespielt zu werden.
In der Dump -Datei lohnt sich der Thread -Status, auf den man sich beachten sollte:
Deadlock, Deadlock (Fokus auf)
Laufbar
Warten auf Bedingung (Fokus auf)
Warten auf Monitoreintrag (Fokus auf)
Ausgesetzt
Objekt wartet, Object.wait () oder Timed_waiting
Blockiert, blockiert (fokussiert)
Stoppen Sie, geparkt
Ich habe mir drei Szenarien aus einem anderen Blog angesehen:
Beispiel 1: Warten auf das Sperren und blockiert
"RMI TCP Connection (267865) -172.16.5.25" Dämon Prio = 10 TID = 0x00007fd508371000 NID = 0x55Ae wartet auf Monitoreintrag [x000007fd4f8684000] Java.lang.Thread.state: Blocked: Blocked (On Object Monitor) AT-Überwachung) AT-Überwach org.apache.log4j.category.callAppenders (category.java:201)- Warten auf das Sperren <0x000000ACF4D0C0> (a org.apache.log4j.logger) bei org.apache.log4j.category.forcedog (Category.java:388) at org.apache.log4j.category.log (category.java:853) unter org.apache.commons.logging.impl.log4jlogger.warn (log4jlogger.java:234) at com.tuan.core.common.lang.cache.remote.spymemcachedclient.get (spyMemcachedclient.java:110)
veranschaulichen:
1) Der Fadenstatus ist blockiert, blockiert. Dies bedeutet, dass der Thread darauf wartet, dass die Ressource ausgerechnet wird!
2) "Warten auf das Sperren <0x00000000ACF4D0C0>" bedeutet, dass der Faden darauf wartet, die Adresse 0x00000000ACF4D0C0 zu sperren (er kann in englischer Sprache beschrieben werden als: Versuch, 0x0000000000ACF4D0C0 -Sperre zu erhalten).
3) Suchen Sie nach dem String 0x00000000ACF4D0C0 im Dump -Protokoll und stellten fest, dass eine große Anzahl von Threads darauf warten, diese Adresse zu sperren. Wenn Sie finden, wer dieses Sperre im Protokoll erhalten hat (z. B. gesperrt <0x00000000ACF4D0C0>), können Sie den Hinweisen folgen.
4) "Warten auf den Überwachungseintrag" bedeutet, dass dieser Thread durch synchronisierte (obj) {...} Anwendung in den kritischen Bereich eingeht und so die unten stehende Warteschlange "Eingabetast" eingibt. Der Monitor, der dem OBJ entspricht, gehört jedoch anderen Threads. Dieser Thread wartet daher in der Eingabetastwarteschlange.
5) In der ersten Zeile ist "RMI TCP Connection (267865) -172.16.5.25" Threadname. TID bezieht sich auf die Java -Thread -ID. NID bezieht sich auf die ID des nativen Threads. Prio ist Fadenpriorität. [0x00007fd4f8684000] ist die Thread -Stapel -Startadresse.
Beispiel 2: Warten auf Bedingung und Timed_waiting
"RMI TCP Connection(idle)" daemon prio=10 tid=0x00007fd50834e800 nid=0x56b2 waiting on condition [0x000007fd4f1a59000] java.lang.Thread.State: TIMED_WAITING (parking) at sun.misc.Unsafe.park(Native Method)- parking to wait for <0x00000000ACD84DE8> (a java.util.concurrent.synchronousqueue $ transferStack) unter java.util.concurrent.locks.locksupport.parknanos (locksupport.java:198) bei java.util.concurrent.synchronousqueue $ transferStack.awaitfulfill (synchronousqueue.java:424) unter java.util.concurrent.synchronousqueue $ transferstack.transfer ( java.util.concurrent.synchronousqueue.poll (synchronousqueue.java:874) unter java.util.concurrent.threadpoolexecutor.gettask (threadpoolexecutor.java:945) bei java.util.concurrent.threadpoolexecutor $ Worker.run (threadpoolexecutor.java:907) unter java.lang.thread.run (Thread.java:662)
veranschaulichen:
1) Das Timed_Waiting in "Timed_waiting (Parking)" bezieht sich auf den Wartezustand, aber die Zeit wird hier angegeben, und der Wartezustand wird automatisch nach der angegebenen Zeit beendet. Das Parken bezieht sich auf den Faden, der suspendiert wird.
2) "Warten auf den Zustand" muss mit "Parkplätzen" kombiniert werden, um auf <0x00000000ACD84DE8> (a Java.util.Concurrent.Synchronousqueue $ transferStack) im Stapel zu warten. Zunächst wartet dieser Thread definitiv darauf, dass sich ein bestimmter Zustand aufweckt. Zweitens ist Synchronousqueue keine Warteschlange, sondern nur ein Mechanismus zum Übergeben von Informationen zwischen Threads. Wenn wir ein Element in Synchronousqueue einfügen, muss ein weiterer Thread darauf warten, dass die Aufgabe übergeben wird. Dies ist also die Bedingung, auf die dieser Thread wartet.
3) Ich kann nichts anderes sehen.
Beispiel 3: In obejct.wait () und Timed_waiting
"RMI Renewclean- [172.16.5.19:28475]" Dämon Prio = 10 TID = 0x0000000041428800 NID = 0xb09 in Object.wait () [0x00007f34f4bd0000] Java.Lang.Sthead.State: Timed_wait (auf Objektmonitor) at java.d.State: Timed_wait (auf Objektmonitor) bei java.wait. Method)- waiting on <0x00000000aa672478> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:118)- locked <0x00000000aa672478> (a java.lang.ref.ReferenceQueue$Lock) at sun.rmi.transport.dgcclient $ Endpointentry $ renewcleanthread.run (dgcclient.java:516) bei java.lang.thread.run (Thread.java:662)
veranschaulichen:
1) "Timed_waiting (auf Objektmonitor)" Für dieses Beispiel liegt es daran, dass dieser Thread java.lang.object.wait (langfristig) aufruft und in den Wartezustand eintritt.
2) Der wartende Thread -Status in "Wait Set" ist "in Object.wait ()". Wenn der Thread den Monitor erhält und in den kritischen Abschnitt eingeht, wenn er feststellt, dass der Thread weiter ausgeführt wird, wird nicht erfüllt, die Wait () -Methode des Objekts (normalerweise synchronisiert das Objekt), verlässt den Monitor auf und greift die Warteschlange "Wait Set" auf. Nur wenn andere Threads aufrufen, notify () oder notifyAll () im Objekt, erhalten die Threads in der Warteschlange "Wait Set" die Möglichkeit, Wettbewerbe zu konkurrieren, aber nur ein Thread erhält den Monitor des Objekts und kehrt in den Laufstatus zurück.
3) RMI Renewclean ist Teil von DGCClient. DGC bezieht sich auf verteilte GC, dh verteilte Müllsammlung.
4) Bitte beachten Sie, dass es zuerst gesperrt ist. Der Grund für das Sperren zuerst und das gleiche gleiche Objekt besteht darin, die folgende Code -Implementierung zu sehen:
statische private Klasse Lock {}; private lock lock = new Lock (); öffentliche Referenz <? erweitert t> entfernen (langfristig) {synchronisiert (lock) {Referenz <? erweitert t> r = wirklichpoll (); if (r! = null) return r; für (;;) {lock.wait (Timeout); r = wirklichpoll (); …}}Das heißt, während der Ausführung des Threads wird der Monitor dieses Objekts zuerst mit synchronisiertem (entsprechend dem gesperrten <0x0000000AAA672478>) erhalten; Bei der Ausführung von Lock.wait (Timeout);, der Thread nachgibt das Eigentum des Monitors und tritt in die Warteschlange "Wait Set" (entspricht dem Warten auf <0x00000000AA672478>).
5) Nach den Stapelinformationen werden Remote -Verweise auf entfernte Objekte gereinigt. Der referenzierte Mietvertrag ist eingetroffen, und die verteilte Müllsammlung wird nacheinander aufgeräumt.
Referenz:
Lösen
Zusammenfassen
Im obigen dreht sich alles um die Analyse- und Nutzungsszenarien des Java -Thread -Dump -Analyse -Tools JStack. Ich hoffe, es wird für alle hilfreich sein. Interessierte Freunde können weiterhin auf andere verwandte Themen auf dieser Website verweisen. Wenn es Mängel gibt, hinterlassen Sie bitte eine Nachricht, um darauf hinzuweisen. Vielen Dank an Freunde für Ihre Unterstützung für diese Seite!