Java的中斷是一種協作機制。也就是說呼叫執行緒物件的interrupt方法並不一定就中斷了正在執行的執行緒，它只是要求執行緒自己在合適的時機中斷自己。
一、Java中斷的現象
首先，看看Thread類裡的幾個方法：
| public static boolean interrupted | 測試當前執行緒是否已經中斷。執行緒的中斷狀態 由該方法清除。換句話說，如果連續兩次呼叫該方法，則第二次呼叫將返回 false（在第一次呼叫已清除了其中斷狀態之後，且第二次呼叫檢驗完中斷狀態前，當前執行緒再次中斷的情況除外）。 | |
|
測試執行緒是否已經中斷。執行緒的中斷狀態 不受該方法的影響。 | |
| public void interrupt() | 中斷執行緒。 |
上面列出了與中斷有關的幾個方法及其行為，可以看到interrupt是中斷執行緒。如果不瞭解Java的中斷機制，這樣的一種解釋極容易造成誤解，認為呼叫了執行緒的interrupt方法就一定會中斷執行緒。
其實，Java的中斷是一種協作機制。也就是說呼叫執行緒物件的interrupt方法並不一定就中斷了正在執行的執行緒，它只是要求執行緒自己在合適的時機中斷自己。每個執行緒都有一個boolean的中斷狀態（不一定就是物件的屬性，事實上，該狀態也確實不是Thread的欄位），interrupt方法僅僅只是將該狀態置為true 。
經執行可以發現，程式丟擲異常停止了，run方法裡的後兩條列印語句沒有執行。那麼，區別在哪裡？
一般說來，如果一個方法宣告丟擲InterruptedException，表示該方法是可中斷的（沒有在方法中處理中斷卻也宣告丟擲 InterruptedException的除外），也就是說可中斷方法會對interrupt呼叫做出響應（例如sleep響應interrupt的操 作包括清除中斷狀態，丟擲InterruptedException）。
如果interrupt呼叫是在可中斷方法之前呼叫，可中斷方法一定會處理中斷，像上面的例子，interrupt方法極可能在run未進入sleep的 時候就呼叫了，但sleep檢測到中斷，就會處理該中斷。如果在可中斷方法正在執行中的時候呼叫interrupt，會怎麼樣呢？這就要看可中斷方法處理 中斷的時機了，只要可中斷方法能檢測到中斷狀態為true，就應該處理中斷。讓我們為開頭的那段程式碼加上中斷處理。
那麼自定義的可中斷方法該如何處理中斷呢？那就是在適合處理中斷的地方檢測執行緒中斷狀態並處理。
這段程式碼中檢測中斷用了Thread的靜態方法interrupted，它將中斷狀態置為false，並將之前的狀態返回，而isInterrupted只是檢測中斷，並不改變中斷狀態。一般來說，處理過了中斷請求，應該將其狀態置為false。但具體還要看實際情形。
二、Java中斷的本質
在歷史上，Java試圖提供過搶佔式限制中斷，但問題多多，例如已被廢棄的 Thread.stop、Thread.suspend和 Thread.resume等。另一方面，出於Java應用程式碼的健壯性的考慮，降低了程式設計門檻，減少不清楚底層機制的程式設計師無意破壞系統的概率。
如今，Java的執行緒排程不提供搶佔式中斷，而採用協作式的中斷。其實，協作式的中斷，原理很簡單，就是輪詢某個表示中斷的標記，我們在任何普通程式碼的中都可以實現。
通常情況下，呼叫執行緒的interrupt方法，並不能立即引發中斷， 只是設定了JVM內部的中斷標記。因此，通過檢查中斷標記，應用程式可以做一些特殊操作，也可以完全忽略中斷。
你可能想，如果JVM只提供了這種簡陋的中斷機制，那和應用程式自己定義中斷變數並輪詢的方法相比，基本也沒有什麼優勢。
JVM內部中斷變數的主要優勢，就是對於某些情況，提供了模擬自動“中斷陷入”的機制。
在執行涉及執行緒排程的阻塞呼叫時（例如wait、sleep和join），如果發生中斷，被阻塞執行緒會“儘可能快的”丟擲InterruptedException。因此，我們就可以用下面的程式碼框架來處理執行緒阻塞中斷：
所謂“儘可能快”，我猜測JVM就是線上程排程排程的間隙檢查中斷變數，速度取決於JVM的實現和硬體的效能。
三、一些不會丟擲 InterruptedException 的執行緒阻塞操作
然而，對於某些執行緒阻塞操作，JVM並不會自動丟擲InterruptedException異常。例如，某些I/O操作和內部鎖操作。對於這類操作，可以用其他方式模擬中斷：
1）java.io中的非同步socket I/O
讀寫socket的時候，InputStream和OutputStream的read和write方法會阻塞等待，但不會響應java中斷。不過，呼叫Socket的close方法後，被阻塞執行緒會丟擲SocketException異常。
2）利用Selector實現的非同步I/O
如果執行緒被阻塞於Selector.select（在java.nio.channels中），呼叫wakeup方法會引起ClosedSelectorException異常。
3）鎖獲取
如果執行緒在等待獲取一個內部鎖，我們將無法中斷它。但是，利用Lock類的lockInterruptibly方法，我們可以在等待鎖的同時，提供中斷能力。
四、兩條程式設計原則
另外，在任務與執行緒分離的框架中，任務通常並不知道自身會被哪個執行緒呼叫，也就不知道呼叫執行緒處理中斷的策略。所以，在任務設定了執行緒中斷標記後，並不能確保任務會被取消。因此，有以下兩條程式設計原則：
1）除非你知道執行緒的中斷策略，否則不應該中斷它。
這條原則告訴我們，不應該直接呼叫Executer之類框架中執行緒的interrupt方法，應該利用諸如Future.cancel的方法來取消任務。
2）任務程式碼不該猜測中斷對執行執行緒的含義。
這條原則告訴我們，一般程式碼遇在到InterruptedException異常時，不應該將其捕獲後“吞掉”，而應該繼續向上層程式碼丟擲。
總之，Java中的非搶佔式中斷機制，要求我們必須改變傳統的搶佔式中斷思路，在理解其本質的基礎上，採用相應的原則和模式來程式設計。
Object類的wait方法的API：
http://bbs.csdn.net/topics/390253732
丟擲：
IllegalMonitorStateException - 如果當前的執行緒不是此物件監視器的所有者。
InterruptedException - 如果在當前執行緒等待通知之前或者正在等待通知時，另一個執行緒中斷了當前執行緒。在丟擲此異常時，當前執行緒的中斷狀態 被清除。
wait
public final void wait()
throws InterruptedException在其他執行緒呼叫此物件的 notify() 方法或 notifyAll() 方法前，導致當前執行緒等待。換句話說，此方法的行為就好像它僅執行 wait(0) 呼叫一樣。
當前執行緒必須擁有此物件監視器。該執行緒釋出對此監視器的所有權並等待，直到其他執行緒通過呼叫 notify 方法，或 notifyAll 方法通知在此物件的監視器上等待的執行緒醒來。然後該執行緒將等到重新獲得對監視器的所有權後才能繼續執行。
對於某一個引數的版本，實現中斷和虛假喚醒是可能的，而且此方法應始終在迴圈中使用：
synchronized (obj) {
while (<condition does not hold>)
obj.wait();
... // Perform action appropriate to condition
}
此方法只應由作為此物件監視器的所有者的執行緒來呼叫。有關執行緒能夠成為監視器所有者的方法的描述，請參閱 notify 方法。
丟擲：
IllegalMonitorStateException - 如果當前執行緒不是此物件監視器的所有者。
InterruptedException - 如果在當前執行緒等待通知之前或者正在等待通知時，任何執行緒中斷了當前執行緒。在丟擲此異常時，當前執行緒的中斷狀態 被清除。
http://my.oschina.net/bayuanqian/blog/160491