Kas ir Thread Dump un kā tos analizēt?

Parunāsim par pavedienu izgāztuvi un to, kā to analizēt.

Mēs arī apspriedīsim, kā tas palīdz precīzi noteikt problēmas un dažus analizatorus, kurus varat izmantot.

Kas ir pavediens?

Process ir datorprogramma, kas tiek ielādēta datora atmiņā un tiek izpildīta. To var izpildīt procesors vai procesoru komplekts. Process tiek aprakstīts atmiņā ar svarīgu informāciju, piemēram, mainīgo krātuvēm, failu rokturiem, programmu skaitītāju, reģistriem un signāliem utt.

Process var sastāvēt no daudziem viegliem procesiem, ko sauc par pavedieniem. Tas palīdz panākt paralēlismu, kurā process ir sadalīts vairākos pavedienos. Tas nodrošina labāku veiktspēju. Visiem procesa pavedieniem ir viena un tā pati atmiņas vieta un tie ir atkarīgi viens no otra.

Vītņu izgāztuves

Kad process tiek izpildīts, mēs varam noteikt pašreizējo pavedienu izpildes stāvokli procesā, izmantojot pavedienu izgāztuves. Pavedienu izdruka satur visu to pavedienu momentuzņēmumu, kas ir aktīvi programmas izpildes laikā noteiktā brīdī. Tajā ir visa atbilstošā informācija par pavedienu un tā pašreizējo stāvokli.

Mūsdienu lietojumprogramma ietver vairākus pavedienus. Katrs pavediens prasa noteiktus resursus, veic noteiktas darbības, kas saistītas ar procesu. Tas var uzlabot lietojumprogrammas veiktspēju, jo pavedieni var izmantot pieejamos CPU kodolus.

Taču pastāv kompromisi, piemēram, dažreiz vairāki pavedieni var slikti koordinēt viens ar otru un var rasties strupceļa situācija. Tātad, ja kaut kas noiet greizi, mēs varam izmantot pavedienu izgāztuves, lai pārbaudītu savu pavedienu stāvokli.

Pavedienu izgāztuve Java

JVM pavedienu izdruka ir visu to pavedienu stāvokļa saraksts, kas ir daļa no procesa konkrētajā brīdī. Tajā ir informācija par pavediena steku, kas tiek parādīta kā steka pēda. Tā kā tas ir rakstīts vienkāršā tekstā, saturu var saglabāt vēlākai pārskatīšanai. Var palīdzēt pavedienu izgāztuvju analīze

  • JVM veiktspējas optimizēšana
  • Lietojumprogrammu veiktspējas optimizēšana
  • Problēmu diagnostika, piemēram, strupceļš, strīds par pavedienu utt.

Vītņu izgāztuvju ģenerēšana

Ir daudzi veidi, kā radīt pavedienu izgāztuves. Tālāk ir norādīti daži uz JVM balstīti rīki, un tos var izpildīt no Java instalācijas mapes komandrindas/termināla (CLI rīki) vai /bin (GUI rīki) direktorijas.

Izpētīsim tos.

#1. jStack

Vienkāršākais veids, kā izveidot pavedienu izdruku, ir izmantot jStack. jStack tiek piegādāts kopā ar JVM, un to var izmantot no komandrindas. Šeit mums ir nepieciešams procesa PID, kuram mēs vēlamies ģenerēt pavedienu izdruku. Lai iegūtu PID, mēs varam izmantot jps komandu, kā parādīts zemāk.

jps -l

jps uzskaita visus Java procesa ID.

Operētājsistēmā Windows

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

Operētājsistēmā 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] ~]#

Kā mēs redzam šeit, mēs iegūstam visu darbojošos Java procesu sarakstu. Tajā ir ietverts lokālais virtuālās mašīnas ID palaist Java procesa un lietojumprogrammas nosaukums attiecīgi pirmajā un otrajā kolonnā. Tagad, lai ģenerētu pavedienu izdruku, mēs izmantojam programmu jStack ar karodziņu –l, kas izveido garu izgāztuves izvadi. Mēs varam arī izvadīt kādu teksta failu pēc mūsu izvēles.

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 ir GUI rīks, kas palīdz mums novērst Java lietojumprogrammas, pārraudzīt un profilēt tās. Tam ir arī JVM, un to var palaist no mūsu Java instalācijas /bin direktorijas. Tas ir ļoti intuitīvs un viegli lietojams. Citu iespēju starpā tas arī ļauj tvert pavedienu izgāztuvi konkrētam procesam.

  Kā droši tīrīt savu iPhone, izmantojot dezinfekcijas salvetes

