超強圖文｜並發編程【等待/通知機制】就是這個feel～

本文轉載自查看原文 2020-03-17 07:50 681 java

你有一個思想，我有一個思想，我們交換后，一個人就有兩個思想

If you can NOT explain it simply, you do NOT understand it well enough

現陸續將Demo代碼和技術文章整理在一起 Github實踐精選，方便大家閱讀查看，本文同樣收錄在此，覺得不錯，還請Star

並發編程為什么會有等待通知機制

上一篇文章說明了 Java並發死鎖解決思路，解決死鎖的思路之一就是 破壞請求和保持條件, 所有櫃員都要通過唯一的賬本管理員一次性拿到所有轉賬業務需要的賬本，就像下面這樣：

沒有等待/通知機制之前，所有櫃員都通過死循環的方式不斷向賬本管理員申請所有賬本，程序的體現就是這樣：

while(!accountBookManager.getAllRequiredAccountBook(this, target)) 
；

假如賬本管理員是年輕小伙，腿腳利落（即執行 getAllRequiredAccountBook方法耗時短），並且多個櫃員轉賬的業務沖突量不大，這個方案簡單粗暴且有效，櫃員只需要嘗試幾次就可以成功（即通過少量的循環可以實現）

過了好多年，年輕的賬本管理員變成了年邁的老人，行動遲緩（即執行 getAllRequiredAccountBook 耗時長），同時，多個櫃員轉賬的業務沖突量也變大，之前幾十次循環能做到的，現在可能就要申請成千上百，甚至上萬次才能完成一次轉賬

人工無限申請浪費口舌，程序無限申請浪費CPU。聰明的人就想到了 等待/通知 機制

等待/通知機制

無限循環實在太浪費CPU，而理想情況應該是這樣：

櫃員A如果拿不到所有賬本，就傲嬌的不再繼續問了（線程阻塞自己 wait）
櫃員B歸還了櫃員A需要的賬本之后就主動通知櫃員A賬本可用（通知等待的線程 notify/notifyAll）

做到這樣，就能避免循環等待消耗CPU的問題了

現實中有太多場景都在應用等待/通知機制。歡迎觀臨紅浪漫，比如去XX辦證，去醫院就醫/體檢。

下面請自行腦補一下去醫院就醫或體檢的畫面, 整體流程類似這樣：

序號	就醫	程序解釋（自己的視角）
1	掛號成功，到診室門口排號候診	排號的患者（線程）嘗試獲取【互斥鎖】
2	大夫叫到自己，進入診室就診	自己【獲取到互斥鎖】
3	大夫簡單詢問，要求做檢查（患者缺乏報告不能診斷病因）	進行【條件判斷】，線程要求的條件【沒滿足】
4	自己出去做檢查	線程【主動釋放】持有的互斥鎖
5	大夫叫下一位患者	另一位患者（線程）獲取到互斥鎖
6	自己拿到檢測報告	線程【曾經】要求的條件得到滿足（實則【被通知】）
7	再次在診室門口排號候診	再次嘗試獲取互斥鎖
8	...	...

在【程序解釋】一列，我將關鍵字（排隊、鎖、等待、釋放....）已經用 【】 框了起來。Java 語言中，其內置的關鍵字 synchronized 和方法wait()，notify()/notifyAll() 就能實現上面提到的等待/通知機制，我們將這幾個關鍵字實現流程現形象化的表示一下：

等待隊列圖

這可不是一個簡單的圖，下面還要圍繞這個圖做很多文章，不過這里我必須要插播幾個面試基礎知識點了：

一個鎖對應一個【入口等待隊列】，不同鎖的入口等待隊列沒任何關系，說白了他們就不存在競爭關系。你想呀，不同患者進入眼科和耳鼻喉科看大夫一點沖突都沒有
wait(), notify()/notifyAll() 要在 synchronized 內部被使用，並且，如果鎖的對象是this，就要 this.wait()，this.notify()/this.notifyAll() , 否則JVM就會拋出 java.lang.IllegalMonitorStateException 的。你想呀，等待/通知機制就是從【競爭】環境逐漸衍生出來的策略，不在鎖競爭內部使用或等待/通知錯了對象，自然是不符合常理的

有了上面知識的鋪墊，要想將無限循環策略改為等待通知策略，你還需要問自己四個問題：

靈魂 4 問

我們拿錢庄賬本管理員的例子依依做以上回答：

我們優化錢庄轉賬的程序：

public class AccountBookManager {

	List<Object> accounts = new ArrayList<>(2);

	synchronized boolean getAllRequiredAccountBook( Object from, Object to){
		if(accounts.contains(from) || accounts.contains(to)){
			try{
        this.wait();
      }catch(Exception e){
        
      }
		} else{
			accounts.add(from);
			accounts.add(to);

			return true;
		}
	}
	// 歸還資源
	synchronized void releaseObtainedAccountBook(Object from, Object to){
		accounts.remove(from);
		accounts.remove(to);
    notify();
	}
}

就這樣【看】【似】【完】【美】的解決了，其實上面的程序有兩個大坑：

坑一

在上面 this.wait() 處，使用了 if 條件判斷，會出現天大的麻煩，來看下圖（從下往上看）：

