Java中断异常的正确处理方法

处理InterruptedException

这个故事可能很熟悉：你正在写一个测试程序，你需要暂停某个线程一段时间，所以你调用 Thread.sleep()。然后编译器或 IDE 就会抱怨说 InterruptedException 没有抛出声明或捕获。什么是 InterruptedException，你为什么要处理它？

最常见的响应 InterruptedException 做法是吞下它 - 捕获它并且什么也不做（或者记录它，也没好多少） - 正如我们将在清单4中看到的那样。不幸的是，这种方法抛弃了关于​​中断发生的重要信息，这可能会损害应用程序取消活动或响应及时关闭的能力。

阻塞方法

当一个方法抛出 InterruptedException 时，意味着几件事情: 除了它可以抛出一个特定的检查异常, 它还告诉你它是一种阻塞方法，它会尝试解除阻塞并提前返回。

阻塞方法不同于仅需要很长时间才能运行完成的普通方法。普通方法的完成仅取决于你要求它做多少事以及是否有足够的计算资源（CPU周期和内存）。另一方面，阻塞方法的完成还取决于某些外部事件，例如计时器到期，I/O 完成或另一个线程的操作（释放锁，设置标志或放置任务到工作队列）。普通方法可以在完成工作后立即结束，但阻塞方法不太好预测，因为它们依赖于外部事件。

因为如果他们正在等待永远不会在事件，发生堵塞的方法有可能永远不结束，常用在阻塞可取消的操作。对于长时间运行的非阻塞方法，通常也是可以取消的。可取消操作是可以在通常自行完成之前从外部强制移动到完成状态的操作。 Thread提供的Thread.sleep() 和 Object.wait() 方法中断机制是一种取消线程继续阻塞的机制; 它允许一个线程请求另一个线程提前停止它正在做的事情。当一个方法抛出时 InterruptedException，它告诉你如果执行方法的线程被中断，它将尝试停止它正在做的事情提前返回, 并通过抛出 InterruptedException 表明它的提早返回。表现良好的阻塞库方法应该响应中断并抛出 InterruptedException 异常, 以便它们可以应用在可取消的活动中而不会妨碍程序的响应性。

线程中断

每个线程都有一个与之关联的布尔属性，表示其中断状态。中断状态最初为假; 当某个线程被其他线程通过调用中断 Thread.interrupt() 时， 会发生以下两种情况之一: 如果该线程正在执行低级别的中断阻塞方法 Thread.sleep()，Thread.join()或 Object.wait()等，它取消阻塞并抛出 InterruptedException。除此以外，interrupt() 仅设置线程的中断状态。在中断的线程中运行的代码可以稍后轮询中断的状态以查看是否已经请求停止它正在做的事情; 中断状态可以通过 Thread.isInterrupted() 读取，并且可以在命名不佳的单个操作Thread.interrupted()中读取和清除 。

中断是一种合作机制。当一个线程中断另一个线程时，被中断的线程不一定会立即停止它正在做的事情。相反，中断是一种礼貌地要求另一个线程在方便的时候停止它正在做什么的方式。有些方法，比如Thread.sleep()认真对待这个请求，但方法不一定要注意中断请求。不阻塞但仍可能需要很长时间才能执行完成的方法可以通过轮询中断状态来尊重中断请求，并在中断时提前返回。你可以自由地忽略中断请求，但这样做可能会影响响应速度。

中断的合作性质的一个好处是它为安全地构建可取消的活动提供了更大的灵活性。我们很少想立即停止活动; 如果活动在更新期间被取消，程序数据结构可能会处于不一致状态。中断允许可取消活动清理正在进行的任何工作，恢复不变量，通知其他活动取消事件，然后终止。

处理InterruptedException

如果 throw InterruptedException 意味着这个方法是一个阻塞方法，那么调用一个阻塞方法意味着你的方法也是一个阻塞方法，你应该有一个处理策略 InterruptedException。通常最简单的策略是你自己也抛出 InterruptedException 异常，如清单1 中的 putTask() 和 getTask() 方法所示。这样做会使你的方法响应中断，并且通常只需要添加 InterruptedException 到 throws 子句。

清单1.通过不捕获它来向调用者传播InterruptedException

public class TaskQueue {
 private static final int MAX_TASKS = 1000;
 
 private BlockingQueue<Task> queue 
  = new LinkedBlockingQueue<Task>(MAX_TASKS);
 
 public void putTask(Task r) throws InterruptedException { 
  queue.put(r);
 }
 
 public Task getTask() throws InterruptedException { 
  return queue.take();
 }
}

有时在传播异常之前需要进行一些清理。在这种情况下，你可以捕获 InterruptedException，执行清理，然后重新抛出异常。清单2是一种用于匹配在线游戏服务中的玩家的机制，说明了这种技术。该 matchPlayers() 方法等待两个玩家到达然后开始新游戏。如果在一个玩家到达之后但在第二个玩家到达之前它被中断，则在重新投掷之前将该玩家放回队列 InterruptedException，以便玩家的游戏请求不会丢失。

清单2.在重新抛出 InterruptedException 之前执行特定于任务的清理

public class PlayerMatcher {
 private PlayerSource players;
 
 public PlayerMatcher(PlayerSource players) { 
  this.players = players; 
 }
 
 public void matchPlayers() <strong>throws InterruptedException</strong> { 
  Player playerOne, playerTwo;
   try {
    while (true) {
     playerOne = playerTwo = null;
     // 等待两个玩家到来以便开始游戏
     playerOne = players.waitForPlayer(); // 会抛出中断异常
     playerTwo = players.waitForPlayer(); // 会抛出中断异常
     startNewGame(playerOne, playerTwo);
    }
   }
   catch (InterruptedException e) { 
    // 如一个玩家中断了, 将这个玩家放回队列
    if (playerOne != null)
     players.addFirst(playerOne);
    // 然后传播异常
    throw e;
   }
 }
}

不要吞下中断

有时抛出 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 并且不重新抛出代码时恢复中断状态 ，以便调用它的代码能够发现中断。

总结

以上就是这篇文章的全部内容了，希望本文的内容对大家的学习或者工作具有一定的参考学习价值，谢谢大家对脚本之家的支持。