Lai skatītu pavedienu izdruku konkrētam procesam, mēs varam ar peles labo pogu noklikšķināt uz programmas un konteksta izvēlnē atlasīt Thread Dump.

#3. jcmd

JCMD ir komandrindas utilīta, kas tiek piegādāta kopā ar JDK un tiek izmantota diagnostikas komandu pieprasījumu nosūtīšanai uz JVM.

Tomēr tas darbojas tikai vietējā datorā, kurā darbojas Java lietojumprogramma. To var izmantot, lai kontrolētu Java lidojumu ierakstus, diagnosticētu un novērstu JVM un Java lietojumprogrammas. Mēs varam izmantot jcmd komandu Thread.print, lai iegūtu pavedienu izgāztuvju sarakstu konkrētam procesam, ko nosaka PID.

Zemāk ir piemērs tam, kā mēs varam izmantot 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 nozīmē Java Mission Control. Tas ir atvērtā pirmkoda GUI rīks, kas tiek piegādāts kopā ar JDK un tiek izmantots Java lietojumprogrammu datu vākšanai un analīzei.

To var palaist no mūsu Java instalācijas mapes /bin. Java administratori un izstrādātāji izmanto rīku, lai apkopotu detalizētu zema līmeņa informāciju par JVM un lietojumprogrammu darbību. Tas nodrošina detalizētu un efektīvu Java Flight Recorder savākto datu analīzi.

Palaižot jmc, mēs varam redzēt java procesu sarakstu, kas darbojas vietējā datorā. Ir iespējams arī attālināts savienojums. Konkrētā procesā mēs varam ar peles labo pogu noklikšķināt un izvēlēties Sākt lidojuma ierakstīšanu un pēc tam pārbaudīt pavedienu izgāztuves cilnē Pavedieni.

#5. jconsole

jconsole ir Java pārvaldības paplašinājuma rīks, ko izmanto sūdzību pārvaldībai un uzraudzībai.

Tam ir arī iepriekš definētu darbību kopums JMX aģentā, ko lietotājs var veikt. Tas ļauj lietotājam atklāt un analizēt tiešās programmas steka izsekošanu. To var palaist no mūsu Java instalācijas mapes /bin.

  ASTC 3.0 skaidrojums: jūsu tālrunī tiek parādīta apraides TV

Izmantojot jconsole GUI rīku, mēs varam pārbaudīt katra pavediena steka izsekošanu, kad savienojam to ar darbojošos Java procesu. Pēc tam cilnē Thread mēs varam redzēt visu darbojošos pavedienu nosaukumus. Lai noteiktu strupceļu, mēs varam noklikšķināt uz Atklāt strupceļu loga apakšējā labajā stūrī. Ja tiek konstatēts strupceļš, tas tiks parādīts jaunā cilnē, pretējā gadījumā tiks parādīts ziņojums Nr.

#6. ThreadMxBean

ThreadMXBean ir saskarne Java virtuālās mašīnas, kas pieder pakotnei java.lang.Management, pavedienu sistēmas pārvaldībai. To galvenokārt izmanto, lai noteiktu pavedienus, kas nonākuši strupceļā, un iegūtu informāciju par tiem.

Mēs varam izmantot ThreadMxBean saskarni, lai programmatiski uztvertu pavedienu izgāztuvi. Lai iegūtu ThreadMXBean saskarnes gadījumu, tiek izmantota ManagementFactory metode getThreadMXBean(). Tas atgriež gan dēmonu, gan nedēmonu tiešo pavedienu skaitu. ManagementFactory ir rūpnīcas klase pārvaldīto pupiņu iegūšanai Java platformai.

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

Vītņu izgāztuvju manuāla analīze

Vītņu izgāztuvju analīze var būt ļoti noderīga, lai precīzi noteiktu problēmas daudzpavedienu procesos. Tādas problēmas kā strupceļi, bloķēšanas strīdi un pārmērīga CPU izmantošana atsevišķu pavedienu izgāztuvēs var atrisināt, vizualizējot atsevišķu pavedienu izgāztuvju stāvokļus.

Lietojumprogrammas maksimālo caurlaidspēju var sasniegt, labojot katra pavediena statusu pēc pavedienu izgāztuves analīzes.

Piemēram, pieņemsim, ka process patērē daudz CPU, mēs varam noskaidrot, vai kāds pavediens visvairāk izmanto centrālo procesoru. Ja ir kāds šāds pavediens, mēs pārveidojam tā LWP numuru par heksadecimālo skaitli. Pēc tam no pavedienu izgāztuves mēs varam atrast pavedienu, kura nid ir vienāds ar iepriekš iegūto heksadecimālo skaitli. Izmantojot pavediena steku, mēs varam precīzi noteikt problēmu. Noskaidrosim pavediena procesa ID, izmantojot tālāk norādīto komandu.

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

