為什么wait()方法要放在同步塊

回顧一下，如果wait()方法不在同步塊中，代碼的確會拋出異常:

public class WaitInSyncBlockTest {

    @Test
    public void test() {
        try {
            new Object().wait();
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }
}

結果是：

Exception in thread "main" java.lang.IllegalMonitorStateException
    at java.lang.Object.wait(Native Method)
    at java.lang.Object.wait(Object.java:503)
    at com.kzx.test.juc.WaitInSyncBlockTest.main(WaitInSyncBlockTest.java:7)

 

為什么呢？

Lost Wake-Up Problem

事情得從一個多線程編程里面臭名昭著的問題"Lost wake-up problem"說起。

這個問題並不是說只在Java語言中會出現，而是會在所有的多線程環境下出現。

假如有兩個線程，一個消費者線程，一個生產者線程。生產者線程的任務可以簡化成將count加一，而后喚醒消費者；消費者則是將count減一，而后在減到0的時候陷入睡眠：

生產者偽代碼：

count+1;
notify();

 消費者偽代碼：

while(count<=0){
　　wait();
}
count--;

 

熟悉多線程的朋友一眼就能夠看出來，這里面有問題。什么問題呢？

生產者是兩個步驟：

1. count+1;

2. notify();

消費者也是兩個步驟：

1. 檢查count值；

2. 睡眠或者減一；

萬一這些步驟混雜在一起呢？比如說，初始的時候count等於0，這個時候消費者檢查count的值，發現count小於等於0的條件成立；就在這個時候，發生了上下文切換，生產者進來了，噼噼啪啪一頓操作，把兩個步驟都執行完了，也就是發出了通知，准備喚醒一個線程。這個時候消費者剛決定睡覺，還沒睡呢，所以這個通知就會被丟掉。緊接着，消費者就睡過去了……

 

這就是所謂的lost wake up問題。

那么怎么解決這個問題呢？

現在我們應該就能夠看到，問題的根源在於，消費者在檢查count到調用wait()之間，count就可能被改掉了。

這就是一種很常見的競態條件。

很自然的想法是，讓消費者和生產者競爭一把鎖，競爭到了的，才能夠修改count的值。

於是生產者的代碼是:

tryLock();

count+1;

notify();

releaseLock();

 

消費者的代碼是:

tryLock();

while(count<=0){
    wait();
}

count--;

releaseLock();

 

注意的是，我這里將兩者的兩個操作都放進去了同步塊中。

終極答案

所以，我們可以總結到，為了避免出現這種lost wake up問題，在這種模型之下，總應該將我們的代碼放進去的同步塊中。

Java強制我們的wait()/notify()調用必須要在一個同步塊中，就是不想讓我們在不經意間出現這種lost wake up問題。

不僅僅是這兩個方法，包括java.util.concurrent.locks.Condition的await()/signal()也必須要在同步塊中。

准確的來說，即便是我們自己在實現自己的鎖機制的時候，也應該要確保類似於wait()和notify()這種調用，要在同步塊內，防止使用者出現lost wake up問題。

Java的這種檢測是很嚴格的。它要求的是，一定要處於鎖對象的同步塊中。舉例來說：

private Object obj = new Object();
private Object anotherObj  = new Object();

@Test
public void produce(){
　　synchronized(obj){
　　　　try{
　　　　　　anotherObj.notify();;
　　　　}catch(Exception e){
　　　　　　e.printStackTrace();
　　　　}
　　}
}

這樣是沒有什么卵用的。一樣出現IllegalMonitorStateException。