suspend() 和 resume() 方法：兩個方法配套使用，suspend()使得執行緒進入阻塞狀態，並且不會自動恢復，必須其對應的 resume() 被呼叫，才能使得執行緒重新進入可執行狀態。典型地，suspend() 和 resume() 被用在等待另一個執行緒產生的結果的情 形：測試發現結果還沒有產生後，讓執行緒阻塞，另一個執行緒產生了結果後，呼叫 resume() 使其恢復。但suspend()方法很容易引起死鎖問題， 已經不推薦使用了。
    wait() 和 notify() 方法：兩個方法配套使用，wait() 使得執行緒進入阻塞狀態，它有兩種形式，一種允許 指定以毫秒為單位 的一段時間作為引數，另一種沒有引數，前者當對應的 notify() 被呼叫或者超出指定時間時執行緒重新進入可執行狀態，後者則必須對應 的 notify() 被呼叫。


初看起來它們與 suspend() 和 resume() 方法對沒有什麼分別，但是事實上它們是截然不同的。區別的核心在於，前面敘述的所有方法，阻塞時都不會釋放佔用的鎖（如果佔用了的話），而這一對方法則相反。


上述的核心區別導致了一系列的細節上的區別。


    首先，前面敘述的所有方法都隸屬於 Thread 類，但是這一對卻直接隸屬於 Object 類，也就是說，所有物件都擁有這一對方法。初看起來這十分 不可思議，但是實際上卻是很自然的，因為這一對方法阻塞時要釋放佔用的鎖，而鎖是任何物件都具有的，呼叫任意物件的 wait() 方法導致執行緒阻塞，並 且該物件上的鎖被釋放。而呼叫 任意物件的notify()方法則導致因呼叫該物件的 wait() 方法而阻塞的執行緒中隨機選擇的一個解除阻塞（但要等 到獲得鎖後才真正可執行）。
    其次，前面敘述的所有方法都可在任何位置呼叫，但是這一對方法卻必須在 synchronized 方法或塊中呼叫，理由也很簡單，只有在 synchronized 方法或塊中當前執行緒才佔有鎖，才有鎖可以釋放。同樣的道理，呼叫這一對方法的物件上的鎖必須為當前執行緒所擁有，這樣才有鎖可以 釋放。因此，這一對方法呼叫必須放置在這樣的 synchronized 方法或塊中，該方法或塊的上鎖物件就是呼叫這一對方法的物件。若不滿足這一條 件，則程式雖然仍能編譯，但在執行時會出現IllegalMonitorStateException 異常。
    wait() 和 notify() 方法的上述特性決定了它們經常和synchronized 方法或塊一起使用，將它們和作業系統的程序間通訊機制作 一個比較就會發現它們的相似性：synchronized方法或塊提供了類似於作業系統原語的功能，它們的執行不會受到多執行緒機制的干擾，而這一對方法則 相當於 block 和wakeup 原語（這一對方法均宣告為 synchronized）。它們的結合使得我們可以實現作業系統上一系列精妙的程序間 通訊的演算法（如訊號量演算法），並用於解決各種複雜的執行緒間通訊問題。


關於 wait() 和 notify() 方法最後再說明兩點：


    第一：呼叫 notify() 方法導致解除阻塞的執行緒是從因呼叫該物件的 wait() 方法而阻塞的執行緒中隨機選取的，我們無法預料哪一個執行緒將會被選擇，所以程式設計時要特別小心，避免因這種不確定性而產生問題。


    第二：除了 notify()，還有一個方法 notifyAll() 也可起到類似作用，唯一的區別在於，呼叫 notifyAll() 方法將把因調 用該物件的 wait() 方法而阻塞的所有執行緒一次性全部解除阻塞。當然，只有獲得鎖的那一個執行緒才能進入可執行狀態。


    談到阻塞，就不能不談一談死鎖，略一分析就能發現，suspend() 方法和不指定超時期限的 wait() 方法的呼叫都可能產生死鎖。遺憾的是，Java  並不在語言級別上支援死鎖的避免，我們在程式設計中必須小心地避免死鎖。


    以上我們對 Java  中實現執行緒阻塞的各種方法作了一番分析，我們重點分析了 wait() 和 notify() 方法，因為它們的功能最強大，使用也最靈活，但是這也導致了它們的效率較低，較容易出錯。實際使用中我們應該靈活使用各種方法，以便更好地達到我們的目的。