Java中的等待喚醒機(jī)制—至少50%的工程師還沒掌握！

這是一篇走心的填坑筆記，自學(xué)Java的幾年總是在不斷學(xué)習(xí)新的技術(shù)，一路走來發(fā)現(xiàn)自己踩坑無數(shù)，而填上的坑卻屈指可數(shù)。突然發(fā)現(xiàn)，有時(shí)候真的不是幾年工作經(jīng)驗(yàn)的問題，有些東西即使工作十年，沒有用心去學(xué)習(xí)過也不過是一個(gè)10年大坑罷了（真實(shí)感受）。


剛開始接觸多線程時(shí)，就知道有等待/喚醒這個(gè)東西，寫過一個(gè)demo就再也沒有看過了，至于它到底是個(gè)什么東西，或者說它能解決什么樣的問題，估計(jì)大多數(shù)人和我一樣都是模棱兩可。這次筆者就嘗試帶你搞懂等待/喚醒機(jī)制，讀完本文你將get到以下幾點(diǎn)：

* 循環(huán)等待帶來什么樣的問題
* 用等待喚醒機(jī)制優(yōu)化循環(huán)等待
* 等待喚醒機(jī)制中的被忽略的細(xì)節(jié)
一,循環(huán)等待問題

假設(shè)今天要發(fā)工資，強(qiáng)老板要去吃一頓好的，整個(gè)就餐流程可以分為以下幾個(gè)步驟：

* 點(diǎn)餐
* 窗口等待出餐
* 就餐 public static void main(String[] args) { // 是否還有包子 AtomicBoolean hasBun
= new AtomicBoolean(); // 包子鋪老板 new Thread(() -> { try { // 一直循環(huán)查看是否還有包子 while
(true) { if (hasBun.get()) { System.out.println("老板：檢查一下是否還剩下包子...");
Thread.sleep(3000); } else { System.out.println("老板：沒有包子了, 馬上開始制作...");
Thread.sleep(1000); System.out.println("老板：包子出鍋咯...."); hasBun.set(true); } } }
catch (InterruptedException e) { e.printStackTrace(); } }).start(); new
Thread(() -> { System.out.println("小強(qiáng)：我要買包子..."); try { // 每隔一段時(shí)間詢問是否完成 while
(!hasBun.get()) { System.out.println("小強(qiáng)：包子咋還沒做好呢~"); Thread.sleep(3000); }
System.out.println("小強(qiáng)：終于吃上包子了...."); } catch (InterruptedException e) {
e.printStackTrace(); } }).start(); }


在上文代碼中存在一個(gè)很大的問題，就是老板需要不斷的去檢查是否還有包子，而客戶則需要隔一段時(shí)間去看催一下老板，這顯然是不合理的，這就是典型的循環(huán)等待問題。



這種問題的代碼中通常是如下這種模式：
while (條件不滿足) { Thread.sleep(3000); } doSomething();
對應(yīng)到計(jì)算機(jī)中，則暴露了一個(gè)問題：不斷通過輪詢機(jī)制來檢測條件是否成立， 如果輪詢時(shí)間過小則會浪費(fèi)CPU資源，如果間隔過大，又導(dǎo)致不能及時(shí)獲取想要的資源。

二，等待/喚醒機(jī)制

為了解決循環(huán)等待消耗CPU以及信息及時(shí)性問題，Java中提供了等待喚醒機(jī)制。通俗來講就是由主動變?yōu)楸粍樱?
當(dāng)條件成立時(shí)，主動通知對應(yīng)的線程，而不是讓線程本身來詢問。

2.1 基本概念


等待/喚醒機(jī)制，又叫等待通知（筆者更喜歡叫喚醒而非通知），是指線程A調(diào)用了對象O的wait()方法進(jìn)入了等待狀態(tài)，而另一個(gè)線程調(diào)用了O的notify()或者notifyAll()方法，線程A收到通知后從對象O的wait()方法返回，進(jìn)而執(zhí)行后續(xù)操作。

上訴過程是通過對象O，使得線程A和線程B之間進(jìn)行通信,
在線程中調(diào)用了對象O的wait()方法后線程久進(jìn)入了阻塞狀態(tài)，而在其他線程中對象O調(diào)用notify()或notifyAll方法時(shí)，則會喚醒對應(yīng)的阻塞線程。

2.2 基本API

等待/喚醒機(jī)制的相關(guān)方法是任意Java對象具備的，因?yàn)檫@些方法被定義在所有Java對象的超類Object中。

notify： 通知一個(gè)在對象上等待的線程，使其從wait()方法返回，而返回的前提是該線程獲取到對象的鎖

notifyAll: 通知所有等待在該對象上的線程

wait: 調(diào)用此方法的線程進(jìn)入阻塞等待狀態(tài)，只有等待另外線程的通知或者被中斷才會返回，調(diào)用wait方法會釋放對象的鎖

wait(long) : 等待超過一段時(shí)間沒有被喚醒就超時(shí)自動返回，單位是毫秒。

