Hva er Thread Dump og hvordan analysere dem?

by
Tweet
Share
Share
Pin
0 Shares

La oss snakke om tråddumpen, og hvordan du analyserer den.

Vi vil også diskutere hvordan det hjelper å finne problemene og noe av analysatoren du kan bruke.

Hva er tråd?

En prosess er et dataprogram som lastes inn i datamaskinens minne og er under utførelse. Det kan utføres av en prosessor eller et sett med prosessorer. En prosess er beskrevet i minnet med viktig informasjon som variable lagre, filhåndtak, programteller, registre og, signaler, og så videre.

En prosess kan bestå av mange lette prosesser kalt tråder. Dette bidrar til å oppnå parallellitet der en prosess er delt inn i flere tråder. Dette gir bedre ytelse. Alle trådene i en prosess deler samme minneplass og er avhengige av hverandre.

Tråddumper

Når prosessen kjører, kan vi oppdage gjeldende utførelsestilstand for trådene i prosessen ved å bruke tråddumper. En tråddump inneholder et øyeblikksbilde av alle trådene som er aktive på et bestemt punkt under kjøringen av et program. Den inneholder all relevant informasjon om tråden og dens nåværende tilstand.

En moderne applikasjon i dag involverer flere antall tråder. Hver tråd krever visse ressurser, utfører visse aktiviteter relatert til prosessen. Dette kan øke ytelsen til en applikasjon ettersom tråder kan bruke tilgjengelige CPU-kjerner.

Men det er avveininger, f.eks. kan det hende at flere tråder ikke koordinerer godt med hverandre og at det kan oppstå en fastlåst situasjon. Så hvis noe går galt, kan vi bruke tråddumper for å inspisere tilstanden til trådene våre.

Tråddump i Java

En JVM-tråddump er en liste over tilstanden til alle tråder som er en del av prosessen på det bestemte tidspunktet. Den inneholder informasjon om trådens stabel, presentert som et stabelspor. Som det er skrevet i klartekst, kan innholdet lagres for gjennomgang senere. Analyse av tråddumper kan hjelpe

  • Optimalisering av JVM-ytelse
  • Optimalisering av applikasjonsytelse
  • Diagnostisering av problemer, f.eks. låsing, trådstrid osv.

Generering av tråddumper

Det er mange måter å generere tråddumper på. Nedenfor er noen JVM-baserte verktøy og kan kjøres fra kommandolinjen/terminalen (CLI-verktøy) eller katalogen /bin (GUI-verktøy) i installasjonsmappen til Java.

La oss utforske dem.

#1. jStack

Den enkleste måten å generere en tråddump på er ved å bruke jStack. jStack leveres med JVM og kan brukes fra kommandolinjen. Her trenger vi PID-en til prosessen som vi ønsker å generere tråddumpen for. For å få PID kan vi bruke jps-kommandoen som vist nedenfor.

jps -l

jps lister ned alle java-prosess-IDer.

På Windows

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

På 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] ~]#

Som vi kan se her, får vi en liste over alle java-prosesser som kjører. Den inneholder den lokale VM-IDen for den kjørende java-prosessen og navnet på applikasjonen i henholdsvis kolonne én og to. Nå, for å generere tråddumpen, bruker vi jStack-programmet med –l-flagg som lager en lang listet utgang av dumpen. Vi kan også overføre utdataene til en tekstfil etter eget valg.

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 er et GUI-verktøy som hjelper oss med å feilsøke, overvåke og profilere Java-applikasjoner. Den kommer også med JVM og kan startes fra /bin-katalogen til vår java-installasjon. Den er veldig intuitiv og enkel å bruke. Blant andre alternativer lar det oss også fange tråddump for en bestemt prosess.

  Hva er en "Qi-sertifisert" trådløs lader?

For å se tråddumpen for en bestemt prosess kan vi høyreklikke på programmet og velge Thread Dump fra kontekstmenyen.

#3. jcmd

JCMD er et kommandolinjeverktøy som følger med JDK og brukes til å sende diagnostiske kommandoforespørsler til JVM.

Det fungerer imidlertid bare på den lokale maskinen der Java-applikasjonen kjører. Den kan brukes til å kontrollere Java Flight Recordings, diagnostisere og feilsøke JVM- og Java-applikasjoner. Vi kan bruke Thread.print-kommandoen til jcmd for å få en liste over tråddumper for en bestemt prosess spesifisert av PID.

Nedenfor er et eksempel på hvordan vi kan bruke 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 står for Java Mission Control. Det er et åpen kildekode GUI-verktøy som leveres med JDK og brukes til å samle inn og analysere Java-applikasjonsdata.

Den kan startes fra mappen /bin i Java-installasjonen vår. Java-administratorer og utviklere bruker verktøyet til å samle detaljert lavnivåinformasjon om JVM-en og applikasjonens oppførsel. Den muliggjør detaljert og effektiv analyse av data samlet inn av Java Flight Recorder.

