當(dāng)線程的狀態(tài)為 waiting for monitor entry [0x17e8f0jg0]，預(yù)示著線程被阻塞了,在等待進(jìn)入一個臨界區(qū) java.lang.Thread.State: BLOCKED (on object monitor)

當(dāng)線程的狀態(tài)為waiting on condition預(yù)示這他在等待另一個條件的發(fā)生，來將自己喚醒或者是直接調(diào)用了sleep方法。 java.lang.Thread.State: WAITING (parking)：一直等那個條件發(fā)生； java.lang.Thread.State: TIMED_WAITING (parking或sleeping)：定時的，那個條件不到來，也將定時喚醒自己。

如果大量的線程在waiting for monitor entry那么非常有可能是一個全局的鎖阻塞了這些線程。如果短時間 內(nèi)thread dump 的信息反映的是隨著時間流逝，waiting for monitor entry 的線程越來越多，沒有減少的趨勢，可能意味著某些線程在臨界區(qū)里呆的時間太長了，以至于越來越多新線程遲遲無法進(jìn)入臨界區(qū)。

線程狀態(tài)為“in Object.wait()”：說明它獲得了監(jiān)視器之后，又調(diào)用了 java.lang.Object.wait() 方法。每個 Monitor在某個時刻，只能被一個線程擁有，該線程就是 “Active Thread”，而其它線程都是 “Waiting Thread”，分別在兩個隊列 “ Entry Set”和 “Wait Set”里面等候。在 “Entry Set”中等待的線程狀態(tài)是 “Waiting for monitor entry”，而在 “Wait Set”中等待的線程狀態(tài)是 “in Object.wait()”。 當(dāng)線程獲得了 Monitor，如果發(fā)現(xiàn)線程繼續(xù)運行的條件沒有滿足，它則調(diào)用對象（一般就是被 synchronized 的對象）的 wait() 方法，放棄了 Monitor，進(jìn)入 “Wait Set”隊列。 此時線程狀態(tài)大致為以下幾種：

java.lang.Thread.State: TIMED_WAITING (on object monitor)； java.lang.Thread.State: WAITING (on object monitor)； 一般都是RMI相關(guān)線程（RMI RenewClean、 GC Daemon、RMI Reaper），GC線程（Finalizer），引用對象垃圾回收線程（Reference Handler）等系統(tǒng)線程處于這種狀態(tài)。

實例一：Waiting to lock 和 Blocked

說明： 1）線程狀態(tài)是 Blocked，阻塞狀態(tài)。說明線程等待資源超時！ 2）“ waiting to lock <0x00000000acf4d0c0>”指，線程在等待給這個 0x00000000acf4d0c0 地址上鎖（英文可描述為：trying to obtain 0x00000000acf4d0c0 lock）。 3）在 dump 日志里查找字符串 0x00000000acf4d0c0，發(fā)現(xiàn)有大量線程都在等待給這個地址上鎖。如果能在日志里找到誰獲得了這個鎖（如locked < 0x00000000acf4d0c0 >），就可以順藤摸瓜了。 4）“waiting for monitor entry”說明此線程通過 synchronized(obj) {……} 申請進(jìn)入了臨界區(qū)，從而進(jìn)入了下圖1中的“Entry Set”隊列，但該 obj 對應(yīng)的 monitor 被其他線程擁有，所以本線程在 Entry Set 隊列中等待。 5）第一行里，”RMI TCP Connection(267865)-172.16.5.25”是 Thread Name 。tid指Java Thread id。nid指native線程的id。prio是線程優(yōu)先級。[0x00007fd4f8684000]是線程棧起始地址。

實例二：Waiting on condition 和 TIMED_WAITING

1）“TIMED_WAITING (parking)”中的 timed_waiting 指等待狀態(tài)，但這里指定了時間，到達(dá)指定的時間后自動退出等待狀態(tài)；parking指線程處于掛起中。

2）“waiting on condition”需要與堆棧中的“parking to wait for <0x00000000acd84de8> (a java.util.concurrent.SynchronousQueue$TransferStack)”結(jié)合來看。首先，本線程肯定是在等待某個條件的發(fā)生，來把自己喚醒。其次，SynchronousQueue 并不是一個隊列，只是線程之間移交信息的機(jī)制，當(dāng)我們把一個元素放入到 SynchronousQueue 中時必須有另一個線程正在等待接受移交的任務(wù)，因此這就是本線程在等待的條件。 3）別的就看不出來了。

實例三：in Obejct.wait() 和 TIMED_WAITING

說明：

1）“TIMED_WAITING (on object monitor)”，對于本例而言，是因為本線程調(diào)用了 java.lang.Object.wait(long timeout) 而進(jìn)入等待狀態(tài)。

2）“Wait Set”中等待的線程狀態(tài)就是“ in Object.wait() ”。當(dāng)線程獲得了 Monitor，進(jìn)入了臨界區(qū)之后，如果發(fā)現(xiàn)線程繼續(xù)運行的條件沒有滿足，它則調(diào)用對象（一般就是被 synchronized 的對象）的 wait() 方法，放棄了 Monitor，進(jìn)入 “Wait Set”隊列。只有當(dāng)別的線程在該對象上調(diào)用了 notify() 或者 notifyAll() ，“ Wait Set”隊列中線程才得到機(jī)會去競爭，但是只有一個線程獲得對象的 Monitor，恢復(fù)到運行態(tài)。

3）RMI RenewClean 是 DGCClient 的一部分。DGC 指的是 Distributed GC，即分布式垃圾回收。

4）請注意，是先 locked <0x00000000aa672478>，后 waiting on <0x00000000aa672478>，之所以先鎖再等同一個對象，請看下面它的代碼實現(xiàn)： static private class Lock { }; private Lock lock = new Lock(); public Reference