Vad är tråddumpning och hur analyserar man dem?

Spread the love

Låt oss prata om tråddumpen och hur man analyserar den.

Vi kommer också att diskutera hur det hjälper att lokalisera problemen och en del av analysatorn du kan använda.

Vad är tråd?

En process är ett datorprogram som laddas in i datorns minne och körs. Det kan köras av en processor eller en uppsättning processorer. En process beskrivs i minnet med viktig information såsom variabellager, filhandtag, programräknare, register och, signaler, och så vidare.

En process kan bestå av många lätta processer som kallas trådar. Detta hjälper till att uppnå parallellitet där en process är uppdelad i flera trådar. Detta resulterar i bättre prestanda. Alla trådar i en process delar samma minnesutrymme och är beroende av varandra.

Tråddumpar

När processen körs kan vi upptäcka det aktuella tillståndet för exekvering av trådarna i processen med hjälp av tråddumpar. En tråddump innehåller en ögonblicksbild av alla trådar som är aktiva vid en viss punkt under körningen av ett program. Den innehåller all relevant information om tråden och dess nuvarande tillstånd.

En modern applikation idag involverar flera antal trådar. Varje tråd kräver vissa resurser, utför vissa aktiviteter relaterade till processen. Detta kan öka prestandan för en applikation eftersom trådar kan använda tillgängliga CPU-kärnor.

Men det finns avvägningar, t.ex. ibland kanske flera trådar inte koordinerar bra med varandra och en dödlägessituation kan uppstå. Så om något går fel kan vi använda tråddumpar för att inspektera tillståndet för våra trådar.

Tråddump i Java

En JVM-tråddump är en lista över tillståndet för alla trådar som ingår i processen vid den specifika tidpunkten. Den innehåller information om trådens stack, presenterad som en stackspårning. Som det är skrivet i klartext kan innehållet sparas för granskning senare. Analys av tråddumpar kan hjälpa till

Optimera JVM-prestanda
Optimera applikationsprestanda
Diagnostisera problem, t.ex. ett dödläge, trådtvist, etc.

Generering av tråddumpar

Det finns många sätt att generera tråddumpar. Nedan finns några JVM-baserade verktyg och kan köras från kommandoraden/terminalen (CLI-verktyg) eller katalogen /bin (GUI-verktyg) i installationsmappen för Java.

Låt oss utforska dem.

#1. jStack

Det enklaste sättet att skapa en tråddump är att använda jStack. jStack levereras med JVM och kan användas från kommandoraden. Här behöver vi PID för processen som vi vill generera tråddumpen för. För att få PID kan vi använda kommandot jps som visas nedan.

jps -l

jps listar alla Java-process-ID.

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 här får vi en lista över alla Java-processer som körs. Den innehåller det lokala VM-id:t för den körande Java-processen och namnet på applikationen i kolumn ett respektive två. Nu, för att generera tråddumpen, använder vi jStack-programmet med –l-flagga som skapar en lång listad utdata av dumpen. Vi kan också skicka utdata till någon textfil som vi väljer.

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 är ett GUI-verktyg som hjälper oss att felsöka, övervaka och profilera Java-applikationer. Den kommer också med JVM och kan startas från /bin-katalogen i vår java-installation. Det är väldigt intuitivt och lätt att använda. Bland andra alternativ tillåter det oss också att fånga tråddump för en viss process.

6 cPanel alternativ värdplattform för WordPress och andra

För att se tråddumpen för en viss process kan vi högerklicka på programmet och välja Thread Dump från snabbmenyn.

#3. jcmd

JCMD är ett kommandoradsverktyg som levereras med JDK och används för att skicka diagnostiska kommandoförfrågningar till JVM.

Det fungerar dock bara på den lokala maskinen där Java-applikationen körs. Den kan användas för att styra Java Flight Recordings, diagnostisera och felsöka JVM- och Java-applikationer. Vi kan använda kommandot Thread.print för jcmd för att få en lista över tråddumpar för en viss process som specificeras av PID.

Nedan är ett exempel på hur vi kan använda 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 för Java Mission Control. Det är ett GUI-verktyg med öppen källkod som levereras med JDK och används för att samla in och analysera Java-applikationsdata.

Den kan startas från mappen /bin i vår Java-installation. Java-administratörer och utvecklare använder verktyget för att samla in detaljerad lågnivåinformation om JVM:s och applikationens beteenden. Det möjliggör detaljerad och effektiv analys av data som samlats in av Java Flight Recorder.

När vi startar jmc kan vi se en lista över java-processer som körs på den lokala maskinen. En fjärranslutning är också möjlig. På en viss process kan vi högerklicka och välja Starta flyginspelning och sedan kontrollera tråddumparna på fliken Trådar.

#5. jconsole

jconsole är ett Java Management Extension-verktyg som används för klagomålshantering och övervakning.

