JVM源碼分析之Object.wait/notify(All)完全解讀
概述
本文有些東西是我自己的理解，比如為什么JDK一開始要這么設計，初衷是什么，沒怎么去找相關資料，所以只能談談自己的理解，所以大家看到文章之后可以談談自己的看法，對于實現部分我倒覺得說清楚問題不大，code is here，看明白了就知道怎么回事了。
Object.wait/notify(All)大家都知道主要是協同線程處理的，大家用得也很多，大概邏輯和下面的用法差不多
看到上面代碼，你會有什么疑惑嗎?至少我會有幾個問題會問自己： * 為什么進入wait和notify的時候要加synchronized鎖 * 既然加了synchronized鎖，那當某個線程調用了wait的時候明明還在synchronized塊里，其他線程怎么進入到鎖里去執行notify的 * 為什么wait方法可能會拋出InterruptedException異常 * 如果有多個線程都進入wait狀態，那某個線程調用notify喚醒線程時是否按照順序喚起那些wait線程 * wait的線程是在某個線程執行完notify之后立馬就被喚起嗎 * notifyAll又是怎么實現全喚起的 * wait的線程是否會影響load
如果上面這些問題也都是你想了解的，那這篇文章或許能給你一個答案。
為何要加synchronized鎖
從實現上來說，這個鎖至關重要，正因為這把鎖，才能讓整個wait/notify玩轉起來，當然我覺得其實通過其他的方式也可以實現類似的機制，不過hotspot至少是完全依賴這把鎖來實現wait/notify的。
如果要我們來實現這種機制我們會怎么去做，我們知道wait/notify是為了線程間協作而設計的，當我們執行wait的時候讓線程掛起，當執行notify的時候喚醒其中一個掛起的線程，那需要有個地方來保存對象和線程之間的映射關系(可以想象一個map，key是對象，value是一個線程列表)，當調用這個對象的wait方法時，將當前線程放到這個線程列表里，當調用這個對象的notify方法時從這個線程列表里取出一個來讓其繼續執行，這樣看來是可行的，也比較簡單，那現在的問題這種映射關系放到哪里。而synchronized正好也是為線程間協作而設計的，上面碰到的問題它也要解決，或許正因為這樣wait和notify的實現就直接依賴synchronzied(monitorenter/monitorexit是jvm規范里要求要去實現的)來實現了，這只是我的理解，可能初衷不是這個原因，這其實也是這篇文章遲遲未寫的一個原因吧，因為我無法取證自己的理解是對的，歡迎各位在這塊談談自己的見解。
wait方法執行后未退出同步塊，其他線程如何進入同步塊
這個問題其實要回答很簡單，因為在wait處理過程中會臨時釋放同步鎖，不過需要注意的是當某個線程調用notify喚起了這個線程的時候，在wait方法退出之前會重新獲取這把鎖，只有獲取了這把鎖才會繼續執行，想象一下，我們知道wait的方法是被monitorenter和monitorexit包圍起來，當我們在執行wait方法過程中如果釋放了鎖，出來的時候又不拿鎖，那在執行到monitorexit指令的時候會發生什么?當然這可以做兼容，不過這實現起來還是很奇怪的。
為什么wait方法可能拋出InterruptedException異常
這個異常大家應該都知道，當我們調用了某個線程的interrupt方法時，對應的線程會拋出這個異常，wait方法也不希望破壞這種規則，因此就算當前線程因為wait一直在阻塞，當某個線程希望它起來繼續執行的時候，它還是得從阻塞態恢復過來，因此wait方法被喚醒起來的時候會去檢測這個狀態，當有線程interrupt了它的時候，它就會拋出這個異常從阻塞狀態恢復過來。
這里有兩點要注意： * 如果被interrupt的線程只是創建了，并沒有start，那等他start之后進入wait態之后也是不能會恢復的 * 如果被interrupt的線程已經start了，在進入wait之前，如果有線程調用了其interrupt方法，那這個wait等于什么都沒做，會直接跳出來，不會阻塞
被notify(All)的線程有規律嗎
這里要分情況： * 如果是通過notify來喚起的線程，那先進入wait的線程會先被喚起來 * 如果是通過nootifyAll喚起的線程，默認情況是***進入的會先被喚起來，即LIFO的策略
notify執行之后立馬喚醒線程嗎
其實這個大家可以驗證一下，在notify之后寫一些邏輯，看這些邏輯是在其他線程被喚起之前還是之后執行，這個是個細節問題，可能大家并沒有關注到這個，其實hotspot里真正的實現是退出同步塊的時候才會去真正喚醒對應的線程，不過這個也是個默認策略，也可以改的，在notify之后立馬喚醒相關線程。
notifyAll是怎么實現全喚起的
或許大家立馬想到這個簡單，一個for循環就搞定了，不過在jvm里沒實現這么簡單，而是借助了monitorexit，上面我提到了當某個線程從wait狀態恢復出來的時候，要先獲取鎖，然后再退出同步塊，所以notifyAll的實現是調用notify的線程在退出其同步塊的時候喚醒起***一個進入wait狀態的線程，然后這個線程退出同步塊的時候繼續喚醒其倒數第二個進入wait狀態的線程，依次類推，同樣這這是一個策略的問題，jvm里提供了挨個直接喚醒線程的參數，不過都很罕見就不提了。
wait的線程是否會影響load
這個或許是大家比較關心的話題，因為關乎系統性能問題，wait/nofity是通過jvm里的park/unpark機制來實現的，在linux下這種機制又是通過pthread_cond_wait/pthread_cond_signal來玩的，因此當線程進入到wait狀態的時候其實是會放棄cpu的，也就是說這類線程是不會占用cpu資源。
【本文是51CTO專欄作者李嘉鵬的原創文章，轉載請通過微信公眾號(你假笨，id:lovestblog)聯系作者本人獲取授權】