Apskatīsim zemāk esošo pavedienu izgāztuves gabalu. Lai iegūtu pavedienu izdruku procesam 26680, izmantojiet 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

Tagad apskatīsim, ko mēs varam izpētīt, izmantojot pavedienu izgāztuves. Ja mēs novērojam pavedienu izgāztuvi, mēs varam redzēt daudz satura, kas var būt milzīgs. Tomēr, ja mēs speram vienu soli vienlaikus, tas var būt diezgan vienkārši saprotams. Sapratīsim pirmo rindiņu

2020-06-27 09:01:29
Pilna pavediena izgāztuves Java HotSpot(TM) 64 bitu servera virtuālā mašīna (25.221-b11 jauktais režīms):

Iepriekš ir parādīts izgāztuves ģenerēšanas laiks un informācija par izmantoto JVM. Tālāk, beigās, mēs varam redzēt pavedienu sarakstu, pirmais no tiem ir mūsu ReferenceHandler pavediens.

Bloķēto pavedienu analīze

Ja analizējam tālāk norādītos pavedienu izdrukas žurnālus, mēs varam atklāt, ka tas ir atklājis pavedienus ar statusu BLOĶĒTS, kas padara lietojumprogrammas darbību ļoti lēnu. Tātad, ja mēs varam atrast BLOKĒTOS pavedienus, mēs varam mēģināt izvilkt pavedienus, kas saistīti ar slēdzenēm, kuras pavedieni mēģina iegūt. Problēmu var palīdzēt atrisināt skursteņa pēdas analīze no pavediena, kurā pašlaik atrodas slēdzene.

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

Strupceļa pavediena analīze

Vēl viens ļoti bieži izmantots diegu izgāztuvju pielietojums ir strupceļu noteikšana. Strupceļu noteikšana un novēršana var būt daudz vienkāršāka, ja analizējam pavedienu izgāztuves.

Strupceļš ir situācija, kurā ir iesaistīti vismaz divi pavedieni, kad resurss, kas nepieciešams vienam pavedienam, lai turpinātu izpildi, tiek bloķēts ar citu pavedienu, un tajā pašā laikā otrajam pavedienam nepieciešamais resurss tiek bloķēts ar pirmo pavedienu.

  Vai jums vajadzētu iegādāties Apple Watch 4?

Tādējādi neviens no pavedieniem nevar turpināt izpildi, un tas noved pie strupceļa un beidzas ar lietojumprogrammas iestrēgšanu. Ja ir dredi, pavedienu izgāztuves pēdējā sadaļā tiks izdrukāta informācija par strupceļu šādi.

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

Šeit mēs varam redzēt strupceļa informāciju diezgan saprotamā formātā.

Izņemot šo, ja mēs apkopojam visu iepriekš minēto pavedienu izgāztuves daļu, tajā ir norādīta tālāk norādītā informācija.

  • Atsauces apdarinātājs ir cilvēkiem salasāms pavediena nosaukums.
  • #2 ir pavediena unikālais ID.
  • dēmons apzīmē, ja pavediens ir dēmona pavediens.
  • Pavediena skaitliskā prioritāte tiek dota ar prio=10.
  • Pašreizējais pavediena statuss tiek apzīmēts ar gaidīšanu ar nosacījumu.
  • Tad mēs redzam steka izsekojumu, kas ietver bloķēšanas informāciju.

Vītņu izgāztuvju analizatori

Papildus manuālajai analīzei ir pieejami daudzi rīki, lai analizētu pavedienu izgāztuves gan tiešsaistē, gan bezsaistē. Zemāk ir daži no uzskaitītajiem rīkiem, kurus varam izmantot, pamatojoties uz prasībām.

Vispirms izpētīsim tiešsaistes rīkus.

#1. Ātrs pavediens

Ātrs pavediens ir DevOps inženiera iecienītākais pavedienu izmešanas analīzes rīks sarežģītu ražošanas problēmu novēršanai. Šis ir tiešsaistes Java pavedienu izgāztuves analizators, mēs varam augšupielādēt pavedienu izdruku kā failu vai arī mēs varam tieši kopēt un ielīmēt pavedienu izgāztuvi.

Atkarībā no izmēra tas analizēs pavedienu izgāztuvi un parādīs informāciju, kā parādīts ekrānuzņēmumā.

