@ Zheng yu Summary
Using the TDA tool, the first response to a large number of Java Thread states is:
1. The thread status is "waiting for monitor entry ":Meaning it
Waiting to enter a critical sectionSo it waits in the "Entry Set" queue. At this time, the thread status is generally Blocked:
- Java. lang. Thread. State:BLOCKED(On object monitor)
2. The thread status is "waiting on condition ":Description
Wait for another condition to occur to wake up.Or simply it calls sleep (N ). The thread status is roughly as follows:
- Java. lang. Thread. State:WAITING(Parking): always wait for that condition to happen;
- Java. lang. Thread. State:TIMED_WAITING(Parking or sleeping): if the timing condition is not met, it will also wake itself up regularly.
3. If a large number of threads
"Waiting for monitor entry ":A global lock may block a large number of threads. If the thread dump file printed in a short period of time is reflected, as time passes by, the number of waiting for monitor entry threads is increasing and there is no decreasing trend, it may mean
Some threads stay in the critical section for too long, so that more and more new threads are unable to enter the critical section..
4. If a large number of threads
"
Waiting on condition
":Maybe they ran to get third-party resources,
In particular, third-party network resources cannot be obtained for a long time., Causing a large number of threads to enter the waiting state. So if you find that a large number of threads are in the Wait on condition, from the thread stack perspective, you are waiting for network read/write.
This may be a sign of a network bottleneck.The thread cannot be executed because of network congestion.
The thread status is "in Object. wait ()":Description
After obtaining the monitor, the java. lang. Object. wait () method is called.. Each Monitor can only be owned by one Thread at a time. The Thread is "Active Thread", while other threads are "Waiting Thread ", wait in the "Entry Set" and "Wait Set" Queues respectively. In "Entry Set", the Waiting thread status is "Waiting for monitor entry", and in "Wait Set", the Waiting thread status is "in Object. wait ()". When the thread obtains the Monitor, if it finds that the conditions for the thread to continue running are not met, it will call the wait () method of the object (usually the object to be synchronized) and discard the Monitor, enter the "Wait Set" queue. The thread status is roughly as follows:
- Java. lang. Thread. State:TIMED_WAITING(On object monitor );
- Java. lang. Thread. State:WAITING(On object monitor );
Generally, RMI-related threads (RMI RenewClean, GC Daemon, RMI Reaper), GC threads (Finalizer), Reference Handler, and other system threads are in this state. Figure 1 A Java Monitor Example 1: The thread below is waiting for the lock
0x00000000fe7e3b50To enter the critical section: "rmi tcp Connection (64896)-172.16.52.118" daemon prio = 10 tid = 0x000000000000405a6000 nid = 0x68fe waiting for monitor entry [0x00007f2be65a3000] java. lang. thread. state: BLOCKED (on object monitor) at com. xyz. goods. service. impl. goodsServiceImpl.
FindChanellGoodsCountWithCache(GoodsServiceImpl. java: 1734 )-
Waiting to lock <0x00000000fe7e3b50> (a java. lang. String)
So who holds the lock? Is another thread that calls the findChanellGoodsCountWithCache function: "rmi tcp Connection (64878)-172.16.52.117" daemon prio = 10 tid = 0x0000000040822000 nid = 0x6841 runnable [0x00007f2be76b3000] java. lang. thread. state: RUNNABLEat java.net. socketInputStream. socketRead0 (Native Method) at java.net. socketInputStream. read (SocketInputStream. java: 129) at java. io. bufferedInputStream. fill (BufferedInputStream. java: 218) at java. io. bufferedInputStream. read1 (BufferedInputStream. java: 258) at java. io. bufferedInputStream. read (BufferedInputStream. java: 317)-locked <0x00000000af4ed638> (a java. io. bufferedInputStream) at org. bson. io. bits. readFully (Bits. java: 35) at org. bson. io. bits. readFully (Bits. java: 28) at com. mongodb. response. <init> (Response. java: 35) at com. mongodb. DBPort. go (DBPort. java: 110)-locked <0x00000000af442d48> (a com. mongodb. DBPort) at com. mongodb. DBPort. go (DBPort. java: 75)-locked <0x00000000af442d48> (a com. mongodb. DBPort) at com. mongodb. DBPort. call (DBPort. java: 65) at com. mongodb. DBTCPConnector. call (DBTCPConnector. java: 202) at com. mongodb. DBApiLayer $ MyCollection. _ find (DBApiLayer. java: 296) at com. mongodb. DB. command (DB. java: 152) at com. mongodb. DBCollection. getCount (DBCollection. java: 760) at com. mongodb. DBCollection. getCount (DBCollection. java: 731) at com. mongodb. DBCollection. count (DBCollection. java: 697) at com. xyz. goods. manager. mongodbManager. count (MongodbManager. java: 202) at com. xyz. goods. service. impl. goodsServiceImpl. findChanellGoodsCount (GoodsServiceImpl. java: 1787) at com. xyz. goods. service. impl. goodsServiceImpl.FindChanellGoodsCountWithCache(GoodsServiceImpl. java: 1739 )-Locked <0x00000000fe7e3b50> (a java. lang. String)Example 2: Wait for another condition to wake up: "rmi tcp Connection (idle)" daemon prio = 10 tid = 0x00007fd50834e800 nid = 0x56b2Waiting 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) 1)"TIMED_WAITING (parking)"Timed_waiting indicates the waiting state, but the time is specified here. After the specified time is reached, the waiting state is automatically exited. parking indicates that the thread is suspended. 2)"Waiting on condition"Needs to be associated with the"Parking to wait for <0x00000000acd84de8>(A java. util. concurrent. SynchronousQueue $ TransferStack. First, this thread must wait for a condition to wake itself up. Secondly, SynchronousQueue is not a queue, but a mechanism for transferring information between threads. When we put an element into SynchronousQueue, there must be another thread waiting for the task to be handed over, therefore, this is the condition that the thread is waiting. Example 3: "RMI RenewClean-[172.16.50.182: 4888]" daemon prio = 10 tid = 0x00000000000040d2c800 nid = 0x97eIn Object. wait ()[0x00007f9ccafd0000] java. lang. Thread. State:TIMED_WAITING (on object monitor)At java. lang. object. wait (Native Method)-waiting on <0x0000000799b032d8> (a java. lang. ref. referenceQueue $ Lock) at java. lang. ref. referenceQueue. remove (ReferenceQueue. java: 118)-locked <0x0000000799b032d8> (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)Reference resources:1) CUBRID, 2012, How to Analyze Java Thread Dumps; 2) Zheng Jing, 2013, three instances demonstrate Java THread Dump log analysis; a picture is given: