Анализ дампа потока: трассировка стека потока

JavaStrackTraceSimulator
Author: Pierre-Hugues Charbonneau
http://javaeesupportpatterns.blogspot.com

Exception in thread "main" java.lang.IllegalArgumentException:
        at org.ph.javaee.training.td.Class2.call(Class2.java:12)
        at org.ph.javaee.training.td.Class1.call(Class1.java:14)
        at org.ph.javaee.training.td.JavaSTSimulator.main(JavaSTSimulator.java:20)

—        
вызов метода Class2
() вызывает исключение Java: java.lang. IllegalArgumentException

—        
Java Exception затем отображается в журнале / стандартный вывод

Как видите, путь выполнения кода, который приводит к этому исключению, всегда отображается снизу вверх.

Вышеупомянутый процесс анализа должен быть хорошо известен любому программисту на Java. Далее вы увидите, что процесс анализа трассировки стека потоков дамп-потока очень похож на описанный выше анализ трассировки стека Java.

Thread Dump: анализ трассировки стека потоков

Дамп потока, сгенерированный из JVM, предоставляет вам моментальный снимок выполнения на уровне кода всех «созданных» потоков всего процесса JVM. Созданные потоки не означают, что все эти потоки действительно что-то делают. В типичном снимке потока дампа, созданном из JVM контейнера Java EE:

—        
Некоторые потоки могут выполнять необработанные вычислительные задачи, такие как синтаксический анализ XML, доступ к IO / диску и т. Д.

—        
Некоторые потоки могут ожидать некоторых блокирующих вызовов ввода-вывода, таких как удаленный вызов веб-службы, запрос DB / JDBC и т. Д.

—        
Некоторые потоки могут быть вовлечены в сборку мусора в то время, например, потоки GC

—        
Некоторые потоки будут ожидать выполнения некоторой работы (потоки, не выполняющие никакой работы, обычно переходят в состояние ожидания ())

—        
Некоторые потоки могут ожидать завершения работы других потоков, например, потоки, ожидающие получения блокировки монитора (синхронизированный блок {}) на некоторых объектах

Я вернусь к вышесказанному с большим количеством диаграмм в моей следующей статье, но сейчас давайте сосредоточимся на процессе анализа трассировки стека. Ваша следующая задача — прочитать трассировку стека потоков и понять, что она делает, насколько вам известно.

A Thread stack trace provides you with a snapshot of its current execution. The first line typically includes native information of the Thread such as its name, state, address etc. The current execution stack trace has to be read from bottom-up. Please follow the analysis process below. The more experience you get with Thread Dump analysis, the faster you will able to read and identify very quickly the work performed by each Thread:

—       
Start to read the Thread stack trace from the bottom

—       
First, identify the originator (Java EE container Thread, custom Thread ,GC Thread, JVM internal Thread, standalone Java program “main” Thread etc.)

—       
The next step is to identify the type of request the Thread is executing (WebApp, Web Service, JMS, Remote EJB (RMI), internal Java EE container etc.)

—       
The next step is to identify form the execution stack trace your application module(s) involved e.g. the actual core work the Thread is trying to perform. The complexity of analysis will depend of the layers of abstraction of your middleware environment and application

—       
The next step is to look at the last ~10-20 lines prior to the first line. Identify the protocol or work the Thread is involved with e.g. HTTP call, Socket communication, JDBC or raw computing tasks such as disk access, class loading etc.

—       
The next step is to look at the first line. The first line usually tells a LOT on the Thread state since it is the current piece of code executed at the time you took the snapshot

—       
The combination of the last 2 steps is what will give you the core of information to conclude of what work and / or hanging condition the Thread is involved with

Now find below a visual breakdown of the above steps using a real example of a Thread Dump Thread stack trace captured from a JBoss 5 production environment. In this example, many Threads were showing a similar problem pattern of excessive IO when creating new instances of JAX-WS Service instances.

As you can see, the last 10 lines along with the first line will tell us what hanging or slow condition the Thread is involved with, if any. The lines from the bottom will give us detail of the originator and type of request.

I hope this article has helped you understand the importance of proper Thread stack trace analysis. I will get back with much more Thread stack trace examples when we cover the most common Thread Dump problem patterns in future articles. The next article will now teach you how to breakdown the Thread Dump threads in logical silos and come up with a potential list of root cause “suspects”.

Please feel free to post any comment and question.