Java Thread Dump analysis tool--jstack "reprint"

Jstack to print out the Java stack information for 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, and the Jstack usage of Windows supports only the following:

jstack [-l][f] PID
If a Java program crashes generating a core file, the Jstack tool can be used to obtain information about the core file's Java stack and the native stack, making it easy to know how the Java program crashes and where the problem occurs in the program. In addition, the Jstack tool can be attached to a running Java program to see the Java stack and the native stack of the Java program that was running, and jstack is useful if the Java program that is running now renders hung state. The process is in hung dead state can be forced to play stack with-F.
in the dump file, the interesting thread states are:
Deadlock,Deadlock (focus on)
In execution, Runnable
Waiting for resources,waiting on condition (focus)
Waiting to get the monitor,waiting on monitor entry (focus)
Pause, Suspended
Object waits, object.wait () or timed_waiting
Blocking,Blocked (Focus)
Stop, parked.

Three scenarios in which another blog was picked up:

Example one: Waiting to lock and Blocked

"RMI TCP Connection (267865) -172.16.5.25" daemon prio=10 tid=0x00007fd508371000 nid=0x55ae waiting for monitor entry [0x00 007FD4F8684000]   Java.lang.Thread.State:BLOCKED (on object monitor) at Org.apache.log4j.Category.callAppenders ( category.java:201)-Waiting to lock <0x00000000acf4d0c0> (a Org.apache.log4j.Logger) at Org.apache.log4j.Category.forcedLog (category.java:388) at Org.apache.log4j.Category.log (category.java:853) at Org.apache.commons.logging.impl.Log4JLogger.warn (log4jlogger.java:234) at Com.tuan.core.common.lang.cache.remote.SpyMemcachedClient.get (spymemcachedclient.java:110)

Description
1) The thread state is Blocked, blocking state. Description thread waits for resource timeout!
2) "Waiting to lock <0x00000000acf4d0c0>" means that the thread is waiting for the 0x00000000acf4d0c0 address to be locked (English can be described as: trying to obtain 0X00000000ACF4D0C0 lock).
3) Find the string 0x00000000acf4d0c0 in the dump log and find that a lot of threads are waiting for the address to be locked. If you can find out who gets this lock (such as locked < 0X00000000ACF4D0C0 >) in the log, you can track it down.
4) "Waiting for monitor entry" indicates that this thread has entered the critical section through synchronized (obj) {...} and thus entered the "entry Set" queue in 1, but the corresponding monitor of that obj is owned by another thread, so this The 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 a thread priority. [0x00007fd4f8684000] is the thread stack start address.

Example two: Waiting on condition and timed_waiting

"RMI TCP Connection (idle)" Daemon prio=10 tid=0x00007fd50834e800 nid=0x56b2 waiting on condition [0x00007fd4f1a59000]
   java.lang.thread.state:timed_waiting (parking) at Sun.misc.Unsafe.park (Native Method)-Parking to wait for  < 0x00000000acd84de8> (a java.util.concurrent.synchronousqueue$transferstack) at Java.util.concurrent.locks.LockSupport.parkNanos (locksupport.java:198) at java.util.concurrent.synchronousqueue$ Transferstack.awaitfulfill (synchronousqueue.java:424) at java.util.concurrent.synchronousqueue$ Transferstack.transfer (synchronousqueue.java:323) at Java.util.concurrent.SynchronousQueue.poll ( synchronousqueue.java:874) at Java.util.concurrent.ThreadPoolExecutor.getTask (threadpoolexecutor.java:945) at Java.util.concurrent.threadpoolexecutor$worker.run (threadpoolexecutor.java:907) at Java.lang.Thread.run ( thread.java:662)

Description

1) The timed_waiting in "timed_waiting (parking)" refers to the wait state, but this specifies the time, which automatically exits the wait state after the specified time, and parking the thread is suspended.

2) "Waiting on condition" needs to be in the stack with "parking to wait for <0x00000000acd84de8> (a Java.util.concurrent.synchronousqueue$transferstack) "in combination. First of all, this thread must be waiting for a certain condition to happen, to wake itself up. Second, Synchronousqueue is not a queue, just a mechanism for transferring information between threads, and when we put an element into synchronousqueue, there must be another thread waiting to accept the handover, so this is the condition that this thread is waiting for.
3) Nothing else can be seen.

Example three: in Obejct.wait () and timed_waiting

"RMI renewclean-[172.16.5.19:28475]" daemon prio=10 tid=0x0000000041428800 nid=0xb09 in object.wait () [ 0X00007F34F4BD0000]   Java.lang.Thread.State:TIMED_WAITING (on object monitor) at Java.lang.Object.wait (Native Method)-Waiting on <0x00000000aa672478> (a java.lang.ref.referencequeue$lock) at Java.lang.ref.ReferenceQueue.remove (referencequeue.java:118)-Locked <0x00000000aa672478> (a Java.lang.ref.referencequeue$lock) at Sun.rmi.transport.dgcclient$endpointentry$renewcleanthread.run ( dgcclient.java:516) at Java.lang.Thread.run (thread.java:662)

Description

1) "Timed_waiting (on object Monitor)", for this example, because this thread called java.lang.Object.wait (long Timeout) and entered the wait state.

2) The state of the thread waiting in "Wait Set" is "in Object.wait ()". When the thread obtains the monitor and enters the critical section, if the condition that the thread continues to run is not satisfied, it calls the Wait () method of the object (typically the object being synchronized), discards the monitor, and enters the "Wait Set" queue. Only if another thread calls notify () or Notifyall () on the object, the "Wait Set" queue is given the opportunity to compete, but only one thread obtains the object's Monitor and reverts to the running state.

3) RMI Renewclean is part of the dgcclient. DGC refers to the distributed GC, which is distributed garbage collection.

4) Note that the first locked <0x00000000aa672478&gt, and then waiting on <0x00000000aa672478&gt, and the reason for locking is the same as an object, see the following code implementation:
Static private class Lock {};
Private lock lock = new Lock ();
Public reference<? Extends t> remove (long timeout)
{
Synchronized (lock) {
reference<? Extends t> r = Reallypoll ();
if (r! = null) return r;
for (;;) {
Lock.wait (timeout);
R = Reallypoll ();
......
}
}
That is, in the execution of the thread, the Monitor (corresponding to locked <0x00000000aa672478>) of the object is obtained with synchronized, and when executed to Lock.wait (timeout), the thread discards the Monitor's ownership, enter the "Wait Set" queue (corresponding to waiting on <0x00000000aa672478>).
5) from the stack information, is the remote references to remote objects is being cleaned up, the reference lease to the, distributed garbage collection in one-off.

Reference:

Command Summary: http://blog.csdn.net/fenglibing/article/details/6411940
Three kinds of examples: http://www.cnblogs.com/zhengyun_ustc/archive/2013/01/06/dumpanalysis.html

----------------------------------

This article was reproduced from: http://www.cnblogs.com/nexiyi/p/java_thread_jstack.html

Java Thread Dump analysis tool--jstack "reprint"