Shulou(Shulou.com)06/03 Report--

This article introduces the relevant knowledge of "what is the state of jstack threads?". Many people will encounter such a dilemma in the operation of actual cases, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

Thread status in jstack Dump log files

Thread status worthy of attention in the dump file

Deadlock, Deadlock (focus)

In progress, Runnable

Wait for resources, Waiting on condition (focus)

Waiting to get the monitor, Waiting on monitor entry (focus)

Pause, Suspended

Object waiting, Object.wait () or TIMED_WAITING

Blocking, Blocked (focus)

Stop, Parked

Let's start with the first example, then list the meaning and considerations of different thread states, and finally add two examples.

Comprehensive demonstration 1: examples of Waiting to lock and Blocked are as follows: "RMI TCP Connection (267865)-172.16.5.25" daemon prio=10 tid=0x00007fd508371000 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 (an 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 timed out waiting for resources!

2) "waiting to lock" means that a thread is waiting to lock this 0x00000000acf4d0c0 address (English description: trying to obtain 0x00000000acf4d0c0 lock).

3) look up the string 0x00000000acf4d0c0 in the dump log and find that there are a large number of threads waiting to lock this address. If you can find out in the log who acquired the lock (such as locked

), and you can follow the trail.

4) "waiting for monitor entry" indicates that this thread passes synchronized (obj) {. } the application enters the critical section, thus entering the "Entry Set" queue in figure 1 below, but the monitor corresponding to the obj is owned by another thread, so this thread waits in the Entry Set queue.

5) in the first line, "RMI TCP Connection (267865)-172.16.5.25" is Thread Name. Tid means 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.

The meaning of thread state and considerations in the Dump file is as follows:

Deadlock: deadlock thread, multiple thread calls, into mutual resource occupation, resulting in waiting for the situation that can not be released.

Runnable: generally speaking, the thread is in a state of execution, takes up resources, is processing a request, may be passing SQL to the database for execution, may be operating on a file, and may perform data type conversion.

Waiting on condition: wait for a resource, or wait for a condition to occur. The specific reasons need to be analyzed in combination with stacktrace.

If the stack information is clearly application code, it proves that the thread is waiting for the resource. Generally, when a large number of resources are read, and the resource is locked, the thread enters the waiting state and waits for the resource to be read. Or, waiting for the execution of other threads, etc.

If you find that there are a large number of threads in the Wait on condition, from the thread stack, waiting for the network to read and write, this may be a sign of a network bottleneck. The thread cannot execute because of network congestion.

One situation is that the network is so busy that it consumes almost all the bandwidth, and there is still a lot of data waiting for the network to read and write.

Another situation may be that the network is idle, but due to routing and other problems, the packet can not arrive normally.

Another common occurrence of Wait on condition is that the thread is in sleep, and when the time for waiting for sleep is up, it will be woken up.

Blocked: thread blocking means that during the current thread execution, the required resources have been waiting for a long time but have not been obtained. It is identified as a blocking state by the thread manager of the container, which can be understood as a thread waiting for the resource timeout.

Waiting for monitor entry and in Object.wait (): Monitor is the main means to implement mutual exclusion and cooperation between threads in Java. It can be regarded as an object or a lock of Class. 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 some point, that thread is "Active Thread", while the other threads are "Waiting Thread", waiting in two queues "Entry Set" and "Wait Set" respectively. The state of the thread waiting in "Entry Set" is "Waiting for monitor entry", while the state of the thread waiting in "Wait Set" is "in Object.wait ()".

Figure 1 A Java Monitor

Comprehensive demonstration 2: examples of Waiting on condition and TIMED_WAITING are as follows: "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 (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) the timed_waiting in "TIMED_WAITING (parking)" refers to the waiting state, but the time is specified here, and the waiting state is automatically exited when the specified time is reached; parking means that the thread is suspended.

2) "waiting on condition" needs to be combined with "parking to wait for (a java.util.concurrent.SynchronousQueue$TransferStack)" in the stack. First of all, this thread must be waiting for a condition to happen to wake itself up. Second, 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 handed over, so this is the condition that the thread is waiting for.

3) nothing else can be seen.

Comprehensive demonstration 3: examples of in Obejct.wait () and TIMED_WAITING are as follows: "RMI RenewClean- [172.16.5.19 0x00007f34f4bd0000 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 (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove (ReferenceQueue.java:118)-locked (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, is because the thread calls java.lang.Object.wait (long timeout) and enters the waiting state.

2) the state of the waiting thread in "Wait Set" is "in Object.wait ()". When the thread gets the Monitor and enters the critical section, if it finds that the conditions for the thread to continue running are not met, it calls the wait () method of the object (usually the object being synchronized), abandons the Monitor and enters the "Wait Set" queue. Only when another thread calls notify () or notifyAll () on the object does the thread in the "Wait Set" queue get a chance to compete, but only one thread gets the object's Monitor and returns to the running state.

3) RMI RenewClean is a part of DGCClient. DGC means Distributed GC, that is, distributed garbage collection.

4) Please note that it is locked before waiting on, that is, in the execution of a thread, the Monitor of this object is first obtained with synchronized (corresponding to locked); when executed to * * lock.wait (timeout); * *, the thread gives up the ownership of Monitor and enters the "Wait Set" queue (corresponding to waiting on).

The reason why you lock the same object first and then wait for the same object, please see its code implementation below:

Static private class Lock {}; private Lock lock = new Lock (); public Reference

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.