2.3 用等待喚醒機(jī)制優(yōu)化循環(huán)等待
public static void main(String[] args) { // 是否還有包子 AtomicBoolean hasBun = new
AtomicBoolean(); // 鎖對象 Object lockObject = new Object(); // 包子鋪老板 new
Thread(() -> { try { while (true) { synchronized (lockObject) { if
(hasBun.get()) { System.out.println("老板：包子夠賣了，打一把王者榮耀"); lockObject.wait(); }
else { System.out.println("老板：沒有包子了, 馬上開始制作..."); Thread.sleep(3000);
System.out.println("老板：包子出鍋咯...."); hasBun.set(true); // 通知等待的食客
lockObject.notifyAll(); } } } } catch (InterruptedException e) {
e.printStackTrace(); } }).start(); new Thread(() -> {
System.out.println("小強(qiáng)：我要買包子..."); try { synchronized (lockObject) { if
(!hasBun.get()) { System.out.println("小強(qiáng)：看一下有沒有做好， 看公眾號cruder有沒有新文章");
lockObject.wait(); } else { System.out.println("小強(qiáng)：包子終于做好了，我要吃光它們....");
hasBun.set(false); lockObject.notifyAll(); System.out.println("小強(qiáng)：一口氣把店里包子吃光了，
快快樂樂去板磚了~~"); } } } catch (InterruptedException e) { e.printStackTrace(); }
}).start(); }


上述流程，減少了輪詢檢查的操作，并且線程調(diào)用wait()方法后，會釋放鎖，不會消耗CPU資源，進(jìn)而提高了程序的性能。

三，等待喚醒機(jī)制的基本范式

等待、喚醒是線程間通信的手段之一，用來協(xié)調(diào)多個(gè)線程操作同一個(gè)數(shù)據(jù)源。實(shí)際應(yīng)用中通常用來優(yōu)化循環(huán)等待的問題，針對等待方和通知方，可以提煉出如下的經(jīng)典范式。

需要注意的是，在等待方執(zhí)行的邏輯中，一定要用while循環(huán)來判斷等待條件，因?yàn)閳?zhí)行
notify/notifyAll方法時(shí)只是讓等待線程從wait方法返回，而非重新進(jìn)入臨界區(qū)
/** * 等待方執(zhí)行的邏輯 * 1. 獲取對象的鎖 * 2. 檢查條件，如果條件不滿足，調(diào)用對象的wait方法，被通知后重新檢查條件 * 3.
條件滿足則執(zhí)行對應(yīng)的邏輯 */ synchronized(對象){ while(條件不滿足){ 對象.wait() } doSomething(); }
/** * ??！ 通知方執(zhí)行的邏輯 * 1. 獲取對象的鎖 * 2. 改變條件 * 3. 通知(所有)等待在對象上的線程 */
synchronized(對象){ 條件改變 對象.notify(); }
這個(gè)編程范式通常是針對典型的通知方和等待方，有時(shí)雙方可能具有雙重身份，即使等待方又是通知方，正如我們上文中的案例一樣。

四，notify/notifyAll不釋放鎖

相信這個(gè)問題有半數(shù)工程師都不知道，
當(dāng)執(zhí)行wait()方法，鎖自動被釋放；但執(zhí)行完notify()方法后，鎖不會釋放，而是要執(zhí)行notify()方法所在的synchronized代碼塊后才會釋放。
這一點(diǎn)很重要，也是很多工程師容易忽略的地方。
lockObject.notifyAll(); System.out.println("小強(qiáng)：一口氣把店里包子吃光了， 快快樂樂去板磚了~~");
案例代碼中，故意設(shè)置成先notifyAll，然后在打??；上文圖中的結(jié)果也印證了了我們的描述，感興趣的小伙伴可以動手執(zhí)行一下案例代碼哦。

五，等待、喚醒必須先獲取鎖

在等待、喚醒編程范式中的wait，notify，notifyAll方法往往不能直接調(diào)用， 需要在獲取鎖之后的臨界區(qū)執(zhí)行

并且只能喚醒等待在同一把鎖上的線程。


當(dāng)線程調(diào)用wait方法時(shí)會被加入到一個(gè)等待隊(duì)列，當(dāng)執(zhí)行notify時(shí)會喚醒隊(duì)列中第一個(gè)等待線程(等待時(shí)間最長的線程)，而調(diào)用notifyAll時(shí)則會喚醒等待線程中所有的等待線程
。



六，sleep不釋放鎖 而wait 釋放

在用等待喚醒機(jī)制優(yōu)化循環(huán)等待的過程中，有一個(gè)重要的特征就是原本的sleep()方法用wait()方法取代，他們的最大的區(qū)別在于
wait方法會釋放鎖，而sleep不會，除此之外，還有個(gè)重要的區(qū)別，
sleep是Thread的方法，可以在任意地方執(zhí)行；而wait是Object對象的方法，必須在synchronized代碼塊中執(zhí)行。

• ? 上一篇： SpringBoot-Security-用戶權(quán)限分配-查找用戶的菜單權(quán)限
• ? 下一篇： 好程序員Java教程分享Java之設(shè)計(jì)模式