为什么我们不应该吞下 InterruptedException

Question

我很困惑，无法理解为什么不应该吞下 InterruptedException。

IBM 的文章说

当阻塞方法检测到中断并抛出 InterruptedException 时，它会清除中断状态。如果您捕获了 InterruptedException 但无法重新抛出它，您应该保留中断发生的证据以便调用堆栈上较高的代码可以了解中断并在需要时响应它

public class TaskRunner implements Runnable {
    private BlockingQueue<Task> queue;

    public TaskRunner(BlockingQueue<Task> queue) { 
        this.queue = queue; 
    }

    public void run() { 
        try {
             while (true) {
                 Task task = queue.take(10, TimeUnit.SECONDS);
                 task.execute();
             }
         }
         catch (InterruptedException e) { 
           Thread.currentThread().interrupt();//preserve the message
             return;//Stop doing whatever I am doing and terminate

         }
    }
}

另外，Java 并发实践在第 7.1.3 章：响应中断中更详细地讨论了这一点。它的规则是：

只有实现线程中断策略的代码才能吞下中断请求。通用任务和库代码不应吞下中断请求。

1.谁能解释更高调用堆栈中的代码如何利用 Thread.currentThread().interrupt() 设置的状态；线程终止时在catch块中？

还请解释一下上面的规则？

Answer 1

看一下这个示例，我们假设它在线程/线程池上下文中运行。

public void run() {
  // Honor interrupts so that you can stop/kill the task
  while (!Thread.currentThread().interrupted()) {
    this.doSomeChunkOfWork();
  }    
}

上面的代码是一个很好的例子，说明了如何编写一个可以被中断的任务并以块的形式处理数据（想想从一些源中读取数据并分段处理数据）。现在让我们假设doSomeChunkOfWork 被中断并且你捕获了一个异常。除非你再次设置标志或保持标志的中断状态，否则run方法将无法知道当方法调用返回时调用堆栈深处的处理被中断，这会扰乱我们的良好逻辑。

这就是为什么你总是将状态设置回来，以便调用堆栈中的方法知道线程是否真的被中断了。我想对此进行类比是“不要在地毯下扫尘”。 :)