Co je Thread Dump a jak je analyzovat?

Pojďme si promluvit o výpisu vláken a jak jej analyzovat.

Budeme také diskutovat o tom, jak pomáhá určit problémy, a o některých analyzátorech, které můžete použít.

Co je vlákno?

Proces je počítačový program, který je načten do paměti počítače a je právě prováděn. Může být vykonáván procesorem nebo sadou procesorů. Proces je popsán v paměti s důležitými informacemi, jako jsou úložiště proměnných, popisovač souborů, čítač programu, registry a signály atd.

Proces se může skládat z mnoha odlehčených procesů nazývaných vlákna. To pomáhá dosáhnout paralelismu, kdy je proces rozdělen do více vláken. Výsledkem je lepší výkon. Všechna vlákna v rámci procesu sdílejí stejný paměťový prostor a jsou na sobě závislá.

Zásobníky nití

Když se proces provádí, můžeme zjistit aktuální stav provádění vláken v procesu pomocí výpisů vláken. Výpis vláken obsahuje snímek všech vláken aktivních v určitém bodě během provádění programu. Obsahuje všechny relevantní informace o vláknu a jeho aktuálním stavu.

Moderní aplikace dnes zahrnuje vícenásobný počet vláken. Každé vlákno vyžaduje určité zdroje, provádí určité činnosti související s procesem. To může zvýšit výkon aplikace, protože vlákna mohou využívat dostupná jádra CPU.

Existují však určité kompromisy, např. někdy se může stát, že více vláken spolu nebude dobře koordinovat a může dojít k uváznutí. Takže pokud se něco pokazí, můžeme použít výpisy vláken ke kontrole stavu našich vláken.

Výpis vlákna v Javě

Výpis vláken JVM je výpis stavu všech vláken, která jsou součástí procesu v daném okamžiku. Obsahuje informace o zásobníku vlákna, prezentované jako trasování zásobníku. Protože je napsán v otevřeném textu, obsah lze uložit pro pozdější kontrolu. Analýza výpisů vláken může pomoci

  • Optimalizace výkonu JVM
  • Optimalizace výkonu aplikace
  • Diagnostika problémů, např. uváznutí, spory vláken atd.

Generování výsypů nití

Existuje mnoho způsobů, jak generovat výpisy vláken. Níže jsou uvedeny některé nástroje založené na JVM a lze je spustit z příkazového řádku/terminálu (nástroje CLI) nebo adresáře /bin (nástroje GUI) instalační složky Java.

Pojďme je prozkoumat.

#1. jStack

Nejjednodušší způsob, jak vygenerovat výpis vlákna, je pomocí jStack. jStack se dodává s JVM a lze jej použít z příkazového řádku. Zde potřebujeme PID procesu, pro který chceme generovat výpis vlákna. K získání PID můžeme použít příkaz jps, jak je uvedeno níže.

jps -l

jps uvádí všechna ID procesů Java.

V systému Windows

C:Program FilesJavajdk1.8.0_171bin>jps -l
47172 portal
6120 sun.tools.jps.Jps
C:Program FilesJavajdk1.8.0_171bin>

Na Linuxu

[[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] ~]#

Jak můžeme vidět zde, dostáváme seznam všech běžících java procesů. Obsahuje místní ID virtuálního počítače pro běžící proces Java a název aplikace ve sloupcích jedna a dva. Nyní, abychom vygenerovali výpis vlákna, použijeme program jStack s příznakem –l, který vytvoří dlouhý výpis výpisu. Můžeme také výstup převést do nějakého textového souboru dle našeho výběru.

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 je nástroj GUI, který nám pomáhá odstraňovat problémy, monitorovat a profilovat Java aplikace. Dodává se také s JVM a lze jej spustit z adresáře /bin naší java instalace. Je velmi intuitivní a snadno se používá. Kromě jiných možností nám také umožňuje zachytit výpis vlákna pro konkrétní proces.

Chcete-li zobrazit výpis vlákna pro konkrétní proces, můžeme kliknout pravým tlačítkem myši na program a z kontextové nabídky vybrat položku Thread Dump.

  Jak povolit tmavý režim na vašem iPhone a iPad

