線程通信的目標是使線程間能夠互相發送信號。另一方面，線程通信使線程能夠等待其他線程的信號。
通過共享對象通信
線程間發送信號的一個簡單方式是在共享對象的變量裡設置信號值。線程A 在一個同步塊裡設置boolean 型成員變量hasDataToProcess 為true，線程B 也在同步塊裡讀取hasDataToProcess 這個成員變量。這個簡單的例子使用了一個持有信號的對象，並提供了set 和check 方法:
public class MySignal{ protected boolean hasDataToProcess = false; public synchronized boolean hasDataToProcess(){ return this.hasDataToProcess; } public synchronized void setHasDataToProcess(boolean hasData){ this.hasDataToProcess = hasData; }}線程A 和B 必須獲得指向一個MySignal 共享實例的引用，以便進行通信。如果它們持有的引用指向不同的MySingal 實例，那麼彼此將不能檢測到對方的信號。需要處理的數據可以存放在一個共享緩存區裡，它和MySignal 實例是分開存放的。
忙等待(Busy Wait)
準備處理數據的線程B 正在等待數據變為可用。換句話說，它在等待線程A 的一個信號，這個信號使hasDataToProcess()返回true。線程B 運行在一個循環裡，以等待這個信號：
protected MySignal sharedSignal = ......while(!sharedSignal.hasDataToProcess()){ //do nothing... busy waiting}wait()，notify()和notifyAll()
忙等待沒有對運行等待線程的CPU 進行有效的利用，除非平均等待時間非常短。否則，讓等待線程進入睡眠或者非運行狀態更為明智，直到它接收到它等待的信號。
Java 有一個內建的等待機制來允許線程在等待信號的時候變為非運行狀態。 java.lang.Object 類定義了三個方法，wait()、notify()和notifyAll()來實現這個等待機制。
一個線程一旦調用了任意對象的wait()方法，就會變為非運行狀態，直到另一個線程調用了同一個對象的notify()方法。為了調用wait()或者notify()，線程必須先獲得那個對象的鎖。也就是說，線程必須在同步塊裡調用wait()或者notify()。以下是MySingal 的修改版本――使用了wait()和notify()的MyWaitNotify：
public class MonitorObject{}public class MyWaitNotify{ MonitorObject myMonitorObject = new MonitorObject(); public void doWait(){ synchronized(myMonitorObject){ try{ myMonitorObject.wait(); } catch(InterruptedException e){...} } } public void doNotify(){ synchronized(myMonitorObject){ myMonitorObject.notify(); } }}等待線程將調用doWait()，而喚醒線程將調用doNotify()。當一個線程調用一個對象的notify()方法，正在等待該對象的所有線程中將有一個線程被喚醒並允許執行（校注：這個將被喚醒的線程是隨機的，不可以指定喚醒哪個線程）。同時也提供了一個notifyAll()方法來喚醒正在等待一個給定對象的所有線程。
如你所見，不管是等待線程還是喚醒線程都在同步塊裡調用wait()和notify()。這是強制性的！一個線程如果沒有持有對象鎖，將不能調用wait()，notify()或者notifyAll()。否則，會拋出IllegalMonitorStateException 異常。
（校注：JVM 是這麼實現的，當你調用wait 時候它首先要檢查下當前線程是否是鎖的擁有者，不是則拋出IllegalMonitorStateExcept。）
但是，這怎麼可能？等待線程在同步塊裡面執行的時候，不是一直持有監視器對象（myMonitor 對象）的鎖嗎？等待線程不能阻塞喚醒線程進入doNotify()的同步塊嗎？答案是：的確不能。一旦線程調用了wait()方法，它就釋放了所持有的監視器對像上的鎖。這將允許其他線程也可以調用wait()或者notify()。
一旦一個線程被喚醒，不能立刻就退出wait()的方法調用，直到調用notify()的
public class MyWaitNotify2{ MonitorObject myMonitorObject = new MonitorObject(); boolean wasSignalled = false; public void doWait(){ synchronized(myMonitorObject){ if(!wasSignalled){ try{ myMonitorObject.wait(); } catch(InterruptedException e){...} } //clear signal and continue running. wasSignalled = false; } } public void doNotify(){ synchronized(myMonitorObject){ wasSignalled = true; myMonitorObject.notify(); } }}
線程退出了它自己的同步塊。換句話說：被喚醒的線程必須重新獲得監視器對象的鎖，才可以退出wait()的方法調用，因為wait 方法調用運行在同步塊裡面。如果多個線程被notifyAll()喚醒，那麼在同一時刻將只有一個線程可以退出wait()方法，因為每個線程在退出wait()前必須獲得監視器對象的鎖。
丟失的信號（Missed Signals）
notify()和notifyAll()方法不會保存調用它們的方法，因為當這兩個方法被調用時，有可能沒有線程處於等待狀態。通知信號過後便丟棄了。因此，如果一個線程先於被通知線程調用wait()前調用了notify()，等待的線程將錯過這個信號。這可能是也可能不是個問題。不過，在某些情況下，這可能使等待線程永遠在等待，不再醒來，因為線程錯過了喚醒信號。
為了避免丟失信號，必須把它們保存在信號類裡。在MyWaitNotify 的例子中，通知信號應被存儲在MyWaitNotify 實例的一個成員變量裡。以下是MyWaitNotify 的修改版本：
public class MyWaitNotify2{ MonitorObject myMonitorObject = new MonitorObject(); boolean wasSignalled = false; public void doWait(){ synchronized(myMonitorObject){ if(!wasSignalled){ try{ myMonitorObject.wait(); } catch(InterruptedException e){...} } //clear signal and continue running. wasSignalled = false; } } public void doNotify(){ synchronized(myMonitorObject){ wasSignalled = true; myMonitorObject.notify(); } }}留意doNotify()方法在調用notify()前把wasSignalled 變量設為true。同時，留意doWait()方法在調用wait()前會檢查wasSignalled 變量。事實上，如果沒有信號在前一次doWait()調用和這次doWait()調用之間的時間段裡被接收到，它將只調用wait()。
（校注：為了避免信號丟失， 用一個變量來保存是否被通知過。在notify 前，設置自己已經被通知過。在wait 後，設置自己沒有被通知過，需要等待通知。）
假喚醒
由於莫名其妙的原因，線程有可能在沒有調用過notify()和notifyAll()的情況下醒來。這就是所謂的假喚醒（spurious wakeups）。無端端地醒過來了。
如果在MyWaitNotify2 的doWait()方法裡發生了假喚醒，等待線程即使沒有收到正確的信號，也能夠執行後續的操作。這可能導致你的應用程序出現嚴重問題。
為了防止假喚醒，保存信號的成員變量將在一個while 循環裡接受檢查，而不是在if 表達式裡。這樣的一個while 循環叫做自旋鎖（校注：這種做法要慎重，目前的JVM 實現自旋會消耗CPU，如果長時間不調用doNotify 方法，doWait 方法會一直自旋，CPU 會消耗太大）。被喚醒的線程會自旋直到自旋鎖(while 循環)裡的條件變為false。以下MyWaitNotify2 的修改版本展示了這點：
public class MyWaitNotify3{ MonitorObject myMonitorObject = new MonitorObject(); boolean wasSignalled = false; public void doWait(){ synchronized(myMonitorObject){ while(!wasSignalled){ try{ myMonitorObject.wait(); } catch(InterruptedException e){...} } //clear signal and continue running. wasSignalled = false; } } public void doNotify(){ synchronized(myMonitorObject){ wasSignalled = true; myMonitorObject.notify(); } }}留意wait()方法是在while 循環裡，而不在if 表達式裡。如果等待線程沒有收到信號就喚醒，wasSignalled 變量將變為false，while 循環會再執行一次，促使醒來的線程回到等待狀態。
多個線程等待相同信號
如果你有多個線程在等待，被notifyAll()喚醒，但只有一個被允許繼續執行，使用while 循環也是個好方法。每次只有一個線程可以獲得監視器對象鎖，意味著只有一個線程可以退出wait()調用並清除wasSignalled 標誌（設為false）。一旦這個線程退出doWait()的同步塊，其他線程退出wait()調用，並在while 循環裡檢查wasSignalled 變量值。但是，這個標誌已經被第一個喚醒的線程清除了，所以其餘醒來的線程將回到等待狀態，直到下次信號到來。
不要在字符串常量或全局對像中調用wait()
（校注：本章說的字符串常量指的是值為常量的變量）
本文早期的一個版本在MyWaitNotify 例子裡使用字符串常量（””）作為管程對象。以下是那個例子：
public class MyWaitNotify{ String myMonitorObject = ""; boolean wasSignalled = false; public void doWait(){ synchronized(myMonitorObject){ while(!wasSignalled){ try{ myMonitorObject.wait(); } catch(InterruptedException e){...} } //clear signal and continue running. wasSignalled = false; } } public void doNotify(){ synchronized(myMonitorObject){ wasSignalled = true; myMonitorObject.notify(); } }}在空字符串作為鎖的同步塊(或者其他常量字符串)裡調用wait()和notify()產生的問題是，JVM/編譯器內部會把常量字符串轉換成同一個對象。這意味著，即使你有2 個不同的MyWaitNotify 實例，它們都引用了相同的空字符串實例。同時也意味著存在這樣的風險：在第一個MyWaitNotify 實例上調用doWait()的線程會被在第二個MyWaitNotify 實例上調用doNotify()的線程喚醒。這種情況可以畫成以下這張圖：
起初這可能不像個大問題。畢竟，如果doNotify()在第二個MyWaitNotify 實例上被調用，真正發生的事不外乎線程A 和B 被錯誤的喚醒了。這個被喚醒的線程（A 或者B）將在while 循環裡檢查信號值，然後回到等待狀態，因為doNotify()並沒有在第一個MyWaitNotify 實例上調用，而這個正是它要等待的實例。這種情況相當於引發了一次假喚醒。線程A 或者B 在信號值沒有更新的情況下喚醒。但是代碼處理了這種情況，所以線程回到了等待狀態。記住，即使4 個線程在相同的共享字符串實例上調用wait()和notify()，doWait()和doNotify()裡的信號還會被2 個MyWaitNotify 實例分別保存。在MyWaitNotify1 上的一次doNotify()調用可能喚醒MyWaitNotify2 的線程，但是信號值只會保存在MyWaitNotify1 裡。
問題在於，由於doNotify()僅調用了notify()而不是notifyAll()，即使有4 個線程在相同的字符串（空字符串）實例上等待，只能有一個線程被喚醒。所以，如果線程A 或B 被發給C 或D 的信號喚醒，它會檢查自己的信號值，看看有沒有信號被接收到，然後回到等待狀態。而C 和D 都沒被喚醒來檢查它們實際上接收到的信號值，這樣信號便丟失了。這種情況相當於前面所說的丟失信號的問題。 C 和D 被發送過信號，只是都不能對信號作出回應。
如果doNotify()方法調用notifyAll()，而非notify()，所有等待線程都會被喚醒並依次檢查信號值。線程A 和B 將回到等待狀態，但是C 或D 只有一個線程注意到信號，並退出doWait()方法調用。 C 或D 中的另一個將回到等待狀態，因為獲得信號的線程在退出doWait()的過程中清除了信號值(置為false)。
看過上面這段後，你可能會設法使用notifyAll()來代替notify()，但是這在性能上是個壞主意。在只有一個線程能對信號進行響應的情況下，沒有理由每次都去喚醒所有線程。
所以：在wait()/notify()機制中，不要使用全局對象，字符串常量等。應該使用對應唯一的對象。例如，每一個MyWaitNotify3 的實例擁有一個屬於自己的監視器對象，而不是在空字符串上調用wait()/notify()。
以上就是關於Java 多線程，線程通信的資料整理，後續繼續補充相關資料，謝謝大家對本站的支持！