Java怎樣處理InterruptedException

 Java 中的受檢查異常 InterruptedException 如何處理是令人頭痛的問題，下面是我對處理這個問題的理解。

Java 中的 InterruptedException 一直是一個令人頭疼的問題，對初級開發者來說尤其如此。但實際上不應如此，這其實是一個很容易理解的問題。我會盡可能簡單地描述這個問題。

我們從這段代碼開始：

while (true) {
  // Nothing
}

它做了什么？什么都沒做，只是無止境的消耗 CPU。我們能終止它嗎？在 Java 中是不行的。只有當你按下 Ctrl-C 來終止整個 JVM 時這段程序才會停止。在 Java 中沒有方式來終止一個線程，除非該線程自動退出。請務必牢記的這一原則，其它東西就顯而易見了。

我們將這個死循環放在一個線程里：

Thread loop = new Thread(
  new Runnable() {
    @Override
    public void run() {
      while (true) {
      }
    }
  }
);
loop.start();
// Now how do we stop it?

所以，怎樣才能停止一個需要停止的線程？

下面是 Java 中設計終止一個線程的方法。在線程的外部，設置一個標識變量（flag），然后在線程內部檢查改標識變量，從而實現線程的終止。過程如下：

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() 方法的設計（一種最基本的方法）：

public static void sleep(long millis)
  throws InterruptedException {
  while (/* You still need to wait */) {
    if (Thread.interrupted()) {
      throw new InterruptedException();
    }
    // Keep waiting
  }
}

為什么要這么做？為什么不能等待并且不用去檢查標識變量？我相信一定有一個非常好的理由。理由如下（如果我說錯了，請修正我的錯誤）：為了讓代碼變快或是中斷準備，沒有其他理由。

如果你的代碼足夠快，你從來不會檢測中斷標識變量，因為你不想處理任何中斷。如果你代碼很慢，可能需要執行數秒，這時你就有可能需要處理中斷了。

這就是為什么 InterruptedException 是受檢查異常。這種設計告訴你，如果你想在幾毫秒內停止線程，確定你已經做好中斷準備。實踐中一般做如下處理：

try {
  Thread.sleep(100);
} catch (InterruptedException ex) {
  // Stop immediately and go home
}

現在，你可以將它拋給負責捕獲該異常的上級程序去處理。這種觀點是有人在使用線程，并且會捕獲該異常。理想情況下，會終止線程，因為這就是標識變量的功能。如果拋出 InterruptedException，就意味著有人在檢查標識變量，線程需要盡可能快地終止。

線程的擁有者不想再等待線程執行，我們應該尊重擁有者的決定。

因此，當捕獲到 InterruptedException 時，你應該完成相關的操作再退出線程。

現在，我們再看一下 Thread.sleep() 的代碼：

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 的處理：

try {
  Thread.sleep(100);
} catch (InterruptedException ex) {
  throw new RuntimeException(ex);
}

這看起來是符合邏輯的，但是這不能保證上層程序真正停止并退出。上層可能捕獲了運行時異常，所以這個線程還是存活的。線程所有者將會非常失望。

我們必須通知上層捕獲了一個中斷請求。我們不能只拋出運行時異常，這種行為太不負責了。當一個線程接收一個中斷請求時，我們不能只是將其轉換成為一個 RuntimeException。我們不能將這種嚴峻的情況如此輕松地對待。

這是我們應該做的：

try {
  Thread.sleep(100);
} catch (InterruptedException ex) {
  Thread.currentThread().interrupt(); // Here!
  throw new RuntimeException(ex);
}

我們需要將標識變量重新設置為 true。

現在，沒有人會譴責我們以不負責的態度來處理標識變量。我們發現其狀態為 true，將其清理，重新設置為 true，最后拋出運行時異常。接下來會發生什么？我們已經不關心了。

這就是我認為的處理方式。你可以找到這個問題更詳細的官方描述：Java 理論與實踐：InterruptedException 處理