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