Den har också en uppsättning fördefinierade operationer på JMX-agenten som användaren kan utföra. Det gör det möjligt för användaren att upptäcka och analysera stackspår av ett liveprogram. Den kan startas från mappen /bin i vår Java-installation.

Lägg till animerade GIF-mönster till dina foton och videor

Med hjälp av jconsole GUI-verktyget kan vi inspektera varje tråds stackspårning när vi ansluter den till en pågående java-process. Sedan, på fliken Tråd, kan vi se namnet på alla pågående trådar. För att upptäcka ett dödläge kan vi klicka på Detektera dödläge längst ner till höger i fönstret. Om ett dödläge upptäcks kommer det att visas på en ny flik, annars visas ett blockerat låsläge inte.

#6. ThreadMxBean

ThreadMXBean är gränssnittet för hantering av trådsystemet för den virtuella Java-maskinen som tillhör java.lang.Management-paketet. Det används främst för att upptäcka trådar som har hamnat i en dödlägessituation och få information om dem.

Vi kan använda ThreadMxBean-gränssnittet för att programmera fånga tråddumpen. getThreadMXBean()-metoden för ManagementFactory används för att få en instans av ThreadMXBean-gränssnittet. Det returnerar antalet livetrådar för både demoner och icke-demoner. ManagementFactory är en fabriksklass för att få de hanterade bönorna för 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 analys av tråddumpar

Analys av tråddumpar kan vara mycket användbar för att lokalisera problem i flertrådade processer. Problem som dödläge, låskonflikt och överdrivet CPU-användning av individuella tråddumpar kan lösas genom att visualisera tillstånden för individuella tråddumpar.

Maximal genomströmning från applikationen kan uppnås genom att korrigera statusen för varje tråd efter att ha analyserat tråddumpen.

Låt oss till exempel säga att en process använder mycket CPU, vi kan ta reda på om någon tråd använder CPU:n mest. Om det finns någon sådan tråd konverterar vi dess LWP-nummer till ett hexadecimalt tal. Sedan från tråddumpen kan vi hitta tråden med nid lika med det tidigare erhållna hexadecimala talet. Med hjälp av stack trace av tråden kan vi lokalisera problemet. Låt oss ta reda på process-id för tråden med kommandot nedan.

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

Låt oss ta en titt på tråddumpen nedan. För att få tråddump för process 26680, använd 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

Nu ska vi se vad vi kan utforska med tråddumpar. Om vi observerar tråddumpningen kan vi se mycket innehåll, vilket kan vara överväldigande. Men om vi tar ett steg i taget kan det vara ganska enkelt att förstå. Låt oss förstå den första raden

2020-06-27 09:01:29
Full tråddump Java HotSpot(TM) 64-bitars server VM (25.221-b11 blandat läge):

Ovanstående visar tiden då dumpen genererades och information om JVM som användes. Därefter, till slut, kan vi se listan över trådar, den första bland dem är vår ReferenceHandler-tråd.

Analysera blockerade trådar

Om vi analyserar tråddumpningsloggarna nedan kan vi upptäcka att den har upptäckt trådar med statusen BLOCKERAD vilket gör att en applikation presterar mycket långsamt. Så om vi kan hitta de BLOCKERADE trådarna kan vi försöka extrahera trådarna som är relaterade till låsen som trådarna försöker få. Analys av stapelspåret från tråden som för närvarande håller låset kan hjälpa till att lösa 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)
.
.
.
.

Analyserar låst tråd

En annan mycket vanlig tillämpning av tråddumpar är detektering av dödläge. Detekteringen och lösningen av dödlägen kan bli mycket lättare om vi analyserar tråddumparna.

6 bästa byggnadsinformationsmodelleringsprogramvaran för designers och byggare

Ett dödläge är en situation som involverar minst två trådar där resursen som krävs av en tråd för att fortsätta exekveringen är låst av en annan tråd och samtidigt är resursen som krävs av den andra tråden låst av den första tråden.

Så ingen av trådarna kan fortsätta körningen, och detta resulterar i en dödlägessituation och slutar med att applikationen fastnar. Om det finns dreadlocks kommer den sista delen av tråddumpen att skriva ut informationen om dödläget enligt följande.

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

Här kan vi se dödlägesinformationen i ett ganska mänskligt läsbart format.

Annat än detta, om vi summerar alla ovanstående bitar av tråddump tillsammans, så anger det nedanstående information.

Referenshanterare är det mänskliga läsbara namnet på tråden.
#2 är trådens unika id.
daemon anger om tråden är en demontråd.
Trådens numeriska prioritet ges av prio=10.
Trådens aktuella status anges med att vänta på villkor.
Sedan ser vi stackspåret, som inkluderar låsinformationen.

Tråddumpningsanalysatorer

Förutom manuell analys finns det många verktyg tillgängliga för att analysera tråddumpar, både online och offline. Nedan är några av de listade verktygen som vi kan använda utifrån kraven.

