啃碎併發（八）：深刻分析wait¬ify原理

前言

=====

上一節講了Synchronized關鍵詞的原理與優化分析，而配合Synchronized使用的另外兩個關鍵詞wait¬ify是本章講解的重點。最簡單的東西，每每包含了最複雜的實現，由於須要爲上層的存在提供一個穩定的基礎，Object做爲Java中全部對象的基類，其存在的價值不言而喻，其中wait&notify方法的實現多線程協做提供了保證。

1 源碼

---

今天咱們要學習或者說分析的是 Object 類中的 wait&notify 這兩個方法，其實說是兩個方法，這兩個方法包括他們的重載方法一共有 5 個，而 Object 類中一共才 12 個方法，可見這 2 個方法的重要性。咱們先看看 JDK 中的代碼：

就是這五個方法。其中有 3 個方法是 native 的，也就是由虛擬機本地的 c 代碼執行的。有 2 個 wait 重載方法最終仍是調用了 wait（long） 方法。

1.wait方法：wait是要釋放對象鎖，進入等待池。既然是釋放對象鎖，那麼確定是先要得到鎖。因此wait必需要寫在synchronized代碼塊中，不然會報異常。

2.notify方法：也須要寫在synchronized代碼塊中，調用對象的這兩個方法也須要先得到該對象的鎖。notify，notifyAll，喚醒等待該對象同步鎖的線程，並放入該對象的鎖池中。對象的鎖池中線程能夠去競爭獲得對象鎖，而後開始執行。

另一點比較重要，notify，notifyAll調用時並不會釋放對象鎖。好比如下代碼：

雖然調用了notifyAll，可是緊接着進入了一個死循環。致使一直不能出臨界區，一直不能釋放對象鎖。因此，即便它把全部在等待池中的線程都喚醒放到了對象的鎖池中，可是鎖池中的全部線程都不會運行，由於他們始終拿不到鎖。

===

2 用法

====

簡單示例：

執行結果：

前提：必須由同一個lock對象調用wait、notify方法

lock對象、線程A和線程B三者是一種什麼關係？根據上面的結論，能夠想象一個場景：

3 相關疑問

3.1 爲什麼wait&notify必需要加synchronized鎖

---

從實現上來講，這個鎖相當重要，正由於這把鎖，才能讓整個wait/notify玩轉起來，固然我以爲其實經過其餘的方式也能夠實現相似的機制，不過hotspot至少是徹底依賴這把鎖來實現wait/notify的。

synchronized 代碼塊經過javap生成的字節碼中包含 monitorenter 和 monitorexit 指令。以下圖所示：

javap生成的字節碼

執行 monitorenter 指令能夠獲取對象的monitor，而 lock.wait() 方法經過調用native方法wait(0)實現，其中接口註釋中有這麼一句：

表示線程執行 lock.wait() 方法時，必須持有該lock對象的monitor，若是wait方法在synchronized代碼中執行，該線程很顯然已經持有了monitor。

---

3.2 爲何wait方法可能拋出InterruptedException異常

---

這個異常你們應該都知道，當咱們調用了某個線程的interrupt方法時，對應的線程會拋出這個異常，wait方法也不但願破壞這種規則，所以就算當前線程由於wait一直在阻塞，當某個線程但願它起來繼續執行的時候，它仍是得從阻塞態恢復過來，所以wait方法被喚醒起來的時候會去檢測這個狀態，當有線程interrupt了它的時候，它就會拋出這個異常從阻塞狀態恢復過來。

這裏有兩點要注意：

3.3 notify執行以後立馬喚醒線程嗎

---

其實hotspot裏真正的實現是退出同步塊的時候纔會去真正喚醒對應的線程，不過這個也是個默認策略，也能夠改的，在notify以後立馬喚醒相關線程。

---

3.4 notifyAll是怎麼實現全喚起全部線程

---

或許你們立馬想到這個簡單，一個for循環就搞定了，不過在JVM裏沒實現這麼簡單，而是藉助了monitorexit，上面提到了當某個線程從wait狀態恢復出來的時候，要先獲取鎖，而後再退出同步塊，因此notifyAll的實現是調用notify的線程在退出其同步塊的時候喚醒起最後一個進入wait狀態的線程，而後這個線程退出同步塊的時候繼續喚醒其倒數第二個進入wait狀態的線程，依次類推，一樣這這是一個策略的問題，JVM裏提供了挨個直接喚醒線程的參數，不過都很罕見就不提了。

---

3.5 wait的線程是否會影響load

---

這個或許是你們比較關心的話題，由於關乎系統性能問題，wait/nofity是經過JVM裏的park/unpark機制來實現的，在Linux下這種機制又是經過

pthread_cond_wait/pthread_cond_signal來玩的，所以當線程進入到wait狀態的時候實際上是會放棄cpu的，也就是說這類線程是不會佔用cpu資源