Iespējas

  • Problēmu novēršana JVM avārijām, palēninājumiem, atmiņas noplūdēm, sasalšanas, CPU lēcieniem
  • Tūlītēja RCA (negaidiet pārdevējus)
  • Intuitīvs informācijas panelis
  • REST API atbalsts
  • Mašīnmācība

#2. Spotify pavedienu izmešanas analizators

The Spotify pavedienu izmešanas analizators ir licencēts saskaņā ar Apache licences versiju 2.0. Tas ir tiešsaistes rīks un pieņem pavedienu izgāztuvi kā failu, vai arī mēs varam tieši kopēt un ielīmēt pavedienu izgāztuvi. Atkarībā no izmēra tas analizēs pavedienu izgāztuvi un parādīs informāciju, kā parādīts ekrānuzņēmumā.

#3. Jstack apskats

Jstack.review analizē Java pavedienu izgāztuves no pārlūkprogrammas. Šī lapa ir paredzēta tikai klienta pusei.

#4. Vietne 24 × 7

Šis rīks ir priekšnoteikums, lai atklātu kļūdainus pavedienus, kas pasliktina Java virtuālās mašīnas (JVM) veiktspēju. Tādas problēmas kā strupceļi, bloķēšanas strīdi un pārmērīga CPU izmantošana atsevišķu pavedienu izgāztuvēs var atrisināt, vizualizējot atsevišķu pavedienu izgāztuvju stāvokļus.

Maksimālo lietotnes caurlaidspēju var sasniegt, labojot katra rīka nodrošinātā pavediena statusu.

Tagad izpētīsim bezsaistes rīkus.

Runājot par profilēšanu, pietiekami labs ir tikai labākais rīks.

#1. JProfiler

JProfiler ir viens no populārākajiem pavedienu izgāztuves analizatoriem Java izstrādātāju vidū. JProfiler intuitīvais lietotāja interfeiss palīdz novērst veiktspējas vājās vietas, novērst atmiņas noplūdes un izprast pavedienu problēmas.

JProfiler atbalsta profilēšanu šādās platformās:

  • Windows
  • macOS
  • Linux
  • FreeBSD
  • Solaris
  • AIX
  • HP-UX

Tālāk ir norādītas dažas funkcijas, kas padara JProfiler par labāko izvēli mūsu lietojumprogrammu profilēšanai JVM.

Iespējas

  • Atbalsta datu bāzes profilēšanu JDBC, JPA un NoSQL
  • Ir pieejams arī Java uzņēmuma izdevuma atbalsts
  • Sniedz augsta līmeņa informāciju par RMI zvaniem
  • Atmiņas noplūdes zvaigžņu analīze
  • Plašas kvalitātes nodrošināšanas iespējas
  • Integrētais vītnes profilētājs ir cieši integrēts ar CPU profilēšanas skatiem.
  • Atbalsts platformām, IDE un lietojumprogrammu serveriem.

#2. IBM TMDA

IBM Thread and Monitor Dump Analyzer for Java (TMDA) ir rīks, kas ļauj identificēt uzkarības, strupceļus, resursu strīdus un vājās vietas Java pavedienu izgāztuvēs. Tas ir IBM produkts, taču TMDA rīks tiek nodrošināts kā bez garantijas vai atbalsta; tomēr viņi laika gaitā mēģina salabot un uzlabot rīku.

#3. Pārvaldīt dzinēju

Pārvaldīt dzinēju lietojumprogrammu pārvaldnieks var palīdzēt pārraudzīt JVM kaudzes un nekaudzes atmiņu. Mēs pat varam konfigurēt sliekšņus un saņemt brīdinājumus pa e-pastu, SMS utt., kā arī nodrošināt, ka Java lietojumprogramma ir labi noregulēta.

#4. YourKit

YourKit sastāv no tālāk norādītajiem produktiem, ko sauc par komplektu.

  • Java Profiler — pilnībā aprīkots zemo izmaksu profilētājs Java EE un Java SE platformām.
  • YouMonitor — Jenkins, TeamCity, Gradle, Maven, Ant, JUnit un TestNG veiktspējas uzraudzība un profilēšana.
  • .NET Profiler — ērti lietojams veiktspējas un atmiņas profilētājs .NET ietvaram.

Secinājums

Tagad jūs zināt, kā pavedienu izgāztuves ir noderīgas, lai izprastu un diagnosticētu problēmas daudzpavedienu lietojumprogrammās. Ar pareizu zināšanasattiecībā uz diegu izgāztuvēm – to uzbūvi, tajos esošo informāciju un tā tālāk – varam tos izmantot, lai ātri identificētu problēmu cēloņus.