1, the thread status is "Waiting for monitor entry":means that it
waiting to enter a critical section, so it waits in the "Entry Set" queue. At this point the thread state is generally Blocked:
- Java.lang.Thread.State: BLOCKED (on object monitor)
2, the thread status is "Waiting on condition":Explain it
waiting for another condition to happen, to wake themselves up, or simply it is called sleep (N). At this point the thread state is roughly the following:
- Java.lang.Thread.State: waiting (parking): Always wait for that condition to happen;
- Java.lang.Thread.State: timed_waiting (parking or sleeping): timed, that condition does not come, also will wake themselves regularly.
3, if a large number of threads are
"Waiting for Monitor entry":A global lock may be blocking a large number of threads. If the thread dump file printed in a short time reflects, over time, the waiting for monitor entry threads more and more, without decreasing the trend that could mean
Some threads spend too much time in the critical section, so that more and more new threads are unable to enter the critical section .。
4, if a large number of threads are
"
Waiting on condition
":Maybe they ran to get third-party resources,
in particular, third-party network resources, delayed access to response, causing a large number of threads to enter the wait state. So if you find that there are a lot of threads in wait on condition, looking from the thread stack, waiting for the network to read and write
, which could be a symptom of a network bottleneckBecause the network blocking causes the thread to fail to execute.
The thread status is "in Object.wait ()":Explain it
after the monitor has been obtained, the java.lang.Object.wait () method is called。 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 monitor Entry", while the thread state waiting in "wait set" is "in Object.wait ()". When the thread obtains monitor, if the condition that the thread continues to run is not satisfied, it calls the Wait () method of the object (usually the object being synchronized), discards the monitor and enters the "Wait Set" queue. At this point the thread state is roughly the following:
- Java.lang.Thread.State: timed_waiting (on object monitor);
- Java.lang.Thread.State: waiting (on object monitor);
These are typically RMI-related threads (RMI Renewclean, GC Daemon, RMI Reaper), GC threads (Finalizer), and system threads such as the object garbage collection thread (Reference Handler) in this state. Figure 1 A Java Monitor demo one: The following thread is waiting for this lock
0x00000000fe7e3b50, waiting to enter the critical section: "RMI TCP Connection (64896) -172.16.52.118" daemon prio=10 tid=0x00000000405a6000 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 owns this lock? is another thread that called the findchanellgoodscountwithcache function first: "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)Model two: Wait for another condition to occur to wake yourself up: "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 <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 refers to the wait state, but the time is specified here, and the waiting state is automatically exited after the specified time; parking refers to the thread being suspended. 2) "
Waiting on condition"Need to be in the stack."
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, 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, so this is the condition that this thread is waiting for. Model three: "RMI renewclean-[172.16.50.182:4888]" daemon prio=10 tid=0x0000000040d2c800 nid=0x97e
In 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)
Various Java Thread State "reprint"
