Detailed usage of thread dump thread deadlock Detection Tool (Jstack)

Thread dump is used to diagnose problems with Java applications and can be used to discover deadlock threads, and so on. It can get the thread, the thread running state, the identity, the call stack, the stack contains the full class name, the method executed, and the number of lines in the source code, and so on.

Next, you need to consider how to get the thread dump problem. First, you can get the process number of the Java process by looking at the Java process information through JPS. You can also use top dynamic to observe CPU usage analysis process situation. It is then analyzed using the tool jstack from the JDK. Jstack <pid> >> filename can write the thread usage of the Java process corresponding to the PID to the back file.

such as the following code:

/**
 * Deadlock Example
 * @author crane.ding
 * @since 2011-3-20/
 public
class Deadlock {public

	static void Main (string[] args) {
		final Object obj_1 = new Object (), obj_2 = new Object ();
		
		thread T1 = new Thread ("T1") {
			@Override public
			void Run () {
				synchronized (obj_1) {
					try {
						Thread.Sleep (3000);
					} catch (Interruptedexception e) {}
					
					synchronized (obj_2) {
						System.out.println ("Thread T1 done.");
					}
			}
		};
		
		Thread t2 = new Thread ("T2") {
			@Override public
			void Run () {
				synchronized (obj_2) {
					try-{
						thread . Sleep (3000);
					catch (Interruptedexception e) {}
					
					synchronized (obj_1) {
						System.out.println ("Thread T2 done.");
					}
			}
		};
		
		T1.start ();
		T2.start ();
	}
	

You can get a snapshot of the thread dump after using the tools above

2011-03-20 23:05:20 full thread dump Java HotSpot (TM) Client VM (19.1-b02 mixed mode, sharing): "DESTROYJAVAVM" Prio=6 ti d=0x00316800 NID=0X9FC waiting on condition [0x00000000] Java.lang.Thread.State:RUNNABLE Locked ownable-Synchroniz ERS:-None "T2" prio=6 tid=0x02bcf000 nid=0xc70 waiting for monitor entry [0x02f6f000] Java.lang.Thread.State:BLOCK ED (on object Monitor) in Com.demo.deadlock$2.run (deadlock.java:40)-Waiting to lock <0x22a297a8> (a java.lang.Ob ject)-Locked <0x22a297b0> (a java.lang.Object) locked ownable synchronizers:-None "T1" prio=6 NID=0XBA0 Waiting for monitor entry [0x02f1f000] Java.lang.Thread.State:BLOCKED (on object monitor) at COM.DEMO.D  Eadlock$1.run (deadlock.java:25)-Waiting to lock <0x22a297b0> (a java.lang.Object)-locked <0x22a297a8> (a  Java.lang.Object) Locked ownable synchronizers:-None "low Memory detector" "Daemon prio=6 tid=0x02bb9400 nid=0xa6c
 runnable [0x00000000]  Java.lang.Thread.State:RUNNABLE Locked ownable synchronizers:-None "CompilerThread0", Daemon prio=10, TID=0X02BB2 NID=0XCB8 waiting on condition [0x00000000] Java.lang.Thread.State:RUNNABLE Locked ownable synchronizers:-N One "Attach Listener" daemon prio=10 tid=0x02bb1000 nid=0x7f4 waiting on condition [0x00000000] Java.lang.Thread.State  : RUNNABLE Locked ownable synchronizers:-None "Signal Dispatcher" daemon prio=10, tid=0x02bd2800 nid=0xd80 RUNNABLE [0x00000000] Java.lang.Thread.State:RUNNABLE Locked ownable synchronizers:-None "Finalizer" daemon, prio=8 tid =0x02bab000 nid=0xe1c in Object.wait () [0x02d3f000] Java.lang.Thread.State:WAITING (on Object monitor) at JAVA.LANG.O Bject.wait (Native method)-Waiting on <0x229e1148> (a java.lang.ref.referencequeue$lock) at Java.lang.ref.Refere Ncequeue.remove (referencequeue.java:118)-Locked <0x229e1148> (a java.lang.ref.referencequeue$lock) at Java.lang.ref.ReferenceQueue.remove(referencequeue.java:134) at Java.lang.ref.finalizer$finalizerthread.run (finalizer.java:159) Locked ownable Synchronizers:-None "Reference Handler" daemon prio=10 tid=0x02ba6800 Nid=0xbe0 in object.wait () [0x02cef000] java. Lang. Thread.State:WAITING (on object Monitor) in Java.lang.Object.wait (Native method)-Waiting on <0x229e1048> (a JAV A.lang.ref.reference$lock) at java.lang.Object.wait (object.java:485) at java.lang.ref.reference$ Referencehandler.run (reference.java:116)-Locked <0x229e1048> (a java.lang.ref.reference$lock) locked ownable Synchronizers:-None "VM Thread" prio=10 tid=0x02b6a400 nid=0x568 runnable "vm periodic Task Thread" prio=10 tid=0x02 bc8400 nid=0x75c waiting on condition JNI global references:878 Found one java-level deadlock: ======================
  ======= "T2": Waiting to lock monitor 0X02BAAEEC (Object 0x22a297a8, a java.lang.Object), which was held by "T1" "T1": Waiting to lock monitor 0X02BAA2BC (object 0x22a297b0, a java.lang.Object), which is held by ' T2 ' Java stack information for the threads listed above: ================== ================================= "T2": At Com.demo.deadlock$2.run (deadlock.java:40)-Waiting to lock <0x22a297a8& Gt (a java.lang.Object)-locked <0x22a297b0> (a java.lang.Object) "T1": At Com.demo.deadlock$1.run (deadlock.java:25 )-Waiting to lock <0x22a297b0> (a java.lang.Object)-locked <0x22a297a8> (a java.lang.Object) Found 1 de
 Adlock.

In the thread state dump file in the Jstack dump log file, the thread state of concern is: deadlock, deadlock (focus)   execution,runnable    Wait resources, waiting on condition ( Focus on   waiting to get monitor, waiting on monitor entry (focus) Pause, suspended object waiting, object.wait () or timed_waiting blocking, Blocked (focus on) & nbsp;  stop, parked integrated model one: Waiting to lock and Blocked examples are as follows: RMI TCP Connection (267865) -172.16.5.25 "Daemon prio=10 tid=0x 00007fd508371000 nid=0x55ae  waiting for Monitor entry  [0x00007fd4f8684000]     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) ... 1 thread state is   Blocked, blocking state. Indicates that the thread is waiting for the resource to timeout. 2) "  WaiTing to lock <0x00000000acf4d0c0> "means that the thread is waiting to lock the &NBSP;0X00000000ACF4D0C0 address (English can be described as: trying to obtain   0x00000000acf4d0c0 lock). 3 Find a string  0x00000000acf4d0c0 in the dump log and find that a large number of threads are waiting to lock the address. If you can find out who got the 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 has entered the "entry Set" queue in Figure 1 below, but that obj corresponding to the monitor is owned by another thread, the Waits in the Entry Set queue with this thread. 5 in the first line, "RMI TCP Connection (267865) -172.16.5.25" is  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 thread stack start address. Thread state meaning and precautions in   dump files

The meaning is as follows: Deadlock: Deadlock thread, generally refers to multiple thread calls between, into the mutual resource consumption, resulting in waiting for the situation can not be released. Runnable: Generally refers to the thread is executing state, the thread is consuming resources, processing a request, it is possible to pass SQL to database execution, it is possible to manipulate a file, it is possible to convert data types, and so on. Waiting on condition: waiting for a resource, or waiting for a condition to occur. The concrete reason needs to combine stacktrace to analyze. If the stack information is explicitly applied to the code, it proves that the thread is waiting for the resource. In the case of a resource lock, the thread enters the waiting state and waits for the resource to read. Alternatively, you are waiting for another thread to execute. If you find that a large number of threads are in the wait on condition, and are waiting for the network to read and write from the thread stack, this may be a symptom of a network bottleneck. The thread could not execute because of network blocking. One scenario is that the network is very busy, consumes almost all of the bandwidth, still has a lot of data waiting for the network to read and write, and the other may be network idle, but due to routing problems, the package will not arrive normally. Another common occurrence of a wait on condition is when the thread is awake, waiting for sleep to be awakened. Blocked: Thread blocking, refers to the current thread execution, the required resources for a long time to wait has not been obtained, the container's thread manager identified as blocking state, can be understood as waiting for the resource timeout thread. Waiting for monitor entry and in Object.wait (): Monitor is the main tool used in Java to implement mutual exclusion and collaboration between threads, and it can be viewed as an object or class lock. Each object has, and only one monitor. As you can see from Figure 1 below, each monitor can only be owned by one thread at a time, which is "Active thread", while the other threads are "waiting thread", waiting in two queues "Entry set" and "Wait set" respectively. The thread state waiting in "Entry set" is "Waiting for monitor Entry", while the thread status waiting in ' Wait Set ' is ' in object.wait () '.

Figure 1 A Java Monitor

  Integrated demonstration Two: W aiting on condition   and  timed_waiting are as follows: "RMI TCP Connection (idle)" Daemon prio=10 d50834e800 nid=0x56b2  waiting on condition  [0x00007fd4f1a59000]    java.lang.thread.state:   timed_waiting (parking) at Sun.misc.Unsafe.park (Native method)-  parking to wait for &NBSP;&LT;0X00000000ACD 84de8>   (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) 1) TIMED in "timed_waiting (parking)"_waiting refers to the wait state, but this specifies the time, automatically exits the wait state when the specified time is reached, parking refers to the thread being suspended.
2 "Waiting on condition" needs to be in the stack with the "Parking to" <0x00000000acd84de8> (a Java.util.concurrent.SynchronousQueu E$transferstack) "combined to see. First of all, this thread must be waiting for a condition to occur, to wake itself up. Second, Synchronousqueue is not a queue, but a mechanism for transferring information between threads, and when we put an element into the synchronousqueue, there must be another thread waiting to accept the handover, so this is the condition the thread is waiting for. 3) I can't see anything else.

Integrated model Three: in Obejct.wait () and timed_waiting examples are as follows: "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.L Ang. Object.wait (Native)-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) 1) "Timed_waiting (on object Monitor)", for this example, because this thread calls the Java.lang.Object.wait (long timeout) enters the wait state.

2 The waiting thread state in ' Wait Set ' is ' in object.wait () '. When the thread obtains the monitor and enters the critical section, it calls the Wait () method of the object (typically the object being synchronized), abandons the monitor, and enters the wait Set queue if the condition that the thread continues to run is not met. Only if another thread invokes the Notify () or Notifyall () on the object, the "Wait Set" queue thread gets the chance to compete, but only one thread gets the Monitor of the object and restores it to its running state.

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

4) Please note that the first   locked <0x00000000aa672478&gt,   waiting on <0x00000000aa672478&gt, the reason that the first lock is equal to an object, See below for its code implementation: static Private class  lock {}; Private lock lock = new Lock (); Public reference<? Extends t>  remove (long timeout) {    synchronized (lock) {        refer ence<?  extends t>  r =  reallypoll ();          if  (r !=  null)   return  R;          for  (;;)  {