Давайте поговоримо про дамп потоку та про те, як його аналізувати.
Ми також обговоримо, як це допомагає визначити проблеми та деякі аналізатори, які можна використовувати.
Що таке Thread?
Процес — це комп’ютерна програма, яка завантажується в пам’ять комп’ютера та виконується. Він може виконуватися процесором або набором процесорів. Процес описується в пам’яті важливою інформацією, такою як сховища змінних, дескриптори файлів, програмний лічильник, регістри та сигнали тощо.
Процес може складатися з багатьох легких процесів, які називаються потоками. Це допомагає досягти паралелізму, коли процес розділений на кілька потоків. Це призводить до кращої продуктивності. Усі потоки в рамках процесу спільно використовують один і той самий простір пам’яті та залежать один від одного.
Дампи потоків
Коли процес виконується, ми можемо визначити поточний стан виконання потоків у процесі за допомогою дампів потоків. Дамп потоку містить знімок усіх потоків, активних у певний момент під час виконання програми. Він містить всю актуальну інформацію про потік і його поточний стан.
Сучасна програма сьогодні включає кілька потоків. Кожен потік вимагає певних ресурсів, виконує певні дії, пов’язані з процесом. Це може підвищити продуктивність програми, оскільки потоки можуть використовувати доступні ядра ЦП.
Але є компроміси, наприклад, іноді декілька потоків можуть погано координуватись один з одним, і може виникнути тупикова ситуація. Отже, якщо щось піде не так, ми можемо використовувати дампи потоків, щоб перевірити стан наших потоків.
Дамп потоку в Java
Дамп потоку JVM — це перелік стану всіх потоків, які є частиною процесу в цей конкретний момент часу. Він містить інформацію про стек потоку, представлений у вигляді трасування стека. Оскільки це написано відкритим текстом, вміст можна зберегти для перегляду пізніше. Аналіз дампів потоків може допомогти
- Оптимізація продуктивності JVM
- Оптимізація продуктивності програми
- Діагностика проблем, наприклад взаємоблокування, суперечка потоків тощо.
Генерація дампів потоків
Є багато способів генерувати дампи потоків. Нижче наведено деякі інструменти на основі JVM, які можна запустити з командного рядка/терміналу (інструменти CLI) або каталогу /bin (інструменти графічного інтерфейсу) папки інсталяції Java.
Давайте досліджувати їх.
#1. jStack
Найпростіший спосіб створити дамп потоку — це використовувати jStack. jStack поставляється з JVM і може використовуватися з командного рядка. Тут нам потрібен PID процесу, для якого ми хочемо створити дамп потоку. Щоб отримати PID, ми можемо використати команду jps, як показано нижче.
jps -l
jps містить список усіх ідентифікаторів процесів Java.
У Windows
C:Program FilesJavajdk1.8.0_171bin>jps -l 47172 portal 6120 sun.tools.jps.Jps C:Program FilesJavajdk1.8.0_171bin>
На 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] ~]#
Як ми бачимо тут, ми отримуємо список усіх запущених процесів Java. Він містить ідентифікатор локальної віртуальної машини для запущеного процесу Java та назву програми в першому та другому стовпцях відповідно. Тепер, щоб створити дамп потоку, ми використовуємо програму jStack з прапорцем –l, яка створює довгий список виводу дампа. Ми також можемо передати вихідні дані в текстовий файл на наш вибір.
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 — це інструмент графічного інтерфейсу користувача, який допомагає нам виявляти неполадки, контролювати та профілювати програми Java. Він також поставляється з JVM і може бути запущений з каталогу /bin нашої установки Java. Він дуже інтуїтивно зрозумілий і простий у використанні. Серед інших параметрів, це також дозволяє нам захопити дамп потоку для певного процесу.
Щоб переглянути дамп потоку для певного процесу, ми можемо клацнути правою кнопкою миші на програмі та вибрати Дамп потоку в контекстному меню.
#3. jcmd
JCMD — це утиліта командного рядка, яка постачається разом із JDK і використовується для надсилання запитів діагностичних команд до JVM.
Однак він працює лише на локальній машині, де запущено програму Java. Його можна використовувати для керування записами польотів Java, діагностики та усунення несправностей програм JVM і Java. Ми можемо використати команду Thread.print jcmd, щоб отримати список дампів потоків для певного процесу, визначеного PID.
Нижче наведено приклад того, як ми можемо використовувати 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 означає Java Mission Control. Це графічний інтерфейс із відкритим вихідним кодом, який постачається разом із JDK і використовується для збору та аналізу даних програми Java.
Його можна запустити з папки /bin нашої інсталяції Java. Адміністратори та розробники Java використовують інструмент для збору детальної низькорівневої інформації про поведінку JVM і програми. Це забезпечує детальний та ефективний аналіз даних, зібраних Java Flight Recorder.
Після запуску jmc ми можемо побачити список процесів Java, які виконуються на локальній машині. Також можливе дистанційне підключення. На певному процесі ми можемо клацнути правою кнопкою миші та вибрати «Почати запис польоту», а потім перевірити дампи потоків на вкладці «Потоки».
#5. jconsole
jconsole — це інструмент розширення керування Java, який використовується для керування скаргами та моніторингу.
Він також має набір попередньо визначених операцій з агентом JMX, які користувач може виконувати. Це дозволяє користувачеві виявляти та аналізувати трасування стека живої програми. Його можна запустити з папки /bin нашої інсталяції Java.
Використовуючи інструмент графічного інтерфейсу користувача jconsole, ми можемо перевіряти трасування стека кожного потоку, коли ми підключаємо його до запущеного процесу Java. Потім на вкладці Thread ми можемо побачити назви всіх запущених потоків. Щоб виявити взаємоблокування, ми можемо натиснути кнопку «Виявити тупик» у нижньому правому куті вікна. Якщо буде виявлено взаємоблокування, воно з’явиться на новій вкладці, інакше відобразиться повідомлення «Взаємоблокування не виявлено».
#6. ThreadMxBean
ThreadMXBean — це інтерфейс для керування системою потоків віртуальної машини Java, що належить пакету java.lang.Management. Він в основному використовується для виявлення потоків, які потрапили в тупикову ситуацію, і отримання інформації про них.
Ми можемо використовувати інтерфейс ThreadMxBean для програмного захоплення дампа потоку. Метод getThreadMXBean() ManagementFactory використовується для отримання екземпляра інтерфейсу ThreadMXBean. Він повертає кількість активних потоків як демона, так і не демона. ManagementFactory — це фабричний клас для отримання керованих компонентів для платформи 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 ();
}
Ручний аналіз дампів потоків
Аналіз дампів потоків може бути дуже корисним для визначення проблем у багатопоточних процесах. Такі проблеми, як взаємоблокування, суперечка за блокування та надмірне використання ЦП дампами окремих потоків, можна вирішити шляхом візуалізації станів дампів окремих потоків.
Максимальної пропускної здатності програми можна досягти шляхом виправлення стану кожного потоку після аналізу дампа потоку.
Наприклад, скажімо, процес використовує багато ЦП, ми можемо дізнатися, чи який потік використовує ЦП найбільше. Якщо такий потік існує, ми перетворюємо його номер LWP у шістнадцяткове число. Тоді з дампа потоку ми можемо знайти потік з nid, що дорівнює отриманому раніше шістнадцятковому числу. Використовуючи трасування стека потоку, ми можемо точно визначити проблему. Давайте дізнаємося ідентифікатор процесу потоку за допомогою наведеної нижче команди.
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
Давайте подивимося на фрагмент дампа потоку нижче. Щоб отримати дамп потоку для процесу 26680, використовуйте 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
Тепер давайте подивимося, які речі ми можемо досліджувати за допомогою дампів потоків. Якщо ми спостерігаємо за дампом потоку, ми можемо побачити багато вмісту, який може бути надзвичайною. Однак, якщо ми робимо крок за кроком, це може бути досить простим для розуміння. Давайте розберемося з першим рядком
2020-06-27 09:01:29
Повний дамп потоку Java HotSpot(TM) 64-Bit Server VM (25.221-b11 змішаний режим):
Вище показано час створення дампа та інформацію про JVM, який використовувався. Далі, в кінці, ми можемо побачити список потоків, першим серед яких є наш потік ReferenceHandler.
Аналіз заблокованих потоків
Якщо ми проаналізуємо наведені нижче журнали дампа потоку, ми можемо виявити, що він виявив потоки зі статусом BLOCKED, що робить роботу програми дуже низькою. Отже, якщо ми можемо знайти ЗАБЛОКОВАНІ потоки, ми можемо спробувати витягти потоки, пов’язані з блокуваннями, які ці потоки намагаються отримати. Аналіз трасування стека з потоку, який зараз містить блокування, може допомогти у вирішенні проблеми.
[[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)
.
.
.
.
Аналіз блокованого потоку
Іншим дуже часто використовуваним застосуванням дампів потоків є виявлення взаємоблокувань. Виявлення та вирішення взаємоблокувань може бути набагато легшим, якщо ми проаналізуємо дампи потоків.
Взаємоблокування — це ситуація, що стосується принаймні двох потоків, коли ресурс, потрібний одному потоку для продовження виконання, блокується іншим потоком, і в той же час ресурс, необхідний другому потоку, блокується першим потоком.
Таким чином, жоден з потоків не може продовжити виконання, і це призводить до тупикової ситуації та призводить до зупинки програми. Якщо дреди присутні, то останній розділ дампа потоку роздрукує інформацію про тупикову блокування наступним чином.
"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)
Тут ми можемо побачити інформацію про взаємоблокування в досить зручному для читання форматі.
Крім цього, якщо ми підсумовуємо весь вищезазначений фрагмент дампа потоку разом, то він містить наведену нижче інформацію.
- Обробник посилання – це зрозуміле для людини ім’я потоку.
- #2 — унікальний ідентифікатор потоку.
- daemon вказує, чи потік є потоком демона.
- Числовий пріоритет потоку визначається як prio=10.
- Поточний статус потоку позначається умовою очікування.
- Потім ми бачимо трасування стека, яке містить інформацію про блокування.
Аналізатори дампів потоків
Окрім аналізу вручну, є численні інструменти для аналізу дампів потоків, як онлайн, так і офлайн. Нижче наведено деякі з перелічених інструментів, які ми можемо використовувати відповідно до вимог.
По-перше, давайте дослідимо онлайн-інструменти.
#1. Швидка нитка
Швидка нитка це улюблений інструмент аналізу дампа потоку інженерів DevOps для вирішення складних проблем виробництва. Це онлайн-аналізатор дампа потоку Java. Ми можемо завантажити дамп потоку як файл або безпосередньо скопіювати та вставити дамп потоку.
Залежно від розміру, він проаналізує дамп потоку та відобразить інформацію, як показано на знімку екрана.
особливості
- Усунення несправностей JVM, збоїв, уповільнень, витоків пам’яті, зависань, стрибків ЦП
- Миттєвий RCA (не чекайте постачальників)
- Інтуїтивно зрозуміла інформаційна панель
- Підтримка REST API
- Машинне навчання
#2. Spotify Thread Dump Analyzer
The Spotify Thread Dump Analyzer ліцензовано за версією 2.0 ліцензії Apache. Це онлайн-інструмент, який приймає дамп потоку як файл, або ми можемо безпосередньо скопіювати та вставити дамп потоку. Залежно від розміру, він проаналізує дамп потоку та відобразить інформацію, як показано на знімку екрана.
#3. Огляд Jstack
Jstack.review аналізує дампи потоків Java з браузера. Ця сторінка є лише клієнтською.
#4. Сайт 24×7
Це інструмент є необхідною умовою для виявлення несправних потоків, що погіршують продуктивність віртуальної машини Java (JVM). Такі проблеми, як взаємоблокування, суперечка за блокування та надмірне використання ЦП дампами окремих потоків, можна вирішити шляхом візуалізації станів дампів окремих потоків.
Максимальної пропускної здатності програми можна досягти шляхом виправлення стану кожного потоку, наданого інструментом.
Тепер давайте вивчимо офлайн-інструменти.
Коли справа доходить до профілювання, лише найкращий інструмент є достатньо хорошим.
#1. JProfiler
JProfiler є одним із найпопулярніших аналізаторів дампа потоку серед розробників Java. Інтуїтивно зрозумілий користувальницький інтерфейс JProfiler допомагає усунути вузькі місця продуктивності, виявити витоки пам’яті та зрозуміти проблеми потоків.
JProfiler підтримує профілювання на таких платформах:
- вікна
- macOS
- Linux
- FreeBSD
- Соляріс
- AIX
- HP-UX
Нижче наведено деякі функції, які роблять JProfiler найкращим вибором для профілювання наших програм на JVM.
особливості
- Підтримує профілювання бази даних для JDBC, JPA та NoSQL
- Також доступна підтримка корпоративної версії Java
- Представляє інформацію високого рівня про виклики RMI
- Зоряний аналіз витоків пам’яті
- Широкі можливості контролю якості
- Інтегрований профайлер потоків тісно інтегрований із представленнями профілювання ЦП.
- Підтримка платформ, IDE та серверів додатків.
#2. IBM TMDA
IBM Thread and Monitor Dump Analyzer для Java (TMDA) — це інструмент, який дозволяє ідентифікувати зависання, взаємоблокування, конфлікти ресурсів і вузькі місця в дампах потоків Java. Це продукт IBM, але інструмент TMDA надається без жодних гарантій чи підтримки; однак з часом вони намагаються виправити та покращити інструмент.
#3. ManageEngine
ManageEngine диспетчер додатків може допомогти контролювати пам’ять JVM Heap і Non-Heap. Ми навіть можемо налаштувати порогові значення та отримувати сповіщення електронною поштою, SMS тощо, а також забезпечити належне налаштування програми Java.
#4. YourKit
YourKit складається з наведених нижче продуктів, які називаються набором.
- Java Profiler – повнофункціональний профайлер із низькими витратами для платформ Java EE та Java SE.
- YouMonitor – моніторинг продуктивності та профілювання Jenkins, TeamCity, Gradle, Maven, Ant, JUnit і TestNG.
- .NET Profiler – простий у використанні профайлер продуктивності та пам’яті для .NET framework.
Висновок
Тепер ви знаєте, як дампи потоків корисні для розуміння та діагностики проблем у багатопоточних програмах. З належним знаннящо стосується дампів потоків – їхньої структури, інформації, що міститься в них тощо – ми можемо використовувати їх для швидкого виявлення причин проблем.