各種 Java Thread State【轉載】
阿新 • • 發佈：2017-05-17
tin run 監視器 .com str ack tran queue 我們 1，線程狀態為“waiting for monitor entry”：
意味著它 在等待進入一個臨界區 ，所以它在”Entry Set“隊列中等待。
此時線程狀態一般都是 Blocked：
3，如果大量線程在“waiting for monitor entry”： 可能是一個全局鎖阻塞住了大量線程。 如果短時間內打印的 thread dump 文件反映，隨著時間流逝，waiting for monitor entry 的線程越來越多，沒有減少的趨勢，可能意味著某些線程在臨界區裏呆的時間太長了，以至於越來越多新線程遲遲無法進入臨界區。
4，如果大量線程在“waiting on condition”： 可能是它們又跑去獲取第三方資源，尤其是第三方網絡資源，遲遲獲取不到Response
線程狀態為“in Object.wait()”： 說明它獲得了監視器之後，又調用了 java.lang.Object.wait() 方法。 每個 Monitor在某個時刻，只能被一個線程擁有，該線程就是 “Active Thread”，而其它線程都是 “Waiting Thread”，分別在兩個隊列 “ Entry Set”和 “Wait Set”裏面等候。在 “Entry Set”中等待的線程狀態是 “Waiting for monitor entry”，而在 “Wait Set”中等待的線程狀態是 “in Object.wait()”。 當線程獲得了 Monitor，如果發現線程繼續運行的條件沒有滿足，它則調用對象（一般就是被 synchronized 的對象）的 wait() 方法，放棄了 Monitor，進入 “Wait Set”隊列。 此時線程狀態大致為以下幾種：
圖1 A Java Monitor
示範一：
下面這個線程在等待這個鎖 0x00000000fe7e3b50，等待進入臨界區：
"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)
那麽誰持有這個鎖呢？ 是另一個先調用了 findChanellGoodsCountWithCache 函數的線程： "RMI TCP Connection(64878)-172.16.52.117" daemon prio=10 tid=0x0000000040822000 nid=0x6841 runnable [0x00007f2be76b3000] java.lang.Thread.State: RUNNABLE at 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) 示範二： 等待另一個條件發生來將自己喚醒： "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 指等待狀態，但這裏指定了時間，到達指定的時間後自動退出等待狀態；parking指線程處於掛起中。 2）“waiting on condition”需要與堆棧中的“parking to wait for <0x00000000acd84de8> (a java.util.concurrent.SynchronousQueue$TransferStack)” 結合來看。首先，本線程肯定是在等待某個條件的發生，來把自己喚醒。其次，SynchronousQueue 並不是一個隊列，只是線程之間移交信息的機制，當我們把一個元素放入到 SynchronousQueue 中時必須有另一個線程正在等待接受移交的任務，因此這就是本線程在等待的條件。 示範三： "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)
- java.lang.Thread.State: BLOCKED (on object monitor)
- java.lang.Thread.State: WAITING (parking)：一直等那個條件發生；
- java.lang.Thread.State: TIMED_WAITING(parking或sleeping)：定時的，那個條件不到來，也將定時喚醒自己。
3，如果大量線程在“waiting for monitor entry”： 可能是一個全局鎖阻塞住了大量線程。 如果短時間內打印的 thread dump 文件反映，隨著時間流逝，waiting for monitor entry 的線程越來越多，沒有減少的趨勢，可能意味著某些線程在臨界區裏呆的時間太長了，以至於越來越多新線程遲遲無法進入臨界區。
4，如果大量線程在“waiting on condition”： 可能是它們又跑去獲取第三方資源，尤其是第三方網絡資源，遲遲獲取不到Response
線程狀態為“in Object.wait()”： 說明它獲得了監視器之後，又調用了 java.lang.Object.wait() 方法。 每個 Monitor在某個時刻，只能被一個線程擁有，該線程就是 “Active Thread”，而其它線程都是 “Waiting Thread”，分別在兩個隊列 “ Entry Set”和 “Wait Set”裏面等候。在 “Entry Set”中等待的線程狀態是 “Waiting for monitor entry”，而在 “Wait Set”中等待的線程狀態是 “in Object.wait()”。 當線程獲得了 Monitor，如果發現線程繼續運行的條件沒有滿足，它則調用對象（一般就是被 synchronized 的對象）的 wait() 方法，放棄了 Monitor，進入 “Wait Set”隊列。 此時線程狀態大致為以下幾種：
- java.lang.Thread.State: TIMED_WAITING(on object monitor)；
- java.lang.Thread.State: WAITING (on object monitor)；
圖1 A Java Monitor
示範一：
下面這個線程在等待這個鎖 0x00000000fe7e3b50，等待進入臨界區：
"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)
那麽誰持有這個鎖呢？ 是另一個先調用了 findChanellGoodsCountWithCache 函數的線程： "RMI TCP Connection(64878)-172.16.52.117" daemon prio=10 tid=0x0000000040822000 nid=0x6841 runnable [0x00007f2be76b3000] java.lang.Thread.State: RUNNABLE at 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) 示範二： 等待另一個條件發生來將自己喚醒： "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 指等待狀態，但這裏指定了時間，到達指定的時間後自動退出等待狀態；parking指線程處於掛起中。 2）“waiting on condition”需要與堆棧中的“parking to wait for <0x00000000acd84de8> (a java.util.concurrent.SynchronousQueue$TransferStack)” 結合來看。首先，本線程肯定是在等待某個條件的發生，來把自己喚醒。其次，SynchronousQueue 並不是一個隊列，只是線程之間移交信息的機制，當我們把一個元素放入到 SynchronousQueue 中時必須有另一個線程正在等待接受移交的任務，因此這就是本線程在等待的條件。 示範三： "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)
各種 Java Thread State【轉載】