Ved lansering av jmc kan vi se en liste over java-prosessen som kjører på den lokale maskinen. En ekstern tilkobling er også mulig. På en bestemt prosess kan vi høyreklikke og velge Start Flight Recording og deretter sjekke tråddumpene i Threads-fanen.

#5. jconsole

jconsole er et Java Management Extension-verktøy som brukes til klagebehandling og overvåking.

Den har også et sett med forhåndsdefinerte operasjoner på JMX-agenten som brukeren kan utføre. Den gjør det mulig for brukeren å oppdage og analysere stabelsporing av et live program. Den kan startes fra mappen /bin i Java-installasjonen vår.

  Slik bruker du styreflatemodus på iPhone og iPad for å velge tekst

Ved å bruke jconsole GUI-verktøyet kan vi inspisere hver tråds stabelsporing når vi kobler den til en kjørende java-prosess. Deretter, i Tråd-fanen, kan vi se navnet på alle løpende tråder. For å oppdage en dødlås, kan vi klikke på Oppdag dødlås nederst til høyre i vinduet. Hvis en vreklås oppdages, vil den vises i en ny fane, ellers vises en vreklås.

#6. ThreadMxBean

ThreadMXBean er grensesnittet for administrasjon av trådsystemet til den virtuelle Java-maskinen som tilhører java.lang.Management-pakken. Den brukes hovedsakelig til å oppdage tråder som har havnet i en fastlåst situasjon og få detaljer om dem.

Vi kan bruke ThreadMxBean-grensesnittet til å programmere fange tråddumpen. getThreadMXBean()-metoden til ManagementFactory brukes for å få en forekomst av ThreadMXBean-grensesnittet. Den returnerer antall live-tråder fra både demoner og ikke-demoner. ManagementFactory er en fabrikkklasse for å få de administrerte bønner for Java-plattformen.

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

Manuell analyse av tråddumper

Analyse av tråddumper kan være svært nyttig for å finne problemer i flertrådede prosesser. Problemer som vranglås, låsestrid og overdreven CPU-utnyttelse av individuelle tråddumper kan løses ved å visualisere tilstandene til individuelle tråddumper.

Maksimal gjennomstrømning fra applikasjonen kan oppnås ved å rette opp statusen til hver tråd etter å ha analysert tråddumpen.

La oss for eksempel si at en prosess bruker mye CPU, vi kan finne ut om en tråd bruker CPUen mest. Hvis det er en slik tråd, konverterer vi LWP-nummeret til et heksadesimalt tall. Så fra tråddumpen kan vi finne tråden med nid lik det tidligere oppnådde heksadesimale tallet. Ved å bruke stabelsporet til tråden kan vi finne problemet. La oss finne ut prosess-ID-en til tråden ved å bruke kommandoen nedenfor.

ps -mo pid,lwp,stime,tid,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

La oss ta en titt på delen av tråddumpen nedenfor. For å få tråddump for prosess 26680, bruk 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

La oss nå se hva vi kan utforske ved å bruke tråddumper. Hvis vi observerer tråddumpen, kan vi se mye innhold, som kan være overveldende. Men hvis vi tar ett skritt om gangen, kan det være ganske enkelt å forstå. La oss forstå den første linjen

2020-06-27 09:01:29
Full tråddump Java HotSpot(TM) 64-bit server VM (25.221-b11 blandet modus):

Ovenstående viser tidspunktet dumpen ble generert, og informasjon om JVM som ble brukt. Deretter, til slutt, kan vi se listen over tråder, den første blant dem er vår ReferenceHandler-tråd.

Analysere blokkerte tråder

Hvis vi analyserer tråddumploggene nedenfor, kan vi finne at den har oppdaget tråder med BLOKKERT status som gjør ytelsen til en applikasjon veldig treg. Så hvis vi kan finne de BLOKKEREDE trådene, kan vi prøve å trekke ut trådene relatert til låsene som trådene prøver å få tak i. Analyse av stabelsporet fra tråden som for øyeblikket holder låsen kan hjelpe til med å løse problemet.

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

Analyserer fastlåst tråd

En annen svært vanlig bruk av tråddumper er deteksjon av vranglåser. Deteksjon og løsning av vranglåser kan bli mye enklere hvis vi analyserer tråddumpene.

  10 kundeserviceplattformer for å øke oppbevaringsraten

En deadlock er en situasjon som involverer minst to tråder der ressursen som kreves av en tråd for å fortsette utførelse er låst av en annen tråd og samtidig er ressursen som kreves av den andre tråden låst av den første tråden.

Så ingen av trådene kan fortsette kjøringen, og dette resulterer i en dødlåssituasjon og ender i at applikasjonen setter seg fast. Hvis dreadlocks er tilstede, vil den siste delen av tråddumpen skrive ut informasjonen om dødlåsen som følger.

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

Her kan vi se dødlåsinformasjonen i et ganske menneskelig lesbart format.

