[[181297]]

概述

本文有些東西是我自己的理解，比如為什么JDK一開始要這么設(shè)計(jì)，初衷是什么，沒(méi)怎么去找相關(guān)資料，所以只能談?wù)勛约旱睦斫猓源蠹铱吹轿恼轮罂梢哉務(wù)勛约旱目捶?，?duì)于實(shí)現(xiàn)部分我倒覺(jué)得說(shuō)清楚問(wèn)題不大，code is here，看明白了就知道怎么回事了。

Object.wait/notify(All)大家都知道主要是協(xié)同線程處理的，大家用得也很多，大概邏輯和下面的用法差不多

看到上面代碼，你會(huì)有什么疑惑嗎?至少我會(huì)有幾個(gè)問(wèn)題會(huì)問(wèn)自己： * 為什么進(jìn)入wait和notify的時(shí)候要加synchronized鎖 * 既然加了synchronized鎖，那當(dāng)某個(gè)線程調(diào)用了wait的時(shí)候明明還在synchronized塊里，其他線程怎么進(jìn)入到鎖里去執(zhí)行notify的 * 為什么wait方法可能會(huì)拋出InterruptedException異常 * 如果有多個(gè)線程都進(jìn)入wait狀態(tài)，那某個(gè)線程調(diào)用notify喚醒線程時(shí)是否按照順序喚起那些wait線程 * wait的線程是在某個(gè)線程執(zhí)行完notify之后立馬就被喚起嗎 * notifyAll又是怎么實(shí)現(xiàn)全喚起的 * wait的線程是否會(huì)影響load

如果上面這些問(wèn)題也都是你想了解的，那這篇文章或許能給你一個(gè)答案。

為何要加synchronized鎖

從實(shí)現(xiàn)上來(lái)說(shuō)，這個(gè)鎖至關(guān)重要，正因?yàn)檫@把鎖，才能讓整個(gè)wait/notify玩轉(zhuǎn)起來(lái)，當(dāng)然我覺(jué)得其實(shí)通過(guò)其他的方式也可以實(shí)現(xiàn)類似的機(jī)制，不過(guò)hotspot至少是完全依賴這把鎖來(lái)實(shí)現(xiàn)wait/notify的。

如果要我們來(lái)實(shí)現(xiàn)這種機(jī)制我們會(huì)怎么去做，我們知道wait/notify是為了線程間協(xié)作而設(shè)計(jì)的，當(dāng)我們執(zhí)行wait的時(shí)候讓線程掛起，當(dāng)執(zhí)行notify的時(shí)候喚醒其中一個(gè)掛起的線程，那需要有個(gè)地方來(lái)保存對(duì)象和線程之間的映射關(guān)系(可以想象一個(gè)map，key是對(duì)象，value是一個(gè)線程列表)，當(dāng)調(diào)用這個(gè)對(duì)象的wait方法時(shí)，將當(dāng)前線程放到這個(gè)線程列表里，當(dāng)調(diào)用這個(gè)對(duì)象的notify方法時(shí)從這個(gè)線程列表里取出一個(gè)來(lái)讓其繼續(xù)執(zhí)行，這樣看來(lái)是可行的，也比較簡(jiǎn)單，那現(xiàn)在的問(wèn)題這種映射關(guān)系放到哪里。而synchronized正好也是為線程間協(xié)作而設(shè)計(jì)的，上面碰到的問(wèn)題它也要解決，或許正因?yàn)檫@樣wait和notify的實(shí)現(xiàn)就直接依賴synchronzied(monitorenter/monitorexit是jvm規(guī)范里要求要去實(shí)現(xiàn)的)來(lái)實(shí)現(xiàn)了，這只是我的理解，可能初衷不是這個(gè)原因，這其實(shí)也是這篇文章遲遲未寫的一個(gè)原因吧，因?yàn)槲覠o(wú)法取證自己的理解是對(duì)的，歡迎各位在這塊談?wù)勛约旱囊娊狻?/p>

wait方法執(zhí)行后未退出同步塊，其他線程如何進(jìn)入同步塊

這個(gè)問(wèn)題其實(shí)要回答很簡(jiǎn)單，因?yàn)樵趙ait處理過(guò)程中會(huì)臨時(shí)釋放同步鎖，不過(guò)需要注意的是當(dāng)某個(gè)線程調(diào)用notify喚起了這個(gè)線程的時(shí)候，在wait方法退出之前會(huì)重新獲取這把鎖，只有獲取了這把鎖才會(huì)繼續(xù)執(zhí)行，想象一下，我們知道wait的方法是被monitorenter和monitorexit包圍起來(lái)，當(dāng)我們?cè)趫?zhí)行wait方法過(guò)程中如果釋放了鎖，出來(lái)的時(shí)候又不拿鎖，那在執(zhí)行到monitorexit指令的時(shí)候會(huì)發(fā)生什么?當(dāng)然這可以做兼容，不過(guò)這實(shí)現(xiàn)起來(lái)還是很奇怪的。

