Jstack command Explanation

Jstack is used 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 only supports the following: Jstack [ -l] 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.

Issues to be aware of:

L different Java Virtual machine thread dump creation method and file format is not the same, different JVM version, dump information also differs.

L in the actual operation, often a dump of information, not enough to confirm the problem. It is recommended to generate three dump messages, and if each dump points to the same problem, we determine the typical problem.

2. Command format

$jstack [option] pid

$jstack [option] executable core

$jstack [option] [[Email Protected]]remote-hostname-or-ip

Parameter description:

The process number of the Pid:java application can be obtained by JPS;

Executable: Java executable program that produces core dump;

Core: Print out the core file;

REMOTE-HOSTNAME-OR-IP: Name or IP of the remote debug server;

Server-id: Unique ID, if there are multiple remote debug services on a single host;

Example:

$jstack –l 23561

Threading Analysis:

In general, the thread information output through Jstack mainly includes: JVM itself thread, user thread, etc. Where the JVM thread will be present when the JVM is started. The user thread is generated when the user accesses it.

L JVM Thread:

In the thread, there are background threads inside the JVM that perform tasks such as garbage collection, or low memory detection, which are often present when the JVM is initialized, as follows:

"Attach Listener" daemon prio=10 tid=0x0000000052fb8000 nid=0xb8f waiting on condition [0x0000000000000000] Java.lang.Thread.State:RUNNABLE Locked ownable Synchronizers: -None DESTROYJAVAVM "prio=10 tid=0x00002aaac1225800 nid=0x7208 waiting on condition [0x0000000000000000] Java.lang.Thread.State:RUNNABLE Locked ownable Synchronizers: -None

L User-level threads

There is also a class of threads that are user-level and vary depending on the user's request. The running of this kind of thread is often the focus of our attention. And this part is the easiest place to create a deadlock.

"Qtp496432309-42" prio=10 tid=0x00002aaaba2a1800 nid=0x7580 waiting on condition [0x00000000425e9000] Java.lang.Thread.State:TIMED_WAITING (parking) At Sun.misc.Unsafe.park (Native Method) -Parking to wait for <0x0000000788cfb020> (a java.util.concurrent.locks.abstractqueuedsynchronizer$ Conditionobject) At Java.util.concurrent.locks.LockSupport.parkNanos (locksupport.java:198) At Java.util.concurrent.locks.abstractqueuedsynchronizer$conditionobject.awaitnanos ( abstractqueuedsynchronizer.java:2025) At Org.eclipse.jetty.util.BlockingArrayQueue.poll (blockingarrayqueue.java:320) At Org.eclipse.jetty.util.thread.queuedthreadpool$2.run (queuedthreadpool.java:479) At Java.lang.Thread.run (thread.java:662) Locked ownable Synchronizers: -None

From the code example above, we can see the following types of information about the user thread:

Ø thread Status: Waiting on condition (wait condition occurs)

Ø the invocation of the thread;

Ø thread-to-resource locking situation;

State Analysis of Threads:

As we just saw, the state of the thread is an important indicator that shows where the threads end each line. So what are the common states of threads? Under what circumstances will a thread enter this state? What clues can we find?

L Runnable

This state indicates that the thread has all the running conditions, prepares the operating system for scheduling in the running queue, or is running.

L Waiton Condition

The status occurs when a thread waits for a condition to occur. What is the specific reason, can combine stacktrace to analyze. The most common scenario is that the thread waits for the network to read and write, such as when the network data is not ready for reading, and the thread is in this wait state, and once the data is ready to read, the thread is reactivated, reading and processing the data. Before the introduction of NiO in Java, for each network connection, there is a corresponding thread to handle the read and write operation of the network, even if there is no data to read and write, the thread is still blocking the read and write operations, which can cause resource waste, but also to the operating system thread scheduling pressure. New mechanisms have been introduced in NiO, and the performance and scalability of the programmed server programs has been improved.

If you find that a large number of threads are in wait on condition, looking from the thread stack, waiting for the network to read and write, this can be a symptom of a network bottleneck. The thread could not execute because of network blocking. One situation is that the network is very busy, almost consumes all the bandwidth, there is still a large amount of data waiting for the network to read and write, another situation may be the network idle, but due to problems such as routing, the packet does not arrive properly. Therefore, we should combine some performance observation tools of the system to synthesize the analysis, such as the number of sending packets of netstat statistic unit time, if it is obviously more than the limit of the network bandwidth; Observe CPU utilization, if the CPU time of the system state is higher than the CPU time of the user state; If the program is running on the Solaris 10 platform, you can use the DTrace tool to see what the system calls, if you observe read/ The number of write system calls or run times is far ahead, which points to network bottlenecks caused by network bandwidth constraints.