Bortsett fra dette, hvis vi oppsummerer alle de ovennevnte delene av tråddump sammen, så står det informasjonen nedenfor.

  • Referansebehandler er det menneskelesbare navnet på tråden.
  • #2 er trådens unike id.
  • daemon angir om tråden er en daemon-tråd.
  • Trådens numeriske prioritet er gitt av prio=10.
  • Gjeldende status for tråden angis ved å vente på betingelse.
  • Så ser vi stabelsporet, som inkluderer låseinformasjonen.

Tråddump-analysatorer

Foruten manuell analyse, er det mange verktøy tilgjengelig for å analysere tråddumper, både online og offline. Nedenfor er noen av de listede verktøyene, som vi kan bruke basert på kravene.

La oss først utforske nettbaserte verktøy.

#1. Rask tråd

Rask tråd er DevOps-ingeniørens favoritt-tråddumpanalyseverktøy for å feilsøke komplekse produksjonsproblemer. Dette er en online Java-tråddumpanalysator, vi kan laste opp tråddumpen som en fil eller vi kan kopiere og lime inn tråddumpen direkte.

Avhengig av størrelsen vil den analysere tråddumpen og vise informasjonen som vist på skjermbildet.

Funksjoner

  • Feilsøk JVM-krasj, nedganger, minnelekkasjer, fryser, CPU-spiker
  • Øyeblikkelig RCA (ikke vent på leverandører)
  • Intuitivt dashbord
  • REST API-støtte
  • Maskinlæring

#2. Spotify Thread Dump Analyzer

De Spotify Thread Dump Analyzer er lisensiert under versjon 2.0 av Apache-lisensen. Det er et nettbasert verktøy og godtar tråddumpen som en fil, eller vi kan kopiere og lime inn tråddumpen direkte. Avhengig av størrelsen vil den analysere tråddumpen og vise informasjonen som vist på skjermbildet.

#3. Jstack anmeldelse

Jstack.review analyserer java-tråddumper fra nettleseren. Denne siden er kun på klientsiden.

#4. Nettsted 24×7

Dette verktøy er en forutsetning for å oppdage defekte tråder som forringer ytelsen til Java Virtual Machine (JVM). Problemer som vranglås, låsestrid og overdreven CPU-utnyttelse av individuelle tråddumper kan løses ved å visualisere tilstandene til individuelle tråddumper.

Maksimal gjennomstrømning fra appen kan oppnås ved å rette opp statusen til hver tråd som leveres av verktøyet.

La oss nå utforske offline-verktøy.

Når det gjelder profilering er det kun det beste verktøyet som er godt nok.

#1. JProfiler

JProfiler er en av de mest populære tråddumpanalysatorene blant Java-utviklere. JProfilers intuitive brukergrensesnitt hjelper deg med å løse ytelsesflaskehalser, finne minnelekkasjer og forstå trådingsproblemer.

JProfiler støtter profilering på følgende plattformer:

  • Windows
  • Mac os
  • Linux
  • FreeBSD
  • Solaris
  • AIX
  • HP-UX

Nedenfor er noen funksjoner som gjør JProfiler til det beste valget for profilering av applikasjonene våre på JVM.

Funksjoner

  • Støtter databaseprofilering for JDBC, JPA og NoSQL
  • Støtte for Java Enterprise Edition er også tilgjengelig
  • Presenterer høynivåinformasjon om RMI-anrop
  • Stjerneanalyse av minnelekkasjer
  • Omfattende QA-funksjoner
  • Den integrerte trådprofileren er tett integrert med CPU-profileringsvisningene.
  • Støtte for plattformer, IDE-er og applikasjonsservere.

#2. IBM TMDA

IBM Thread and Monitor Dump Analyzer for Java (TMDA) er et verktøy som tillater identifikasjon av henger, vranglåser, ressursstrid og flaskehalser i Java-tråddumper. Det er et IBM-produkt, men TMDA-verktøyet leveres uten garanti eller støtte; imidlertid prøver de å fikse og forbedre verktøyet over tid.

#3. ManageEngine

ManageEngine Application Manager kan hjelpe til med å overvåke JVM Heap og Non-Heap minne. Vi kan til og med konfigurere terskler og bli varslet via e-post, SMS, etc, og sørge for at en Java-applikasjon er godt innstilt.

#4. YourKit

YourKit består av produktene nedenfor kalt det som et sett.

  • Java Profiler – Fullverdig lav overhead profiler for Java EE og Java SE-plattformer.
  • YouMonitor – Ytelsesovervåking og profilering av Jenkins, TeamCity, Gradle, Maven, Ant, JUnit og TestNG.
  • .NET Profiler – Enkel å bruke ytelses- og minneprofiler for .NET framework.

Konklusjon

Nå vet du hvordan tråddumper er nyttige for å forstå og diagnostisere problemer i flertrådede applikasjoner. Med skikkelig kunnskapangående tråddumpene – deres struktur, informasjonen i dem, og så videre – kan vi bruke dem til å identifisere årsakene til problemene raskt.