Co to jest Thread Dump i jak je analizować?

Porozmawiajmy o zrzucie wątku i o tym, jak go analizować.

Omówimy również, w jaki sposób pomaga zidentyfikować problemy i niektóre analizatory, których możesz użyć.

Co to jest wątek?

Proces to program komputerowy, który jest ładowany do pamięci komputera i jest w trakcie wykonywania. Może być wykonywany przez procesor lub zestaw procesorów. Proces jest opisany w pamięci z ważnymi informacjami, takimi jak magazyny zmiennych, uchwyty plików, licznik programu, rejestry i sygnały, i tak dalej.

Proces może składać się z wielu lekkich procesów zwanych wątkami. Pomaga to osiągnąć równoległość, w której proces jest podzielony na wiele wątków. Skutkuje to lepszą wydajnością. Wszystkie wątki w ramach procesu współdzielą tę samą przestrzeń pamięci i są od siebie zależne.

Zrzuty wątków

Gdy proces jest wykonywany, możemy wykryć bieżący stan wykonywania wątków w procesie za pomocą zrzutów wątków. Zrzut wątku zawiera migawkę wszystkich wątków aktywnych w określonym momencie podczas wykonywania programu. Zawiera wszystkie istotne informacje o wątku i jego aktualnym stanie.

Dzisiejsza nowoczesna aplikacja obejmuje wiele wątków. Każdy wątek wymaga określonych zasobów, wykonuje określone czynności związane z procesem. Może to zwiększyć wydajność aplikacji, ponieważ wątki mogą wykorzystywać dostępne rdzenie procesora.

Istnieją jednak kompromisy, np. czasami wiele wątków może nie współgrać ze sobą i może dojść do impasu. Tak więc, jeśli coś pójdzie nie tak, możemy użyć zrzutów wątków, aby sprawdzić stan naszych wątków.

Zrzut wątku w Javie

Zrzut wątku JVM to lista stanu wszystkich wątków, które są częścią procesu w danym momencie. Zawiera informacje o stosie wątku, przedstawione jako ślad stosu. Ponieważ jest napisany zwykłym tekstem, zawartość można zapisać do późniejszego przejrzenia. Pomocna może być analiza zrzutów wątków

Optymalizacja wydajności JVM
Optymalizacja wydajności aplikacji
Diagnozowanie problemów, np. impas, rywalizacja wątków itp.

Generowanie zrzutów wątków

Istnieje wiele sposobów generowania zrzutów wątków. Poniżej znajduje się kilka narzędzi opartych na JVM, które można uruchomić z wiersza poleceń/terminala (narzędzia CLI) lub katalogu /bin (narzędzia GUI) w folderze instalacyjnym Java.

Zbadajmy je.

# 1. jStos

Najprostszym sposobem wygenerowania zrzutu wątku jest użycie jStack. jStack jest dostarczany z JVM i może być używany z wiersza poleceń. Tutaj potrzebujemy PID procesu, dla którego chcemy wygenerować zrzut wątku. Aby uzyskać PID, możemy użyć polecenia jps, jak pokazano poniżej.

jps -l

jps zawiera listę wszystkich identyfikatorów procesów Java.

W systemie Windows

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

Na Linuksie