為什么wait方法可能拋出InterruptedException異常

這個(gè)異常大家應(yīng)該都知道，當(dāng)我們調(diào)用了某個(gè)線程的interrupt方法時(shí)，對(duì)應(yīng)的線程會(huì)拋出這個(gè)異常，wait方法也不希望破壞這種規(guī)則，因此就算當(dāng)前線程因?yàn)閣ait一直在阻塞，當(dāng)某個(gè)線程希望它起來(lái)繼續(xù)執(zhí)行的時(shí)候，它還是得從阻塞態(tài)恢復(fù)過(guò)來(lái)，因此wait方法被喚醒起來(lái)的時(shí)候會(huì)去檢測(cè)這個(gè)狀態(tài)，當(dāng)有線程interrupt了它的時(shí)候，它就會(huì)拋出這個(gè)異常從阻塞狀態(tài)恢復(fù)過(guò)來(lái)。

這里有兩點(diǎn)要注意： * 如果被interrupt的線程只是創(chuàng)建了，并沒(méi)有start，那等他start之后進(jìn)入wait態(tài)之后也是不能會(huì)恢復(fù)的 * 如果被interrupt的線程已經(jīng)start了，在進(jìn)入wait之前，如果有線程調(diào)用了其interrupt方法，那這個(gè)wait等于什么都沒(méi)做，會(huì)直接跳出來(lái)，不會(huì)阻塞

被notify(All)的線程有規(guī)律嗎

這里要分情況： * 如果是通過(guò)notify來(lái)喚起的線程，那先進(jìn)入wait的線程會(huì)先被喚起來(lái) * 如果是通過(guò)nootifyAll喚起的線程，默認(rèn)情況是***進(jìn)入的會(huì)先被喚起來(lái)，即LIFO的策略

notify執(zhí)行之后立馬喚醒線程嗎

其實(shí)這個(gè)大家可以驗(yàn)證一下，在notify之后寫一些邏輯，看這些邏輯是在其他線程被喚起之前還是之后執(zhí)行，這個(gè)是個(gè)細(xì)節(jié)問(wèn)題，可能大家并沒(méi)有關(guān)注到這個(gè)，其實(shí)hotspot里真正的實(shí)現(xiàn)是退出同步塊的時(shí)候才會(huì)去真正喚醒對(duì)應(yīng)的線程，不過(guò)這個(gè)也是個(gè)默認(rèn)策略，也可以改的，在notify之后立馬喚醒相關(guān)線程。

notifyAll是怎么實(shí)現(xiàn)全喚起的

或許大家立馬想到這個(gè)簡(jiǎn)單，一個(gè)for循環(huán)就搞定了，不過(guò)在jvm里沒(méi)實(shí)現(xiàn)這么簡(jiǎn)單，而是借助了monitorexit，上面我提到了當(dāng)某個(gè)線程從wait狀態(tài)恢復(fù)出來(lái)的時(shí)候，要先獲取鎖，然后再退出同步塊，所以notifyAll的實(shí)現(xiàn)是調(diào)用notify的線程在退出其同步塊的時(shí)候喚醒起***一個(gè)進(jìn)入wait狀態(tài)的線程，然后這個(gè)線程退出同步塊的時(shí)候繼續(xù)喚醒其倒數(shù)第二個(gè)進(jìn)入wait狀態(tài)的線程，依次類推，同樣這這是一個(gè)策略的問(wèn)題，jvm里提供了挨個(gè)直接喚醒線程的參數(shù)，不過(guò)都很罕見就不提了。

wait的線程是否會(huì)影響load

這個(gè)或許是大家比較關(guān)心的話題，因?yàn)殛P(guān)乎系統(tǒng)性能問(wèn)題，wait/nofity是通過(guò)jvm里的park/unpark機(jī)制來(lái)實(shí)現(xiàn)的，在linux下這種機(jī)制又是通過(guò)pthread_cond_wait/pthread_cond_signal來(lái)玩的，因此當(dāng)線程進(jìn)入到wait狀態(tài)的時(shí)候其實(shí)是會(huì)放棄cpu的，也就是說(shuō)這類線程是不會(huì)占用cpu資源。

【本文是51CTO專欄作者李嘉鵬的原創(chuàng)文章，轉(zhuǎn)載請(qǐng)通過(guò)微信公眾號(hào)(你假笨，id:lovestblog)聯(lián)系作者本人獲取授權(quán)】

戳這里，看該作者更多好文