#3. jcmd

JCMD je obslužný program příkazového řádku, který se dodává s JDK a používá se k odesílání požadavků na diagnostické příkazy do JVM.

Funguje však pouze na místním počítači, kde běží Java aplikace. Lze jej použít k ovládání Java Flight Recordings, diagnostice a odstraňování problémů s aplikacemi JVM a Java. Můžeme použít příkaz Thread.print jcmd k získání seznamu výpisů vláken pro konkrétní proces určený PID.

Níže je uveden příklad, jak můžeme použít jcmd.

jcmd 28036 Závit.tisk

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 znamená Java Mission Control. Jedná se o open-source nástroj GUI, který je dodáván s JDK a používá se ke sběru a analýze dat java aplikací.

Lze jej spustit ze složky /bin naší instalace Java. Správci a vývojáři Java používají tento nástroj ke shromažďování podrobných nízkoúrovňových informací o chování JVM a aplikací. Umožňuje detailní a efektivní analýzu dat shromážděných Java Flight Recorder.

Při spuštění jmc vidíme seznam java procesu, který běží na místním počítači. Možné je i vzdálené připojení. U konkrétního procesu můžeme kliknout pravým tlačítkem a vybrat Spustit záznam letu a poté zkontrolovat výpisy vláken na kartě Vlákna.

#5. jconsole

jconsole je nástroj Java Management Extension používaný pro správu a monitorování stížností.

Má také sadu předdefinovaných operací s agentem JMX, které může uživatel provádět. Umožňuje uživateli detekovat a analyzovat stopu zásobníku živého programu. Lze jej spustit ze složky /bin naší instalace Java.

Pomocí nástroje GUI jconsole můžeme zkontrolovat trasování zásobníku každého vlákna, když jej připojíme k běžícímu procesu Java. V záložce Thread pak můžeme vidět názvy všech běžících vláken. Pro detekci zablokování můžeme kliknout na Detect Deadlock v pravé dolní části okna. Pokud je detekováno zablokování, objeví se na nové kartě, jinak se zobrazí Bez zablokování.

  Jak fotit časosběrnou zrcadlovkou nebo bezzrcadlovkou

#6. ThreadMxBean

ThreadMXBean je rozhraní pro správu systému vláken virtuálního stroje Java patřícího do balíčku java.lang.Management. Používá se hlavně k detekci vláken, která se dostala do zablokování, a získání podrobností o nich.

K programovému zachycení výpisu vlákna můžeme použít rozhraní ThreadMxBean. Metoda getThreadMXBean() ManagementFactory se používá k získání instance rozhraní ThreadMXBean. Vrací počet živých vláken démona i jiných vláken. ManagementFactory je tovární třída pro získávání spravovaných beanů pro platformu Java.

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 ();
}

Manuální analýza výsypů nití

Analýza výpisů vláken může být velmi užitečná při určování problémů ve vícevláknových procesech. Problémy, jako jsou uváznutí, spory o uzamčení a nadměrné vytížení procesoru výpisy jednotlivých vláken, lze vyřešit vizualizací stavů výpisů jednotlivých vláken.

Maximální propustnost z aplikace lze dosáhnout opravou stavu každého vlákna po analýze výpisu stavu vlákna.

Řekněme například, že proces zabírá hodně CPU, můžeme zjistit, jestli nějaké vlákno nejvíce využívá CPU. Pokud nějaké takové vlákno existuje, převedeme jeho číslo LWP na hexadecimální číslo. Potom z výpisu vlákna můžeme najít vlákno s nid rovným dříve získanému hexadecimálnímu číslu. Pomocí trasování zásobníku vlákna můžeme určit problém. Pojďme zjistit ID procesu vlákna pomocí níže uvedeného příkazu.

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

Podívejme se níže na výpis nití. Chcete-li získat výpis vlákna pro proces 26680, použijte 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

Nyní se podívejme, jaké věci můžeme prozkoumat pomocí výpisů vláken. Pokud pozorujeme výpis vláken, můžeme vidět spoustu obsahu, který může být ohromující. Pokud však uděláme jeden krok za druhým, může být docela snadné to pochopit. Pojďme pochopit první řádek