[[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 widać tutaj, otrzymujemy listę wszystkich uruchomionych procesów java. Zawiera identyfikator lokalnej maszyny wirtualnej dla uruchomionego procesu java oraz nazwę aplikacji odpowiednio w kolumnach pierwszej i drugiej. Teraz, aby wygenerować zrzut wątku, używamy programu jStack z flagą –l, która tworzy długi wynik zrzutu. Możemy również potokować dane wyjściowe do wybranego przez nas pliku tekstowego.

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 to narzędzie GUI, które pomaga nam rozwiązywać problemy, monitorować i profilować aplikacje Java. Jest również dostarczany z JVM i można go uruchomić z katalogu /bin naszej instalacji java. Jest bardzo intuicyjny i łatwy w użyciu. Wśród innych opcji pozwala nam również przechwycić zrzut wątku dla określonego procesu.

Aby wyświetlić zrzut wątku dla określonego procesu, możemy kliknąć program prawym przyciskiem myszy i wybrać Zrzut wątku z menu kontekstowego.

#3. jcmd

JCMD to narzędzie wiersza poleceń, które jest dostarczane z pakietem JDK i służy do wysyłania żądań poleceń diagnostycznych do maszyny JVM.

Działa jednak tylko na komputerze lokalnym, na którym działa aplikacja Java. Może być używany do kontrolowania Java Flight Recordings, diagnozowania i rozwiązywania problemów z aplikacjami JVM i Java. Możemy użyć polecenia Thread.print jcmd, aby uzyskać listę zrzutów wątków dla określonego procesu określonego przez PID.

Poniżej znajduje się przykład, jak możemy użyć 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 to skrót od Java Mission Control. Jest to narzędzie GUI typu open source, które jest dostarczane z JDK i służy do zbierania i analizowania danych aplikacji Java.

Można go uruchomić z folderu /bin naszej instalacji Java. Administratorzy i programiści języka Java używają tego narzędzia do zbierania szczegółowych informacji niskiego poziomu na temat zachowań maszyny JVM i aplikacji. Umożliwia szczegółową i wydajną analizę danych gromadzonych przez Java Flight Recorder.

Po uruchomieniu jmc możemy zobaczyć listę procesów Java, które są uruchomione na komputerze lokalnym. Możliwe jest również zdalne połączenie. W konkretnym procesie możemy kliknąć prawym przyciskiem myszy i wybrać Rozpocznij nagrywanie lotu, a następnie sprawdzić zrzuty wątków na karcie Wątki.

#5. jkonsola

jconsole to narzędzie Java Management Extension służące do zarządzania reklamacjami i monitorowania.

Posiada również zestaw predefiniowanych operacji na agencie JMX, które użytkownik może wykonać. Umożliwia użytkownikowi wykrywanie i analizowanie śledzenia stosu programu na żywo. Można go uruchomić z folderu /bin naszej instalacji Java.

Korzystając z narzędzia GUI jconsole, możemy sprawdzić ślad stosu każdego wątku, gdy łączymy go z uruchomionym procesem java. Następnie w zakładce Thread możemy zobaczyć nazwy wszystkich uruchomionych wątków. Aby wykryć zakleszczenie, możemy kliknąć Wykryj zakleszczenie w prawym dolnym rogu okna. Jeśli zostanie wykryty zakleszczenie, pojawi się ono w nowej karcie, w przeciwnym razie zostanie wyświetlony komunikat Nie wykryto zakleszczenia.

#6. ThreadMxBean

ThreadMXBean to interfejs do zarządzania systemem wątków wirtualnej maszyny Java należącej do pakietu java.lang.Management. Służy głównie do wykrywania wątków, które znalazły się w sytuacji zakleszczenia i uzyskiwania szczegółowych informacji na ich temat.

Możemy użyć interfejsu ThreadMxBean do programowego przechwycenia zrzutu wątku. getThreadMXBean() metoda ManagementFactory służy do pobierania instancji interfejsu ThreadMXBean. Zwraca liczbę żywych wątków zarówno demonów, jak i nie-demonów. ManagementFactory to klasa fabryczna służąca do pobierania zarządzanych komponentów bean dla platformy 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 ();
}

Ręczna analiza zrzutów wątków

Analiza zrzutów wątków może być bardzo przydatna w określaniu problemów w procesach wielowątkowych. Problemy, takie jak zakleszczenia, rywalizacja o blokadę i nadmierne wykorzystanie procesora przez zrzuty poszczególnych wątków, można rozwiązać, wizualizując stany zrzutów poszczególnych wątków.

Maksymalną przepustowość z aplikacji można osiągnąć, korygując status każdego wątku po przeanalizowaniu zrzutu wątku.

Na przykład, powiedzmy, że proces zużywa dużo procesora, możemy dowiedzieć się, czy jakiś wątek najbardziej wykorzystuje procesor. Jeśli istnieje taki wątek, zamieniamy jego numer LWP na liczbę szesnastkową. Następnie ze zrzutu wątku możemy znaleźć wątek o nid równym uzyskanej wcześniej liczbie szesnastkowej. Korzystając ze śladu stosu wątku, możemy wskazać problem. Znajdźmy identyfikator procesu wątku za pomocą poniższego polecenia.

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

Rzućmy okiem na poniższy fragment zrzutu wątku. Aby uzyskać zrzut wątku dla procesu 26680, użyj 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

Zobaczmy teraz, jakie rzeczy możemy eksplorować za pomocą zrzutów wątków. Jeśli obserwujemy zrzut wątku, możemy zobaczyć wiele treści, które mogą być przytłaczające. Jeśli jednak zrobimy krok po kroku, może to być dość łatwe do zrozumienia. Rozumiemy pierwszą linię

2020-06-27 09:01:29
Pełny zrzut wątku Java HotSpot(TM) 64-bitowy serwer VM (tryb mieszany 25.221-b11):

Powyższe wyświetla czas wygenerowania zrzutu oraz informacje o używanej maszynie JVM. Następnie na końcu możemy zobaczyć listę wątków, pierwszym z nich jest nasz wątek ReferenceHandler.

Analiza zablokowanych wątków

Jeśli przeanalizujemy poniższe dzienniki zrzutu wątku, możemy stwierdzić, że wykryto wątki ze stanem ZABLOKOWANY, co bardzo spowalnia działanie aplikacji. Jeśli więc uda nam się znaleźć ZABLOKOWANE wątki, możemy spróbować wyodrębnić wątki związane z blokadami, które próbują uzyskać. Analiza śladu stosu z wątku aktualnie utrzymującego blokadę może pomóc w rozwiązaniu problemu.

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

Analiza zakleszczonego wątku

Innym bardzo często używanym zastosowaniem zrzutów wątków jest wykrywanie zakleszczeń. Wykrywanie i rozwiązywanie zakleszczeń może być dużo łatwiejsze, jeśli przeanalizujemy zrzuty wątków.

Zakleszczenie to sytuacja obejmująca co najmniej dwa wątki, w której zasób wymagany przez jeden wątek do kontynuowania wykonywania jest zablokowany przez inny wątek, a jednocześnie zasób wymagany przez drugi wątek jest zablokowany przez pierwszy wątek.

Tak więc żaden z wątków nie może kontynuować wykonywania, co skutkuje zakleszczeniem i kończy się zablokowaniem aplikacji. Jeśli obecne są dredy, ostatnia sekcja zrzutu wątku wydrukuje informacje dotyczące impasu w następujący sposób.

"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)

Tutaj możemy zobaczyć informacje o zakleszczeniu w formacie czytelnym dla człowieka.

Poza tym, jeśli zsumujemy razem wszystkie powyższe części zrzutu wątku, to zawiera ona poniższe informacje.

Program obsługi odwołań to czytelna dla człowieka nazwa wątku.
#2 to unikalny identyfikator wątku.
demon wskazuje, czy wątek jest wątkiem demona.
Priorytet numeryczny wątku jest określony przez prio=10.
Bieżący stan wątku jest oznaczony przez warunek oczekiwania.
Następnie widzimy ślad stosu, który zawiera informacje o blokowaniu.

Analizatory zrzutów wątków

Oprócz analizy ręcznej dostępnych jest wiele narzędzi do analizy zrzutów wątków, zarówno online, jak i offline. Poniżej znajdują się niektóre z wymienionych narzędzi, których możemy użyć w zależności od wymagań.

Najpierw przyjrzyjmy się narzędziom online.

# 1. Szybki wątek

Szybki wątek to ulubione narzędzie inżyniera DevOps do analizy zrzutów wątków do rozwiązywania złożonych problemów produkcyjnych. To jest internetowy analizator zrzutu wątku Java. Możemy przesłać zrzut wątku jako plik lub możemy bezpośrednio skopiować i wkleić zrzut wątku.

W zależności od rozmiaru przeanalizuje zrzut wątku i wyświetli informacje, jak pokazano na zrzucie ekranu.

Cechy

Rozwiązywanie problemów z awariami JVM, spowolnieniami, wyciekami pamięci, zawieszaniem się, skokami procesora
Natychmiastowe RCA (nie czekaj na sprzedawców)
Intuicyjny pulpit nawigacyjny
Obsługa API REST
Nauczanie maszynowe

#2. Analizator zrzutów wątków Spotify

The Analizator zrzutów wątków Spotify jest licencjonowany w ramach wersji 2.0 licencji Apache. Jest to narzędzie online i akceptuje zrzut wątku jako plik lub możemy bezpośrednio skopiować i wkleić zrzut wątku. W zależności od rozmiaru przeanalizuje zrzut wątku i wyświetli informacje, jak pokazano na zrzucie ekranu.

#3. Recenzja Jstacka

Recenzja Jstack analizuje zrzuty wątków Java z poziomu przeglądarki. Ta strona jest dostępna tylko po stronie klienta.

#4. Strona 24×7

Ten narzędzie jest warunkiem wstępnym wykrywania wadliwych wątków obniżających wydajność Java Virtual Machine (JVM). Problemy, takie jak zakleszczenia, rywalizacja o blokadę i nadmierne wykorzystanie procesora przez zrzuty poszczególnych wątków, można rozwiązać, wizualizując stany zrzutów poszczególnych wątków.

Maksymalną przepustowość z aplikacji można osiągnąć, korygując stan każdego wątku dostarczonego przez narzędzie.

Przyjrzyjmy się teraz narzędziom offline.

Jeśli chodzi o profilowanie, tylko najlepsze narzędzie jest wystarczająco dobre.

# 1. JProfiler

JProfiler jest jednym z najpopularniejszych analizatorów zrzutów wątków wśród programistów Java. Intuicyjny interfejs użytkownika JProfiler pomaga rozwiązać wąskie gardła wydajności, zlokalizować wycieki pamięci i zrozumieć problemy z wątkami.

JProfiler obsługuje profilowanie na następujących platformach:

Okna
System operacyjny Mac
Linuks
FreeBSD
Solaris
AIX
HP-UX

Poniżej znajduje się kilka funkcji, które sprawiają, że JProfiler jest najlepszym wyborem do profilowania naszych aplikacji na maszynie JVM.

Cechy

Obsługuje profilowanie baz danych dla JDBC, JPA i NoSQL
Dostępna jest również obsługa wersji Java Enterprise
Przedstawia ogólne informacje o wywołaniach RMI
Gwiezdna analiza wycieków pamięci
Rozbudowane możliwości kontroli jakości
Zintegrowany program do profilowania wątków jest ściśle zintegrowany z widokami profilowania procesora.
Wsparcie dla platform, IDE i serwerów aplikacji.

#2. IBMTMDA

IBM Thread and Monitor Dump Analyzer for Java (TMDA) to narzędzie, które umożliwia identyfikację zawieszeń, zakleszczeń, rywalizacji o zasoby i wąskich gardeł w zrzutach wątków Java. Jest to produkt IBM, ale narzędzie TMDA jest dostarczane bez żadnej gwarancji ani wsparcia; jednak z czasem próbują naprawić i ulepszyć narzędzie.

#3. Zarządzaj silnikiem

Zarządzaj silnikiem Menedżer aplikacji może pomóc w monitorowaniu pamięci JVM Heap i Non-Heap. Możemy nawet skonfigurować progi i otrzymywać powiadomienia e-mailem, SMS-em itp., a także upewnić się, że aplikacja Java jest dobrze dostrojona.

#4. TwójZestaw

TwójZestaw składa się z poniższych produktów o nazwie it as a Kit.

Java Profiler — w pełni funkcjonalny, niskonakładowy profiler dla platform Java EE i Java SE.
YouMonitor – Monitorowanie wydajności i profilowanie Jenkins, TeamCity, Gradle, Maven, Ant, JUnit i TestNG.
.NET Profiler — łatwy w użyciu profiler wydajności i pamięci dla platformy .NET.

Wniosek

Teraz już wiesz, jak zrzuty wątków są przydatne w zrozumieniu i diagnozowaniu problemów w aplikacjach wielowątkowych. Z właściwym wiedzajeśli chodzi o zrzuty wątków – ich strukturę, zawarte w nich informacje itd. – możemy je wykorzystać do szybkiej identyfikacji przyczyn problemów.