Lass uns über Thread-Dumps sprechen und wie sie analysiert werden können.
Wir werden untersuchen, wie Thread-Dumps helfen können, Probleme zu identifizieren, und einige der Analysewerkzeuge, die du nutzen kannst.
Was ist ein Thread?
Ein Prozess ist ein Computerprogramm, das in den Speicher eines Computers geladen und ausgeführt wird. Es kann von einem einzelnen oder einer Gruppe von Prozessoren bearbeitet werden. Ein Prozess wird im Speicher durch wichtige Informationen wie variable Speicherbereiche, Dateihandles, den Programmzähler, Register und Signale beschrieben.
Ein Prozess kann in viele kleinere Prozesse unterteilt werden, die als Threads bezeichnet werden. Dies ermöglicht Parallelität, da ein Prozess in mehrere Threads aufgeteilt wird, was zu einer gesteigerten Leistung führt. Alle Threads innerhalb eines Prozesses teilen sich den gleichen Speicherbereich und sind voneinander abhängig.
Thread-Dumps
Während der Ausführung eines Prozesses können wir den aktuellen Status der Threads mithilfe von Thread-Dumps einsehen. Ein Thread-Dump ist eine Momentaufnahme aller Threads, die zu einem bestimmten Zeitpunkt innerhalb eines Programms aktiv sind. Er enthält wichtige Informationen über jeden Thread und dessen aktuellen Zustand.
Heutzutage bestehen moderne Anwendungen aus mehreren Threads. Jeder Thread benötigt bestimmte Ressourcen und führt spezifische Aktivitäten im Zusammenhang mit dem Prozess aus. Dies kann die Performance einer Anwendung steigern, da Threads die verfügbaren CPU-Kerne nutzen können.
Es gibt jedoch auch Kompromisse, wie z.B. die Möglichkeit, dass mehrere Threads nicht optimal zusammenarbeiten und es zu einem Deadlock kommen kann. In solchen Fällen können Thread-Dumps genutzt werden, um den Status der Threads zu überprüfen.
Thread-Dumps in Java
Ein JVM-Thread-Dump ist eine Auflistung des Zustands aller Threads, die zu einem bestimmten Zeitpunkt Teil des Prozesses sind. Er enthält Informationen über den Stack des Threads, dargestellt als Stack-Trace. Da der Inhalt als Klartext gespeichert wird, kann er für eine spätere Analyse aufbewahrt werden. Die Analyse von Thread-Dumps hilft bei:
- Optimierung der JVM-Leistung
- Verbesserung der Anwendungsleistung
- Diagnose von Problemen wie Deadlocks, Thread-Konflikten usw.
Erstellung von Thread-Dumps
Es gibt viele Wege, um Thread-Dumps zu erzeugen. Hier sind einige JVM-basierte Tools aufgeführt, die über die Befehlszeile/das Terminal (CLI-Tools) oder das /bin-Verzeichnis (GUI-Tools) der Java-Installationsordner ausgeführt werden können.
Lass sie uns genauer ansehen.
#1. jStack
Der einfachste Weg, einen Thread-Dump zu erstellen, ist die Verwendung von jStack. jStack ist Bestandteil der JVM und kann über die Befehlszeile verwendet werden. Dafür wird die PID des Prozesses benötigt, für den der Thread-Dump erstellt werden soll. Die PID kann mit dem Befehl jps ermittelt werden, wie unten gezeigt.
jps -l
jps listet alle Java-Prozess-IDs auf.
Unter Windows
C:Program FilesJavajdk1.8.0_171bin>jps -l 47172 portal 6120 sun.tools.jps.Jps C:Program FilesJavajdk1.8.0_171bin>
Unter Linux
[[email protected] ~]# jps -l 1088 /opt/keycloak/jboss-modules.jar 26680 /var/lib/jenkins/workspace/kyc/kyc/target/kyc-1.0.jar 7193 jdk.jcmd/sun.tools.jps.Jps 2058 /usr/share/jenkins/jenkins.war 11933 /var/lib/jenkins/workspace/admin-portal/target/portal-1.0.jar [[email protected] ~]#
Wie wir sehen können, erhalten wir eine Liste aller laufenden Java-Prozesse. Die Spalten eins und zwei zeigen die lokale VM-ID des laufenden Java-Prozesses und den Namen der Anwendung. Um nun den Thread-Dump zu generieren, wird das Programm jStack mit dem Flag -l verwendet, was eine ausführliche Ausgabe des Dumps erstellt. Die Ausgabe kann auch in eine Textdatei umgeleitet werden.
jstack -l 26680
[[email protected] ~]# jstack -l 26680
2020-06-27 06:04:53
Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.221-b11 mixed mode):
"Attach Listener" #16287 daemon prio=9 os_prio=0 tid=0x00007f0814001800 nid=0x4ff2 waiting on condition [0x0000000000000000]
java.lang.Thread.State: RUNNABLE
Locked ownable synchronizers:
- None
"logback-8" #2316 daemon prio=5 os_prio=0 tid=0x00007f07e0033000 nid=0x4792 waiting on condition [0x00007f07baff8000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x00000006ca9a1fc0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1081)
at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Locked ownable synchronizers:
- None
"logback-7" #2315 daemon prio=5 os_prio=0 tid=0x00007f07e0251800 nid=0x4791 waiting on condition [0x00007f07bb0f9000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x00000006ca9a1fc0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1081)
at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Locked ownable synchronizers:
- None
#2. jvisualvm
jvisualvm ist ein GUI-Tool, das bei der Fehlerbehebung, Überwachung und Profilerstellung von Java-Anwendungen unterstützt. Es ist ebenfalls Teil der JVM und kann aus dem /bin-Verzeichnis der Java-Installation gestartet werden. Es ist sehr intuitiv und einfach zu bedienen. Neben anderen Funktionen ermöglicht es auch das Erfassen von Thread-Dumps für einen bestimmten Prozess.
Um den Thread-Dump eines bestimmten Prozesses anzuzeigen, kann man mit der rechten Maustaste auf das Programm klicken und dann „Thread-Dump“ aus dem Kontextmenü auswählen.
#3. jcmd
JCMD ist ein Befehlszeilen-Dienstprogramm, das im JDK enthalten ist und zum Senden von Diagnosebefehlen an die JVM verwendet wird.
Es funktioniert jedoch nur auf dem lokalen Rechner, auf dem die Java-Anwendung ausgeführt wird. Es kann zur Steuerung von Java-Flugaufzeichnungen, zur Diagnose von JVM- und Java-Anwendungen sowie zur Fehlerbehebung verwendet werden. Der Thread.print-Befehl von jcmd kann verwendet werden, um eine Liste von Thread-Dumps für einen bestimmten Prozess zu erhalten, der durch seine PID identifiziert wird.
Hier ist ein Beispiel für die Verwendung von jcmd.
jcmd 28036 Thread.print
C:Program FilesJavajdk1.8.0_171bin>jcmd 28036 Thread.print
28036:
2020-06-27 21:20:02
Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.171-b11 mixed mode):
"Bundle File Closer" #14 daemon prio=5 os_prio=0 tid=0x0000000021d1c000 nid=0x1d4c in Object.wait() [0x00000000244ef000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Unknown Source)
at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.getNextEvent(EventManager.java:403)
- locked <0x000000076f380a88> (a org.eclipse.osgi.framework.eventmgr.EventManager$EventThread)
at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:339)
"Active Thread: Equinox Container: 0b6cc851-96cd-46de-a92b-253c7f7671b9" #12 prio=5 os_prio=0 tid=0x0000000022e61800 nid=0xbff4 waiting on condition [0x00000000243ee000]
java.lang.Thread.State: TIMED_WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x000000076f388188> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.parkNanos(Unknown Source)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(Unknown Source)
at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(Unknown Source)
at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.getTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
"Service Thread" #10 daemon prio=9 os_prio=0 tid=0x0000000021a7b000 nid=0x2184 runnable [0x0000000000000000]
java.lang.Thread.State: RUNNABLE
"C1 CompilerThread3" #9 daemon prio=9 os_prio=2 tid=0x00000000219f5000 nid=0x1300 waiting on condition [0x0000000000000000]
java.lang.Thread.State: RUNNABLE
"C2 CompilerThread2" #8 daemon prio=9 os_prio=2 tid=0x00000000219e0000 nid=0x48f4 waiting on condition [0x0000000000000000]
java.lang.Thread.State: RUNNABLE
"C2 CompilerThread1" #7 daemon prio=9 os_prio=2 tid=0x00000000219df000 nid=0xb314 waiting on condition [0x0000000000000000]
java.lang.Thread.State: RUNNABLE
"C2 CompilerThread0" #6 daemon prio=9 os_prio=2 tid=0x00000000219db800 nid=0x2260 waiting on condition [0x0000000000000000]
java.lang.Thread.State: RUNNABLE
"Attach Listener" #5 daemon prio=5 os_prio=2 tid=0x00000000219d9000 nid=0x125c waiting on condition [0x0000000000000000]
java.lang.Thread.State: RUNNABLE
"Signal Dispatcher" #4 daemon prio=9 os_prio=2 tid=0x00000000219d8000 nid=0x834 runnable [0x0000000000000000]
java.lang.Thread.State: RUNNABLE
"Finalizer" #3 daemon prio=8 os_prio=1 tid=0x000000001faf3000 nid=0x36c0 in Object.wait() [0x0000000021eae000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x000000076f390180> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(Unknown Source)
- locked <0x000000076f390180> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(Unknown Source)
at java.lang.ref.Finalizer$FinalizerThread.run(Unknown Source)
"Reference Handler" #2 daemon prio=10 os_prio=2 tid=0x0000000005806000 nid=0x13c0 in Object.wait() [0x00000000219af000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x000000076f398178> (a java.lang.ref.Reference$Lock)
at java.lang.Object.wait(Unknown Source)
at java.lang.ref.Reference.tryHandlePending(Unknown Source)
- locked <0x000000076f398178> (a java.lang.ref.Reference$Lock)
at java.lang.ref.Reference$ReferenceHandler.run(Unknown Source)
"main" #1 prio=5 os_prio=0 tid=0x000000000570e800 nid=0xbf8 runnable [0x0000000000fec000]
java.lang.Thread.State: RUNNABLE
at java.util.zip.ZipFile.open(Native Method)
at java.util.zip.ZipFile.<init>(Unknown Source)
at java.util.zip.ZipFile.<init>(Unknown Source)
at java.util.zip.ZipFile.<init>(Unknown Source)
at org.eclipse.osgi.framework.util.SecureAction.getZipFile(SecureAction.java:307)
at org.eclipse.osgi.storage.bundlefile.ZipBundleFile.getZipFile(ZipBundleFile.java:136)
at org.eclipse.osgi.storage.bundlefile.ZipBundleFile.lockOpen(ZipBundleFile.java:83)
at org.eclipse.osgi.storage.bundlefile.ZipBundleFile.getEntry(ZipBundleFile.java:290)
at org.eclipse.equinox.weaving.hooks.WeavingBundleFile.getEntry(WeavingBundleFile.java:65)
at org.eclipse.osgi.storage.bundlefile.BundleFileWrapper.getEntry(BundleFileWrapper.java:55)
at org.eclipse.osgi.storage.BundleInfo$Generation.getRawHeaders(BundleInfo.java:130)
- locked <0x000000076f85e348> (a java.lang.Object)
at org.eclipse.osgi.storage.BundleInfo$CachedManifest.get(BundleInfo.java:599)
at org.eclipse.osgi.storage.BundleInfo$CachedManifest.get(BundleInfo.java:1)
at org.eclipse.equinox.weaving.hooks.SupplementerRegistry.addSupplementer(SupplementerRegistry.java:172)
at org.eclipse.equinox.weaving.hooks.WeavingHook.initialize(WeavingHook.java:138)
at org.eclipse.equinox.weaving.hooks.WeavingHook.start(WeavingHook.java:208)
at org.eclipse.osgi.storage.FrameworkExtensionInstaller.startActivator(FrameworkExtensionInstaller.java:261)
at org.eclipse.osgi.storage.FrameworkExtensionInstaller.startExtensionActivators(FrameworkExtensionInstaller.java:198)
at org.eclipse.osgi.internal.framework.SystemBundleActivator.start(SystemBundleActivator.java:112)
at org.eclipse.osgi.internal.framework.BundleContextImpl$3.run(BundleContextImpl.java:815)
at org.eclipse.osgi.internal.framework.BundleContextImpl$3.run(BundleContextImpl.java:1)
at java.security.AccessController.doPrivileged(Native Method)
at org.eclipse.osgi.internal.framework.BundleContextImpl.startActivator(BundleContextImpl.java:808)
at org.eclipse.osgi.internal.framework.BundleContextImpl.start(BundleContextImpl.java:765)
at org.eclipse.osgi.internal.framework.EquinoxBundle.startWorker0(EquinoxBundle.java:1005)
at org.eclipse.osgi.internal.framework.EquinoxBundle$SystemBundle$EquinoxSystemModule.initWorker(EquinoxBundle.java:190)
at org.eclipse.osgi.container.SystemModule.init(SystemModule.java:99)
at org.eclipse.osgi.internal.framework.EquinoxBundle$SystemBundle.init(EquinoxBundle.java:272)
at org.eclipse.osgi.internal.framework.EquinoxBundle$SystemBundle.init(EquinoxBundle.java:257)
at org.eclipse.osgi.launch.Equinox.init(Equinox.java:171)
at org.eclipse.core.runtime.adaptor.EclipseStarter.startup(EclipseStarter.java:316)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:251)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:661)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:597)
at org.eclipse.equinox.launcher.Main.run(Main.java:1476)
"VM Thread" os_prio=2 tid=0x000000001fae8800 nid=0x32cc runnable
"GC task thread#0 (ParallelGC)" os_prio=0 tid=0x0000000005727800 nid=0x3264 runnable
"GC task thread#1 (ParallelGC)" os_prio=0 tid=0x0000000005729000 nid=0xbdf4 runnable
"GC task thread#2 (ParallelGC)" os_prio=0 tid=0x000000000572a800 nid=0xae6c runnable
"GC task thread#3 (ParallelGC)" os_prio=0 tid=0x000000000572d000 nid=0x588 runnable
"GC task thread#4 (ParallelGC)" os_prio=0 tid=0x000000000572f000 nid=0xac0 runnable
"GC task thread#5 (ParallelGC)" os_prio=0 tid=0x0000000005730800 nid=0x380 runnable
"GC task thread#6 (ParallelGC)" os_prio=0 tid=0x0000000005733800 nid=0x216c runnable
"GC task thread#7 (ParallelGC)" os_prio=0 tid=0x0000000005734800 nid=0xb930 runnable
"VM Periodic Task Thread" os_prio=2 tid=0x0000000021a8d000 nid=0x2dcc waiting on condition
JNI global references: 14
C:Program FilesJavajdk1.8.0_171bin>
#4. JMC
JMC steht für Java Mission Control. Es ist ein Open-Source-GUI-Tool, das im JDK enthalten ist und zur Erfassung und Analyse von Java-Anwendungsdaten verwendet wird.
Es kann aus dem /bin-Ordner der Java-Installation gestartet werden. Java-Administratoren und -Entwickler verwenden das Tool, um detaillierte Informationen über das Verhalten von JVMs und Anwendungen zu sammeln. Es ermöglicht eine detaillierte und effiziente Analyse der von Java Flight Recorder erfassten Daten.
Nach dem Start von jmc ist eine Liste der auf dem lokalen Computer laufenden Java-Prozesse zu sehen. Es ist auch eine Fernverbindung möglich. Für einen bestimmten Prozess kann per Rechtsklick „Start Flight Recording“ ausgewählt und die Thread-Dumps dann im Tab „Threads“ eingesehen werden.
#5. jconsole
jconsole ist ein Java Management Extension-Tool, das für die Verwaltung und Überwachung verwendet wird.
Es bietet auch eine Reihe vordefinierter Operationen auf dem JMX-Agenten, die vom Benutzer ausgeführt werden können. Es ermöglicht die Anzeige und Analyse des Stack-Trace eines Live-Programms. Es kann aus dem /bin-Ordner der Java-Installation gestartet werden.
Mit dem GUI-Tool jconsole können wir den Stack-Trace jedes Threads untersuchen, sobald es mit einem laufenden Java-Prozess verbunden ist. Dann können wir im Tab „Thread“ die Namen aller aktiven Threads sehen. Um einen Deadlock zu erkennen, kann man auf „Deadlock erkennen“ unten rechts im Fenster klicken. Wenn ein Deadlock erkannt wird, wird er in einem neuen Tab angezeigt, andernfalls wird die Meldung „Kein Deadlock erkannt“ angezeigt.
#6. ThreadMxBean
ThreadMXBean ist die Schnittstelle zur Verwaltung des Thread-Systems der Java Virtual Machine, welche zum Paket java.lang.Management gehört. Sie wird hauptsächlich verwendet, um Threads zu identifizieren, die sich in einem Deadlock befinden, und Details dazu zu erhalten.
Die ThreadMxBean-Schnittstelle kann zur programmgesteuerten Erfassung des Thread-Dumps genutzt werden. Die Methode `getThreadMXBean()` von `ManagementFactory` wird verwendet, um eine Instanz der ThreadMXBean-Schnittstelle zu erhalten. Sie gibt die Anzahl sowohl von Daemon- als auch Nicht-Daemon-Live-Threads zurück. `ManagementFactory` ist eine Factory-Klasse zum Abrufen der verwalteten Beans für die Java-Plattform.
private static String getThreadDump (boolean lockMonitors, boolean lockSynchronizers) {
StringBuffer threadDump = new StringBuffer (System.lineSeparator ());
ThreadMXBean threadMXBean = ManagementFactory.getThreadMXBean ();
for (ThreadInfo threadInfo : threadMXBean.dumpAllThreads (lockMonitors, lockSynchronizers)) {
threadDump.append (threadInfo.toString ());
}
return threadDump.toString ();
}
Manuelle Analyse von Thread-Dumps
Die Analyse von Thread-Dumps kann sehr hilfreich sein, um Probleme in Multithread-Prozessen zu identifizieren. Probleme wie Deadlocks, Sperrkonflikte und eine übermäßige CPU-Auslastung können durch die Visualisierung der Zustände einzelner Threads gelöst werden.
Die maximale Leistung einer Anwendung kann durch Korrektur des Status jedes Threads nach der Thread-Dump-Analyse erreicht werden.
Nehmen wir zum Beispiel an, ein Prozess verbraucht viel CPU-Zeit. Wir können herausfinden, ob ein bestimmter Thread die CPU am meisten beansprucht. Wenn das der Fall ist, wandeln wir seine LWP-Nummer in eine Hexadezimalzahl um. Aus dem Thread-Dump kann dann der Thread mit der gleichen nid wie die zuvor erhaltene Hexadezimalzahl gefunden werden. Mit dem Stack-Trace des Threads kann das Problem lokalisiert werden. Die Prozess-ID des Threads wird mit folgendem Befehl ermittelt:
ps -mo pid,lwp,stime,time,cpu -C java
[[email protected] ~]# ps -mo pid,lwp,stime,time,cpu -C java
PID LWP STIME TIME %CPU
26680 - Dec07 00:02:02 99.5
- 10039 Dec07 00:00:00 0.1
- 10040 Dec07 00:00:00 95.5
Werfen wir einen Blick auf den unteren Teil des Thread-Dumps. Um einen Thread-Dump für den Prozess mit der PID 26680 zu erhalten, verwendet man `jstack -l 26680`:
[[email protected] ~]# jstack -l 26680
2020-06-27 09:01:29
<strong>Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.221-b11 mixed mode):</strong>
"Attach Listener" #16287 daemon prio=9 os_prio=0 tid=0x00007f0814001800 nid=0x4ff2 waiting on condition [0x0000000000000000]
java.lang.Thread.State: RUNNABLE
Locked ownable synchronizers:
- None
.
.
.
.
.
.
.
"<strong>Reference Handler</strong>" #2 daemon prio=10 os_prio=0 tid=0x00007f085814a000 nid=0x6840 in Object.wait() [0x00007f083b2f1000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:502)
at java.lang.ref.Reference.tryHandlePending(Reference.java:191)
- locked <0x00000006c790fbd0> (a java.lang.ref.Reference$Lock)
at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:153)
Locked ownable synchronizers:
- None
"VM Thread" os_prio=0 tid=0x00007f0858140800 nid=0x683f runnable
"GC task thread#0 (ParallelGC)" os_prio=0 tid=0x00007f0858021000 nid=0x683b runnable
"GC task thread#1 (ParallelGC)" os_prio=0 tid=0x00007f0858022800 nid=0x683c runnable
"GC task thread#2 (ParallelGC)" os_prio=0 tid=0x00007f0858024800 nid=0x683d runnable
"GC task thread#3 (ParallelGC)" os_prio=0 tid=0x00007f0858026000 nid=0x683e runnable
"VM Periodic Task Thread" os_prio=0 tid=0x00007f08581a0000 nid=0x6847 waiting on condition
JNI global references: 1553
Betrachten wir, welche Informationen uns Thread-Dumps geben können. Wenn man sich den Thread-Dump ansieht, kann der viele Informationen enthalten, die zunächst überwältigend wirken können. Wenn man es jedoch Schritt für Schritt betrachtet, wird es einfacher zu verstehen. Die erste Zeile ist wie folgt:
2020-06-27 09:01:29
Vollständiger Thread-Dump Java HotSpot(TM) 64-Bit Server VM (25.221-b11 gemischter Modus):
Das obige zeigt den Zeitpunkt, zu dem der Dump erzeugt wurde, und Informationen über die verwendete JVM. Als Nächstes sehen wir die Liste der Threads, wobei der erste der ReferenceHandler-Thread ist.
Analyse blockierter Threads
Bei der Analyse von Thread-Dump-Protokollen kann festgestellt werden, dass Threads mit dem Status BLOCKED die Leistung der Anwendung verlangsamen. Wenn die BLOCKED-Threads identifiziert werden, kann man versuchen, die Threads zu extrahieren, die sich auf die Sperren beziehen, welche die Threads zu erlangen versuchen. Die Analyse des Stack-Traces des Threads, der die Sperre gerade hält, kann bei der Lösung des Problems helfen.
[[email protected] ~]# jstack -l 26680
.
.
.
.
" DB-Processor-13" daemon prio=5 tid=0x003edf98 nid=0xca waiting for monitor entry [0x000000000825f000]
java.lang.Thread.State: <strong>BLOCKED</strong> (on object monitor)
at beans.ConnectionPool.getConnection(ConnectionPool.java:102)
- waiting to lock <0xe0375410> (a beans.ConnectionPool)
at beans.cus.ServiceCnt.getTodayCount(ServiceCnt.java:111)
at beans.cus.ServiceCnt.insertCount(ServiceCnt.java:43)
"DB-Processor-14" daemon prio=5 tid=0x003edf98 nid=0xca waiting for monitor entry [0x000000000825f020]
java.lang.Thread.State: <strong>BLOCKED<