Jstack Command Analysis

The Jstack command parses jstack to print out the Java stack information for a given Java process ID or core file or remote debugging service, and if it is on a 64-bit machine, you need to specify the option "-j-d64", The Jstack usage of Windows only supports this way: 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 native stack, This makes 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) execution, runnable waiting for resources, waiting on condition (focus on) waiting to get the monitor, waiting on monitor Entry (focus) Pause, suspended object waiting, object.wait () or timed_waiting block, Blocked (focus) stop, parked three scenarios in which another blog was picked: instance one: Waiting to Lock and Blocked "RMI TCP Connection (267865) -172.16.5.25" daemon prio=10 tid=0x00007fd508371000 nid=0x55ae waiting for Monit or 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) Description: 1) 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 Waiti ng 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 the time specified here, automatically exits the wait state after the specified time, and parking refers to 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, it's 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.Task, 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 the purposes of this example, is 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 DgccliePart of NT. DGC refers to the distributed GC, which is distributed garbage collection. 4) Note that it is locked <0x00000000aa672478&gt first, after waiting on <0x00000000aa672478&gt, and the reason why the first lock is equal to an object, see the following code implementation: static Private class  Lock {};p rivate lock lock = new Lock ();p ublic reference< Extends t> remove (long timeout) {synchronized (lock) {reference<? extends t> r = Reallypoll (); if (r! = null) retur n R;for (;;) {lock.wait (timeout); r = Reallypoll ();}} That is, in the execution of the thread, the Monitor (corresponding to   locked <0x00000000aa672478>) of this object is first obtained with synchronized, and when executed to lock.wait (timeout); The thread discards the ownership of Monitor and enters 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

Jstack Command parsing