Wait-Notify場景
典型的Wait-Notify場景一般與以下兩個內容相關：
1. 狀態變量（State Variable）
當線程需要wait的時候，總是因為一些條件得不到滿足導致的。例如往隊列里填充數據，當隊列元素已經滿時，線程就需要wait停止運行。當隊列元素有空缺時，再繼續自己的執行。
2. 條件斷言（Condition Predicate）
當線程確定是否進入wait或者是從notify醒來的時候是否繼續往下執行，大部分都要測試狀態條件是否滿足。例如，往隊列里添加元素，隊列已滿，于是阻塞當前線程，當有其他線程從隊列里取走了元素，就通知在等待的線程“隊列有剩余空間，可以往里添加元素了”。這時，等待添加元素的進程就會被喚醒，然后判斷一下當前隊列是否真的有剩余空間，如果真的有剩余空間，就將元素添加進去，如果沒有，則繼續阻塞等待下次喚醒。
3. 條件隊列（Condition Queue）
每個對象都有一個內置的條件隊列，當一個線程在該對象鎖上調用wait函數的時候，就會將該線程加入到該對象的條件隊列中。

注意
wait與notify是Java同步機制中的重要組成部分。結合與synchronized關鍵字使用，可以建立很多優秀的同步模型，例如生產者-消費者模型。但是在使用wait()、notify()、notifyAll()函數的時候，需要特別注意以下幾點：

    wait()、notify()、notifyAll()方法不屬于Thread類，而是屬于Object基礎類，也就是說每個對象都有wait()、notify()、notifyAll()的功能。因為每個對象都有鎖，鎖是每個對象的基礎，因此操作鎖的方法也是最基礎的。
    調用obj的wait(), notify()方法前，必須獲得obj鎖，也就是必須寫在synchronized(obj){...} 代碼段內。
    調用obj.wait()后，線程A就釋放了obj的鎖，否則線程B無法獲得obj鎖，也就無法在synchronized(obj){...} 代碼段內喚醒線程A。
    當obj.wait()方法返回后，線程A需要再次獲得obj鎖，才能繼續執行。
    如果線程A1,A2,A3都在obj.wait()，則線程B調用obj.notify()只能喚醒線程A1,A2,A3中的一個（具體哪一個由JVM決定）。
    如果線程B調用obj.notifyAll()則能全部喚醒等待的線程A1,A2,A3，但是等待的線程要繼續執行obj.wait()的下一條語句，必須獲得obj鎖。因此，線程A1,A2,A3只有一個有機會獲得鎖繼續執行，例如A1，其余的需要等待A1釋放obj鎖之后才能繼續執行。
    當線程B調用obj.notify()或者obj.notifyAll()的時候，線程B正持有obj鎖，因此，線程A1,A2,A3雖被喚醒，但是仍無法獲得obj鎖。直到線程B退出synchronized代碼塊，釋放obj鎖后，線程A1,A2,A3中的一個才有機會獲得對象鎖并得以繼續執行。

示例代碼
線程的wait操作的典型代碼結構如下：

  public void test() throws InterruptedException {     synchronized(obj) {       while (! contidition) {         obj.wait();       }     }   } 

為什么obj.wait()操作必須位于循環中呢？有以下幾個主要原因：
1. 一個對象鎖可能用于保護多個狀態變量，當它們都需要wait-notify操作時，如果不將wait放到while循環中就會有問題。例如，某對象鎖obj保護兩種狀態變量a和b，當a的條件斷言不成立時發生了wait操作，當b的條件斷言不成立時也發生了wait操作，兩個線程被加入到obj對應的條件隊列中?，F在若改變狀態變量a的某操作發生，在obj上調用了notifyAll操作，則obj對應的條件隊列里的所有線程均被喚醒，之前等待a的一個或幾個線程去判斷a的條件斷言可能成立了，但是b對于的條件斷言肯定仍不成立，而此時等待b的線程也被喚醒了，所以需要循環判斷b的條件斷言是否滿足，如果不滿足，則繼續wait。
2. 多個線程wait的同一狀態的條件斷言。例如，向隊列添加元素的場景，當前隊列是滿的，多個線程想往里面添加元素，于是都wait了。此時，另一個線程從隊列里取出了一個元素，調用了notifyAll操作，喚醒了所有線程，但是只有一個線程能夠往隊列里添加一個元素，其他的仍需要等待。
3. 虛假喚醒。在沒有被通知、中斷或超時的情況下，線程自動蘇醒了。雖然這種情況在實踐中很少發生，但是通過循環等待可以杜絕這一情況的發生。