27. 6. 2020 9:01:29
Úplný výpis vlákna Java HotSpot(TM) 64-Bit Server VM (25.221-b11 smíšený režim):

Výše uvedené zobrazuje čas vygenerování výpisu a informace o použitém JVM. Dále, na konci, můžeme vidět seznam vláken, první z nich je naše vlákno ReferenceHandler.

Analýza blokovaných vláken

Pokud analyzujeme níže uvedené protokoly výpisu podprocesů, zjistíme, že zjistila vlákna se stavem BLOCKED, což velmi zpomaluje výkon aplikace. Pokud tedy najdeme BLOKOVANÁ vlákna, můžeme se pokusit extrahovat vlákna související se zámky, které se vlákna snaží získat. Analýza trasování zásobníku z vlákna, které aktuálně drží zámek, může pomoci při řešení problému.

[[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</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)
.
.
.
.

Analýza uvázlého vlákna

Další velmi často používanou aplikací výpisů vláken je detekce uváznutí. Detekce a řešení zablokování může být mnohem jednodušší, pokud analyzujeme výpisy vláken.

Zablokování je situace zahrnující alespoň dvě vlákna, kdy prostředek požadovaný jedním vláknem pro pokračování ve vykonávání je uzamčen jiným vláknem a zároveň je prostředek požadovaný druhým vláknem uzamčen prvním vláknem.

Žádné z vláken tedy nemůže pokračovat v provádění, což má za následek zablokování a končí uvíznutím aplikace. Pokud jsou přítomny dredy, pak poslední část výpisu vlákna vytiskne informace týkající se zablokování následovně.

"Thread-0":
waiting to lock monitor 0x00000250e4982480 (object 0x00000000894465b0, a java.lang.Object),
which is held by "Thread-1"
"Thread-1":
waiting to lock monitor 0x00000250e4982380 (object 0x00000000894465a0, a java.lang.Object),
which is held by "Thread-0"
.
.
.
"Thread-0":
at DeadlockedProgram$DeadlockedRunnableImplementation.run(DeadlockedProgram.java:34)
- waiting to lock <0x00000000894465b0> (a java.lang.Object)
- locked <0x00000000894465a0> (a java.lang.Object)
at java.lang.Thread.run([email protected]/Thread.java:844)
"Thread-1":
at DeadlockedProgram $DeadlockRunnableImplementation.run(DeadlockedProgram.java:34)
- waiting to lock <0x00000000894465a0> (a java.lang.Object)
- locked <0x00000000894465b0> (a java.lang.Object)
at java.lang.Thread.run([email protected]/Thread.java:844)

Zde můžeme vidět informace o uváznutí v poměrně dobře čitelném formátu.

  Jak nastavit výchozí hodnoty programu v KDE Plasma 5

Kromě toho, pokud shrneme všechny výše uvedené části výpisu vláken dohromady, pak uvádí níže uvedené informace.

  • Obslužná rutina reference je pro člověka čitelný název vlákna.
  • #2 je jedinečné ID vlákna.
  • daemon označuje, zda je vlákno vláknem démona.
  • Číselná priorita vlákna je dána prio=10.
  • Aktuální stav vlákna je označen jako čekání na podmínku.
  • Poté vidíme trasování zásobníku, které obsahuje informace o zamykání.

Analyzátory výsypů nití

Kromě ruční analýzy je k dispozici řada nástrojů pro analýzu výpisů vláken, online i offline. Níže jsou uvedeny některé z uvedených nástrojů, které můžeme použít na základě požadavků.

Nejprve se podívejme na online nástroje.

#1. Rychlá nit

Rychlé vlákno je oblíbený nástroj pro analýzu výpisu stavu vláken inženýra DevOps pro řešení složitých produkčních problémů. Toto je online analyzátor výpisu stavu vláken Java. Výpis vlákna můžeme nahrát jako soubor nebo můžeme výpis přímo zkopírovat a vložit.

V závislosti na velikosti analyzuje výpis vlákna a zobrazí informace, jak je znázorněno na snímku obrazovky.

Funkce

  • Odstraňte problémy s pády JVM, zpomaleními, úniky paměti, zamrzáním, špičkami CPU
  • Okamžité RCA (nečekejte na prodejce)
  • Intuitivní ovládací panel
  • Podpora REST API
  • Strojové učení

#2. Spotify Thread Dump Analyzer

The Spotify Thread Dump Analyzer je licencován pod verzí 2.0 licence Apache. Je to online nástroj a přijímá výpis vlákna jako soubor nebo můžeme výpis vlákna přímo zkopírovat a vložit. V závislosti na velikosti analyzuje výpis vlákna a zobrazí informace, jak je znázorněno na snímku obrazovky.

#3. Jstack recenze

Jstack.review analyzuje výpisy java vláken z prohlížeče. Tato stránka je pouze na straně klienta.

#4. Stránky 24×7

Tento nástroj je nezbytným předpokladem pro detekci vadných vláken snižujících výkon Java Virtual Machine (JVM). Problémy, jako jsou uváznutí, spory o uzamčení a nadměrné vytížení procesoru výpisy jednotlivých vláken, lze vyřešit vizualizací stavů výpisů jednotlivých vláken.

Maximální propustnost z aplikace lze dosáhnout opravou stavu každého vlákna poskytovaného nástrojem.

Nyní se podívejme na offline nástroje.

Pokud jde o profilování, jen ten nejlepší nástroj je dost dobrý.

#1. JProfiler

JProfiler je jedním z nejpopulárnějších analyzátorů výpisu vláken mezi vývojáři v Javě. Intuitivní uživatelské rozhraní JProfiler vám pomůže vyřešit problémová místa ve výkonu, odstranit úniky paměti a porozumět problémům s vlákny.

JProfiler podporuje profilování na následujících platformách:

  • Okna
  • Operační Systém Mac
  • Linux
  • FreeBSD
  • Solaris
  • AIX
  • HP-UX

Níže jsou uvedeny některé funkce, díky kterým je JProfiler nejlepší volbou pro profilování našich aplikací na JVM.

Funkce

  • Podporuje profilování databáze pro JDBC, JPA a NoSQL
  • K dispozici je také podpora pro Java Enterprise Edition
  • Poskytuje informace na vysoké úrovni o voláních RMI
  • Hvězdná analýza úniků paměti
  • Rozsáhlé možnosti QA
  • Integrovaný profilovač závitů je těsně integrován s pohledy na profilování CPU.
  • Podpora platforem, IDE a aplikačních serverů.

#2. IBM TMDA

IBM Thread and Monitor Dump Analyzer for Java (TMDA) je nástroj, který umožňuje identifikovat zablokování, zablokování, spory o zdroje a úzká místa ve výpisech vláken Java. Je to produkt IBM, ale nástroj TMDA je poskytován bez jakékoli záruky nebo podpory; pokoušejí se však nástroj časem opravit a vylepšit.

#3. ManageEngine

ManageEngine Správce aplikací může pomoci monitorovat paměť haldy JVM a paměti bez haldy. Můžeme dokonce nakonfigurovat prahové hodnoty a být upozorňováni e-mailem, SMS atd. a zajistit, aby aplikace Java byla dobře vyladěna.

#4. YourKit

YourKit sestává z níže uvedených produktů nazývaných jako Kit.

  • Java Profiler – Plně vybavený profiler s nízkou režií pro platformy Java EE a Java SE.
  • YouMonitor – Sledování výkonu a profilování Jenkins, TeamCity, Gradle, Maven, Ant, JUnit a TestNG.
  • .NET Profiler – Snadno použitelný profilovač výkonu a paměti pro .NET framework.

Závěr

Nyní víte, jak jsou výpisy vláken užitečné pro pochopení a diagnostiku problémů ve vícevláknových aplikacích. S řádným znalostpokud jde o výpisy vláken – jejich strukturu, informace v nich obsažené atd. – můžeme je využít k rychlé identifikaci příčin problémů.

x