java 中的受檢查異常 InterruptedException 如何處理是令人頭痛的問題，下面是我對處理這個問題的理解。
Java 中的 InterruptedException 一直是一個令人頭疼的問題，對初級開發者來說尤其如此。但實際上不應如此，這其實是一個很容易理解的問題。我會盡可能簡單地描述這個問題。
我們從這段代碼開始：
1 2 3 | while (true) { // Nothing} |
它做了什么？什么都沒做，只是無止境的消耗 CPU。我們能終止它嗎？在 Java 中是不行的。只有當你按下 Ctrl-C 來終止整個 JVM 時這段程序才會停止。在 Java 中沒有方式來終止一個線程，除非該線程自動退出。請務必牢記的這一原則，其它東西就顯而易見了。
我們將這個死循環放在一個線程里：
1 2 3 4 5 6 7 8 9 10 11 | Thread loop = new Thread( new Runnable() { @Override public void run() { while (true) { } } });loop.start();// Now how do we stop it? |
所以，怎樣才能停止一個需要停止的線程？
下面是 Java 中設計終止一個線程的方法。在線程的外部，設置一個標識變量（flag），然后在線程內部檢查改標識變量，從而實現線程的終止。過程如下：
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | Thread loop = new Thread( new Runnable() { @Override public void run() { while (true) { if (Thread.interrupted()) { break; } // Continue to do nothing } } });loop.start();loop.interrupt(); |
這是終止線程的唯一方式，在這個例子里使用了兩個方法。當調用 loop.interrupt() ，線程內部將標志位設置為 true。當調用 interrupted() 時，立即返回，并將標識變量設置為 false。確實，這個方法就是這樣設計的。檢查標識變量、返回、設置為 false。我知道這很丑陋。
因此，我從來沒有在線程內調用 Thread.interrupted() 方法，因此標識變量為 true 時線程不會退出，沒有人能停止這個線程。準確地說，我會忽略他們對 interrupt() 方法的調用。雖然它們會要求終止線程，但是我會忽略它們。它們不能讓線程中斷。
因此，總結一下我們現在理解的內容，一種合理的設計是通過檢查標識變量來優雅地終止線程。如果代碼中不檢測標識變量，也不調用 Thread.interrupted()，那么終止線程的方式就只能按下 Ctrl-C 了。
現在你聽明白這個邏輯了嗎？我希望是。
現在，JDK 中有一些方法來檢測標識變量，如果設置該標識變量，則會拋出 InterruptedException。例如，Thread.sleep() 方法的設計（一種最基本的方法）：
1 2 3 4 5 6 7 8 9 | public static void sleep(long millis) throws InterruptedException { while (/* You still need to wait */) { if (Thread.interrupted()) { throw new InterruptedException(); } // Keep waiting }} |
為什么要這么做？為什么不能等待并且不用去檢查標識變量？我相信一定有一個非常好的理由。理由如下（如果我說錯了，請修正我的錯誤）：為了讓代碼變快或是中斷準備，沒有其他理由。
如果你的代碼足夠快，你從來不會檢測中斷標識變量，因為你不想處理任何中斷。如果你代碼很慢，可能需要執行數秒，這時你就有可能需要處理中斷了。
這就是為什么 InterruptedException 是受檢查異常。這種設計告訴你，如果你想在幾毫秒內停止線程，確定你已經做好中斷準備。實踐中一般做如下處理：
1 2 3 4 5 | try { Thread.sleep(100);} catch (InterruptedException ex) { // Stop immediately and go home} |
現在，你可以將它拋給負責捕獲該異常的上級程序去處理。這種觀點是有人在使用線程，并且會捕獲該異常。理想情況下，會終止線程，因為這就是標識變量的功能。如果拋出 InterruptedException，就意味著有人在檢查標識變量，線程需要盡可能快地終止。
線程的擁有者不想再等待線程執行，我們應該尊重擁有者的決定。
因此，當捕獲到 InterruptedException 時，你應該完成相關的操作再退出線程。
現在，我們再看一下 Thread.sleep() 的代碼：
1 2 3 4 5 6 7 8 | public static void sleep(long millis) throws InterruptedException { while (/* ... */) { if (Thread.interrupted()) { throw new InterruptedException(); } }} |
請記住，Thread.interrupted() 不僅僅是返回標識變量的值，而且會將標識變量的值設置為 false。因此，一旦拋出 InterruptedException 異常，標志變量將會重置。線程不再收到任何擁有者發送的中斷請求。
線程的所有者要求停止線程，Thread.sleep() 監測到該請求并將其刪除，再拋出 InterruptedException。如果你再次調用 Thread.sleep()，就不會響應任何中斷請求，也不會拋出任何異常。
知道我想要說的是什么嗎？不要丟失 InterruptedException，這一點非常重要。我們不能吞噬該異常并繼續運行。這嚴重違背了 Java 多線程原則。所有者（線程的所有者）要求停止線程，而我們卻將其忽略，這是非常不好的想法。
下面是大多數人對 InterruptedException 的處理：
1 2 3 4 5 | try { Thread.sleep(100);} catch (InterruptedException ex) { throw new RuntimeException(ex);} |
這看起來是符合邏輯的，但是這不能保證上層程序真正停止并退出。上層可能捕獲了運行時異常，所以這個線程還是存活的。線程所有者將會非常失望。
我們必須通知上層捕獲了一個中斷請求。我們不能只拋出運行時異常，這種行為太不負責了。當一個線程接收一個中斷請求時，我們不能只是將其轉換成為一個 RuntimeException。我們不能將這種嚴峻的情況如此輕松地對待。
這是我們應該做的：
1 2 3 4 5 6 | try { Thread.sleep(100);} catch (InterruptedException ex) { Thread.currentThread().interrupt(); // Here! throw new RuntimeException(ex);} |
我們需要將標識變量重新設置為 true。
現在，沒有人會譴責我們以不負責的態度來處理標識變量。我們發現其狀態為 true，將其清理，重新設置為 true，最后拋出運行時異常。接下來會發生什么？我們已經不關心了。
這就是我認為的處理方式。你可以找到這個問題更詳細的官方描述：Java 理論與實踐：InterruptedException 處理
原文鏈接： https://dzone.com/articles/how-to-handle-the-interruptedexception 翻譯：ImportNew.com - paddx
譯文鏈接： http://www.importnew.com/17027.html
全能程序員交流QQ群290551701，聚集很多互聯網精英,技術總監,架構師,項目經理!開源技術研究,歡迎業內人士,大牛及新手有志于從事IT行業人員進入!
新聞熱點
疑難解答
