不要吞下中断
有时抛出 InterruptedException 不是一种选择，例如当通过 Runnable 调用可中断方法定义的任务时。在这种情况下，你不能重新抛出 InterruptedException，但你也不想做任何事情。当阻塞方法检测到中断和抛出时 InterruptedException，它会清除中断状态。如果你抓住 InterruptedException 但不能重新抛出它，你应该保留中断发生的证据，以便调用堆栈上的代码可以了解中断并在需要时响应它。此任务通过调用 interrupt()实现“重新中断”当前线程，如清单3所示。至少，无论何时捕获 InterruptedException 并且不重新抛出它，都要在返回之前重新中断当前线程。
清单3.捕获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(); } } }
你可以做的最糟糕的事情 InterruptedException 就是吞下它 - 抓住它，既不重新抛出它也不重新确定线程的中断状态。处理你没有规划的异常的标准方法 - 捕获它并记录它 - 也算作吞噬中断，因为调用堆栈上的代码将无法找到它。（记录 InterruptedException 也很愚蠢，因为当人类读取日志时，对它做任何事都为时已晚。）清单4显示了吞下中断的常见模式：
清单4.吞下中断 - 不要这样做
// 不要这么做! 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 swallowed) { /* DON'T DO THIS - RESTORE THE INTERRUPTED STATUS INSTEAD */ /* 不要这么做 - 要让线程中断 */ } } }
如果你不能重新抛出 InterruptedException，无论你是否计划对中断请求执行操作，你仍然希望重新中断当前线程，因为单个中断请求可能有多个“收件人”。标准线程池（ThreadPoolExecutor）工作线程实现响应中断，因此中断线程池中运行的任务可能具有取消任务和通知执行线程线程池正在关闭的效果。如果作业吞下中断请求，则工作线程可能不会知道请求了中断，这可能会延迟应用程序或服务关闭。
实施可取消的任务
语言规范中没有任何内容给出任何特定语义的中断，但在较大的程序中，除了取消之外，很难保持中断的任何语义。根据活动，用户可以通过 GUI 或通过 JMX 或 Web 服务等网络机制请求取消。它也可以由程序逻辑请求。例如，如果 Web 爬虫检测到磁盘已满，则可能会自动关闭自身，或者并行算法可能会启动多个线程来搜索解决方案空间的不同区域，并在其中一个找到解决方案后取消它们。
仅仅因为一个任务是取消并不意味着它需要一个中断请求响应立即。对于在循环中执行代码的任务，通常每次循环迭代仅检查一次中断。根据循环执行的时间长短，在任务代码通知线程中断之前可能需要一些时间（通过使用 Thread.isInterrupted()或通过调用阻塞方法轮询中断状态）。如果任务需要更具响应性，则可以更频繁地轮询中断状态。阻止方法通常在进入时立即轮询中断状态，InterruptedException 如果设置为提高响应性则抛出 。
吞下一个中断是可以接受的，当你知道线程即将退出时。这种情况只发生在调用可中断方法的类是一个 Thread，而不是 Runnable 一般或通用库代码的一部分时，如清单5所示。它创建一个枚举素数的线程，直到它被中断并允许线程退出中断。寻求主要的循环在两个地方检查中断：一次是通过轮询 isInterrupted() while 循环的头部中的方法，一次是在调用阻塞 BlockingQueue.put() 方法时。
清单5.如果你知道线程即将退出，则可以吞下中断
public class PrimeProducer extends Thread { private final BlockingQueue<BigInteger> queue; PrimeProducer(BlockingQueue<BigInteger> queue) { this.queue = queue; } public void run() { try { BigInteger p = BigInteger.ONE; while (!Thread.currentThread().isInterrupted()) queue.put(p = p.nextProbablePrime()); } catch (InterruptedException consumed) { /* Allow thread to exit */ /* 允许线程退出 */ } } public void cancel() { interrupt(); } }
不间断阻塞
并非所有阻止方法都抛出 InterruptedException。输入和输出流类可能会阻止等待 I/O 完成，但它们不会抛出InterruptedException，并且如果它们被中断，它们不会提前返回。但是，在套接字 I/O 的情况下，如果一个线程关闭了套接字，那么阻塞其他线程中该套接字上的 I/O 操作将在早期完成SocketException。非阻塞 I/O 类 java.nio 也不支持可中断 I/O，但可以通过关闭通道或请求唤醒来类似地取消阻塞操作 Selector。同样，尝试获取内在锁（输入一个 synchronized 块）不能被中断，但 ReentrantLock 支持可中断的采集模式。
不可取消的任务
有些任务只是拒绝被打断，使它们无法取消。但是，即使是不可取消的任务也应该尝试保留中断状态，以但在调用堆栈上层的代码在非可取消任务完成后想要对发生的中断进行响应。清单6显示了一个等待阻塞队列直到某个项可用的方法，无论它是否被中断。为了成为一个好公民，它在完成后恢复最终块中的中断状态，以免剥夺呼叫者的中断请求。它无法提前恢复中断状态，因为它会导致无限循环 - BlockingQueue.take(), 完成后则可以在进入时立即轮询中断状态, 如果发现中断状态设置，则可以抛出InterruptedException。
清单6. 在返回之前恢复中断状态的非可执行任务
public Task getNextTask(BlockingQueue<Task> queue) { boolean interrupted = false; try { while (true) { try { return queue.take(); } catch (InterruptedException e) { interrupted = true; // 失败了再试 } } } finally { if (interrupted) Thread.currentThread().interrupt(); } }
摘要
你可以使用 Java 平台提供的协作中断机制来构建灵活的取消策略。作业可以决定它们是否可以取消，它们希望如何响应中断，如果立即返回会影响应用程序的完整性，它们可以推迟中断以执行特定于任务的清理。即使你想完全忽略代码中断，也要确保在捕获 InterruptedException 并且不重新抛出代码时恢复中断状态 ，以便调用它的代码能够发现中断。