notify 喚醒的那一刻，線程【曾經/曾經/曾經】要求的條件得到了滿足，從這一刻開始，到去條件等隊列中喚醒線程，再到再次嘗試獲取鎖是有時間差的，當再次獲取到鎖時，線程曾經要求的條件是不一定滿足，所以需要重新進行條件判斷，所以需要將 if 判斷改成 while 判斷

synchronized boolean getAllRequiredAccountBook( Object from, Object to){
		while(accounts.contains(from) || accounts.contains(to)){
			try{
        this.wait();
      }catch(Exception e){
        
      }
		} else{
			accounts.add(from);
			accounts.add(to);

			return true;
		}
}

一個線程可以從掛起狀態變為可運行狀態（也就是被喚醒），即使線程沒有被其他線程調用notify()/notifyAll() 方法進行通知，或被中斷，或者等待超時，這就是所謂的【虛假喚醒】。雖然虛假喚醒很少發生，但要防患於未然，做法就是不停的去測試該線程被喚醒條件是否滿足

——摘自《Java並發編程之美》

有同學可能還會產生疑問，為什么while就可以？

因為被喚醒的線程再次獲取到鎖之后是從原來的 wait 之后開始執行的，wait在循環里面，所以會再次進入循環條件重新進行條件判斷。

如果不理解這個道理就記住一句話：

從哪里跌倒就從哪里爬起來；在哪里wait，就從wait那里繼續向后執行

所以，這也就成了使用wait()的標准范式

至於坑二，是線程歸還所使用的賬戶之后使用 notify 而不是 notifyAll 進行通知，由於坑很大，需要一些知識鋪墊來說明

為什么說盡量使用 notifyAll

notify() 和 notifyAll() 到底啥區別？

notify() 函數

隨機喚醒一個：一個線程調用共享對象的 notify() 方法，會喚醒一個在該共享變量上調用 wait() 方法后被掛起的線程，一個共享變量上可能有多個線程在等待，具體喚醒那一個，是隨機的

notifyAll() 函數

喚醒所有： 與notify() 不同，notifyAll() 會喚醒在該共享變量上由於調用wait() 方法而被掛起的所有線程

看個非常簡單的程序例子吧

示例程序一

@Slf4j
public class NotifyTest {

	private static volatile Object resourceA = new Object();

	public static void main(String[] args) throws InterruptedException {
		Thread threadA = new Thread(() -> {
				synchronized (resourceA){
					log.info("threadA get resourceA lock");

					try{
						log.info("threadA begins to wait");
						resourceA.wait();
						log.info("threadA ends wait");
					}catch (InterruptedException e){
						log.error(e.getMessage());
					}
				}
		});

		Thread threadB = new Thread(() -> {
			synchronized (resourceA){
				log.info("threadB get resourceA lock");

				try{
					log.info("threadB begins to wait");
					resourceA.wait();
					log.info("threadB ends wait");
				}catch (InterruptedException e){
					log.error(e.getMessage());
				}
			}
		});

		Thread threadC = new Thread(() -> {
			synchronized (resourceA){
				log.info("threadC begin to notify");
				resourceA.notify();
			}
		});

		threadA.start();
		threadB.start();

		Thread.sleep(1000);

		threadC.start();

		threadA.join();
		threadB.join();
		threadC.join();

		log.info("main thread over now");
	}
}

來看運行結果

程序中我們使用notify()隨機通知resourceA的等待隊列的一個線程，threadA被喚醒，threadB卻沒有打印出 threadB ends wait 這句話，遺憾的死掉了

將 notify() 換成 notifyAll() 的結果想必你已經知道了

使用 notifyAll() 確實不會遺落等待隊列中的線程，但也產生了比較強烈的競爭，如果notify() 設計的本身就是 bug，那么這個函數應該早就從 JDK 中移除了，它隨機通知一個線程的形式必定是有用武之地的

什么時候可以使用 notify()

notify() 的典型的應用就是線程池（按照上面的三個條件你自問自答驗證一下是這樣嗎？）

這里我們拿一個 JUC 下的類來看看 notify() 的用處

Tips:

notify() 等同於 signal()

wait() 等同於 await()

在IDE中，打開 ArrayBlockingQueue.java

所有的入隊 public 方法offer()/put() 內部都調用了 private 的 enqueue() 方法

所有的出隊 public 方法poll()/take() 內部都調用了 private 的 dequeue() 方法

將這個模型進行精簡就是下面這個樣子：

public class SimpleBlockingQueue<T> {

	final Lock lock = new ReentrantLock();
	// 條件變量：隊列不滿
	final Condition notFull = lock.newCondition();
	// 條件變量：隊列不空
	final Condition notEmpty = lock.newCondition();

	// 入隊
	void enq(T x) {
		lock.lock();
		try {
			while (隊列已滿){
				// 等待隊列不滿
				notFull.await();
			}
			// 省略入隊操作...
			//入隊后,通知可出隊
			notEmpty.signal();
		}finally {
			lock.unlock();
		}
	}
	// 出隊
	void deq(){
		lock.lock();
		try {
			while (隊列已空){
				// 等待隊列不空
				notEmpty.await();
			}
			// 省略出隊操作...
			//出隊后，通知可入隊
			notFull.signal();
		}finally {
			lock.unlock();
		}
	}
}

如果滿足上面這三個條件，notify() 的使用就恰到好處；我們用使用 notify()的條件進行驗證