Another common scenario in which wait on condition occurs is when the thread is in sleep, waiting for the time of sleep to be awakened.

L waitingfor Monitor entry and in Object.wait ()

In multithreaded Java programs, to implement synchronization between threads, it is necessary to talk about monitor. Monitor is the primary means of using Java to achieve mutual exclusion and collaboration between threads, which can be seen as an object or class lock. Every object has, and only one monitor. The following diagram depicts the relationship between the thread and monitor, and the state transition diagram of the thread:

As you can see, each monitor can be owned by only one thread at a time, and the thread is "Active thread", while the other threads are "waiting thread", waiting in the two queue "Entry set" and "Wait set" respectively. The state of the thread waiting in "Entry set" is "Waiting for Monitorentry", while the thread state waiting in "wait set" is "in Object.wait ()".

First look at the thread inside the "Entry Set". We call the code snippet protected by synchronized as a critical section. When a thread requests to enter a critical section, it enters the "Entry Set" queue. The corresponding code is like this:

Synchronized (obj) {

.........

}

There are two possibilities:

The monitor is not owned by other threads, and there are no other waiting threads in the Entry set. This thread becomes the Owner of the corresponding class or object's monitor, executing the code for the critical section. At this point the thread will be in runnable state;

The monitor is owned by another thread, and this thread waits in the Entry set queue. At this point, the dump information displays "Waiting for monitor entry".

"Thread-0" prio=10 tid=0x08222eb0 nid=0x9 waiting for monitor entry [0xf927b000. 0XF927BDB8] At Testthread. Waitthread.run (waitthread.java:39) -Waiting to lock <0xef63bf08> (a java.lang.Object) -Locked <0xef63beb8> (a java.util.ArrayList) At Java.lang.Thread.run (thread.java:595)

The critical section is set to ensure the atomicity and integrity of code execution within it. But because the critical section only allows threads to pass through at any time, this is contrary to the original intention of our multithreaded program. If in a multithreaded program, a large number of use of synchronized, or improper use of it, will cause a large number of threads in the critical section of the entrance waiting, resulting in a significant decrease in performance of the system. If this situation is found in the thread dump, the source code should be reviewed and the program improved.

Now let's see why threads are entering "Wait Set". 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. In the "Wait Set" thread, dump behaves as: in Object.wait (), similar to:

"Thread-1" prio=10 tid=0x08223250 nid=0xa in object.wait () [0xef47a000. 0xef47aa38] At java.lang.Object.wait (Native Method) -Waiting on <0xef63beb8> (a java.util.ArrayList) At Java.lang.Object.wait (object.java:474) At Testthread. Mywaitthread.run (MYWAITTHREAD.JAVA:40) -Locked <0xef63beb8> (a java.util.ArrayList) At Java.lang.Thread.run (thread.java:595)

Looking closely at the dump information above, you will find that it has the following two lines:

²locked <0xef63beb8> (ajava.util.ArrayList)

²waiting on <0xef63beb8> (ajava.util.ArrayList)

Here's an explanation for why you lock the object first and then waiting on the same object? Let's take a look at the code that this thread corresponds to:

Synchronized (obj) {

.........

Obj.wait ();

.........

}

In the execution of the thread, the Monitor (corresponding to locked <0xef63beb8>) of this object is obtained with synchronized. When executed to Obj.wait (), the thread discards the ownership of monitor and enters the "Wait set" queue (corresponding to waiting on<0xef63beb8>).

In your program, there will be a number of similar threads, they all have similar dump may also be normal. For example, there are multiple service threads in the program that are designed to read request data from a queue. This queue is the lock and waiting on object. When the queue is empty, these threads wait on this queue until the queue has data, the threads are notify, and of course only one thread gets lock, continues execution, while the other threads continue to wait.

Reference documents:

Http://www.blogjava.net/jzone/articles/303979.html

http://blog.csdn.net/fenglibing/article/details/6411940

Jstack command Explanation