Låt oss först utforska onlineverktyg.

#1. Snabb tråd

Snabb tråd är DevOps-ingenjörens favoritverktyg för tråddumpningsanalys för att felsöka komplexa produktionsproblem. Detta är en online Java-tråddumpanalysator, vi kan ladda upp tråddumpen som en fil eller så kan vi direkt kopiera och klistra in tråddumpen.

Beroende på storleken kommer den att analysera tråddumpen och visa informationen som visas på skärmdumpen.

Funktioner

Felsök JVM-krascher, nedgångar, minnesläckor, frysningar, CPU-spik
Omedelbar RCA (vänta inte på leverantörer)
Intuitiv instrumentpanel
REST API-stöd
Maskininlärning

#2. Spotify Thread Dump Analyzer

De Spotify Thread Dump Analyzer är licensierad under version 2.0 av Apache-licensen. Det är ett onlineverktyg och accepterar tråddumpen som en fil eller så kan vi direkt kopiera och klistra in tråddumpen. Beroende på storleken kommer den att analysera tråddumpen och visa informationen som visas på skärmdumpen.

#3. Jstack recension

Jstack.review analyserar java-tråddumpar från webbläsaren. Denna sida är endast klientsidan.

#4. Webbplats 24×7

Detta verktyg är en förutsättning för att upptäcka felaktiga trådar som försämrar prestanda för Java Virtual Machine (JVM). Problem som dödläge, låskonflikt och överdrivet CPU-användning av individuella tråddumpar kan lösas genom att visualisera tillstånden för individuella tråddumpar.

Maximal genomströmning från appen kan uppnås genom att korrigera statusen för varje tråd som tillhandahålls av verktyget.

Låt oss nu utforska offlineverktyg.

När det kommer till profilering är bara det bästa verktyget tillräckligt bra.

#1. JProfiler

JProfiler är en av de mest populära tråddumpningsanalysatorerna bland Java-utvecklare. JProfilers intuitiva användargränssnitt hjälper dig att lösa prestandaflaskhalsar, hitta minnesläckor och förstå trådningsproblem.

JProfiler stöder profilering på följande plattformar:

Windows
Mac OS
Linux
FreeBSD
Solaris
AIX
HP-UX

Nedan finns några funktioner som gör JProfiler till det bästa valet för profilering av våra applikationer på JVM.

Funktioner

Stöder databasprofilering för JDBC, JPA och NoSQL
Stöd för Java Enterprise Edition finns också tillgängligt
Presenterar information på hög nivå om RMI-samtal
Stjärnanalys av minnesläckor
Omfattande QA-funktioner
Den integrerade gängprofileraren är tätt integrerad med CPU-profileringsvyerna.
Stöd för plattformar, IDE:er och applikationsservrar.

#2. IBM TMDA

IBM Thread and Monitor Dump Analyzer för Java (TMDA) är ett verktyg som tillåter identifiering av häng, dödlägen, resurskonflikt och flaskhalsar i Java-tråddumpar. Det är en IBM-produkt men TMDA-verktyget tillhandahålls som utan någon garanti eller support; men de försöker fixa och förbättra verktyget över tid.

#3. ManageEngine

ManageEngine applikationshanteraren kan hjälpa till att övervaka JVM Heap och Non-Heap-minne. Vi kan till och med konfigurera trösklar och bli varnade via e-post, SMS, etc, och se till att en Java-applikation är väl avstämd.

#4. YourKit

YourKit består av nedanstående produkter som kallas det som ett kit.

Java Profiler – Fullt utrustad låg overhead profiler för Java EE och Java SE-plattformar.
YouMonitor – Prestandaövervakning och profilering av Jenkins, TeamCity, Gradle, Maven, Ant, JUnit och TestNG.
.NET Profiler – Lättanvänd prestanda- och minnesprofilerare för .NET framework.

Slutsats

Nu vet du hur tråddumpar är användbara för att förstå och diagnostisera problem i flertrådade applikationer. Med ordentligt kunskapangående tråddumparna – deras struktur, informationen i dem och så vidare – kan vi använda dem för att snabbt identifiera orsakerna till problemen.

Din åsikt ?

Vad är tråd?

Tråddumpar

Tråddump i Java

Generering av tråddumpar

#1. jStack

På Windows

På Linux

#2. jvisualvm

#3. jcmd

#4. JMC

#5. jconsole

#6. ThreadMxBean

Manuell analys av tråddumpar

Analysera blockerade trådar

Analyserar låst tråd

Tråddumpningsanalysatorer

#1. Snabb tråd

#2. Spotify Thread Dump Analyzer

#3. Jstack recension

#4. Webbplats 24×7

#1. JProfiler

#2. IBM TMDA

#3. ManageEngine

#4. YourKit

Slutsats

Share this post!