Java thread dump analysis tool jstack parsing and usage scenario

Jstack is used to print out the Java stack information of a given java process ID or core file or remote debugging service. If it is on a 64 bit machine, the option "- j-d64" needs to be specified. The use of jstack in windows only supports the following methods:

jstack [-l][F] pid

If a java program crashes and generates a core file, the jstack tool can be used to obtain the information of the Java stack and native stack of the core file, so that you can easily know how the Java program crashes and where the problem occurs in the program. In addition, the jstack tool can also be attached to the running Java program to see the information of the Java stack and native stack of the running Java program at that time. Jstack is very useful if the running Java program presents a hung state. If the process is in hung dead state, you can use - F to force a stack.

In the dump file, thread states that deserve attention are:

Deadlock, deadlock (focus)

Running, runnable

Waiting on condition

Waiting on monitor entry

Suspended

Object waiting, object Wait() or timed_ WAITING

Blocked (focus)

Stop, parked

After picking up three scenarios from another blog:

Example 1: waiting to lock and blocked

explain:

1) The thread status is blocked and blocked. Description the thread timed out waiting for resources!

2) "Waiting to lock < 0x00000000acf4d0c0 >" means that the thread is waiting to lock this 0x00000000acf4d0c0 address (English can be described as: trying to obtain 0x00000000acf4d0c0 lock).

3) Look up the string 0x00000000acf4d0c0 in the dump log and find that a large number of threads are waiting to lock this address. If you can find out who has obtained the lock in the log (e.g. locked < 0x00000000acf4d0c0 >), you can follow it.

4) "Waiting for monitor entry" means that this thread enters the critical area through the synchronized (obj) {...} application, thus entering the "entry set" queue in Figure 1, but the monitor corresponding to this obj is owned by other threads, so this thread waits in the entry set queue.

5) In the first line, "RMI TCP connection (267865) -172.16.5.25" is the thread name. TID refers to the java thread ID. NID refers to the ID of the native thread. Prio is the thread priority. [0x00007fd4f8684000] is the starting address of the thread stack.

Example 2: waiting on condition and timed_ WAITING

explain:

1) Timed in timed_waiting (parking)_ Waiting refers to the waiting state, but the time is specified here. When the specified time is reached, it will automatically exit the waiting state; Parking means that the thread is suspended.

2) "Waiting on condition" needs to be combined with "parking to wait for < 0x00000000acd84de8 > (a Java. Util. Concurrent. Synchronousqueue $transferstack)" in the stack. First, the thread must be waiting for a condition to wake itself up. Secondly, the synchronousqueue is not a queue, but a mechanism for transferring information between threads. When we put an element into the synchronousqueue, another thread must be waiting for the task to be transferred. Therefore, this is the condition for this thread to wait.

3) I can't see anything else.

Example 3: in obejct Wait() and timed_ WAITING

explain:

1) "Timed_waiting (on object monitor)", for this example, is because this thread calls Java lang.Object. Wait (long timeout).

2) The waiting thread state in the "wait set" is "in object. Wait()". When the thread obtains the monitor and enters the critical area, if it finds that the conditions for the thread to continue running are not met, it calls the wait() method of the object (generally the synchronized object), abandons the monitor and enters the "wait set" queue. Only when other threads call notify() or notifyall() on the object can the threads in the "wait set" queue get the opportunity to compete, but only one thread obtains the monitor of the object and returns to the running state.

3) RMI renewclean is a part of dgccclient. DGC refers to distributed GC, that is, distributed garbage collection.

4) Please note that it is locked < 0x00000000aa672478 >, and then waiting on < 0x00000000aa672478 >. The reason why it is locked first and then equivalent to an object is to see its code implementation below:

That is, during the execution of the thread, the monitor of the object is obtained with synchronized (corresponding to locked < 0x00000000aa672478 >); When executing to lock wait(timeout);， The thread gives up the ownership of the monitor and enters the "wait set" queue (corresponding to waiting on < 0x00000000aa672478 >).

5) Judging from the stack information, remote references to remote objects are being cleaned up. The referenced lease has arrived, and the distributed garbage collection is cleaning up one by one.

referance：

Example code of solving process Deadlock through jstack analysis