java - 一个方法什么时候应该抛出 InterruptedException，我应该如何处理一个呢？ (阻塞方法)

Question

如果方法必须是 阻塞 方法，我是否认为如果我离开
出 throws InterruptedException ，我有没有搞错？

简而言之:

阻塞方法应包括 throws InterruptedException否则是正常方法。

阻塞方法可能会影响响应能力，因为很难预测它何时完成，这就是它需要的原因 throws InterruptedException .

那是正确的吗？

Answer 1

不，我认为你的总结不正确。通常，如果您正在编写一个方法来调用其他抛出 InterruptedException 的方法。 ，那么你的方法也应该宣传 throw InterruptedException ——除非你有一个很好的计划，当你所依赖的方法发出中断信号时该怎么做。

您能够吸收这种中断的情况很少见。也许您正在计算一个迭代解决方案，其中精度随着时间的推移而增加，但是，当您的调用线程被中断时，您决定在分配的时间内达到的解决方案足够好，并且仍然足够正确以返回。换句话说，该解决方案仍在您的方法范围内。

想象:

private double improveUpon(double start) throws InterruptedException {
  // ...
}


public double compute() {
  double result = 0.0;
  try {
    do {
      result = improveUpon(result);
    } while (couldBeImproved(result));
  } catch (InterruptedException ex) {
    Thread.currentThread().interrupt();
  }
  return result;
}

或者，如果您只是想尊重中断请求，则无需 InterruptedException 也可以这样做。参与:

private double improveUpon(double start) {
  // ...
}


public double compute() {
  final Thread current = Thread.currentThread();
  double result = 0.0;
  do {
    result = improveUpon(result);
  } while (couldBeImproved(result) &&
           !current.isInterrupted());
  return result;
}

对于另一种变体，请考虑这样一种情况:您的方法必须完成其所有工作，或者向调用者指示它无法完成它，并且需要一段时间才能完成，但您希望尊重线程中断。像这样的东西就足够了:

private double improveUpon(double start) {
  // ...
}


public double compute() throws InterruptedException {
  final Thread current = Thread.currentThread();
  double result = 0.0;
  do {
    if (current.interrupted())
      throw new InterruptedException();
    result = improveUpon(result);
  } while (!isAdequate(result));
  return result;
}

请注意，我们调用了 Thread#interrupted() ，如果已设置，则具有清除线程的中断状态的副作用。如果该方法返回 true，我们作为调用者已经接受了保持和传达该中断状态的责任。在这种情况下，由于我们不假设我们创建了调用线程，并且我们在这里没有足够的可见范围来了解其中断策略是什么，因此我们通过抛出 InterruptedException 来传达我们观察到和采用的中断状态。 .

将方法标记为“阻塞”总是一个程度的问题；每个方法都会在一段时间内阻止其调用者。您可能正在寻找的区别在于该方法是否阻止等待某些外部输入，例如用户按下某个键或通过网络到达的消息。在这些情况下，您抛出的广告 InterruptedException向您的调用者表明您的方法对于来自必须控制延迟的线程的调用者来说是安全的。你是说，“这可能需要一段时间才能完成，但不会超过你愿意等待的时间。”你是说，“我会一直跑，直到你告诉我不要跑为止。”这不同于，比如说， java.io.InputStream#read() ，它威胁要阻塞，直到三个条件之一发生，其中没有一个是调用者的线程被中断。

在大多数情况下，您的决定归结为回答以下问题:

为了满足我的方法的要求，我是否需要调用任何抛出 InterruptedException 的方法？ ?

如果是这样，我到目前为止所做的工作对我的来电者有任何用处吗？

如果没有，我也应该扔InterruptedException .

如果没有我称之为抛出 InterruptedException ，我应该尊重我的调用线程的中断状态吗？

如果是这样，在我检测到我被打断对我的来电者有任何用处之前，我是否做过任何工作？

如果没有，我应该扔InterruptedException .

人们会检测到当前线程的中断并吞下它的情况通常仅限于您(作者)创建了有问题的线程，并且您已 promise 退出线程的 run() 的情况。线程中断后的方法。这就是“合作取消”的概念，您观察线程停止运行的请求，然后决定通过尽快完成工作并让线程的调用堆栈展开来遵守该请求。尽管如此，除非您是该线程 run() 的作者方法，您吞下线程的中断状态可能会损害调用者和他们调用的其他方法的预期行为。

建议你研究一下线程的中断状态，熟悉方法 Thread#isInterrupted() , Thread#interrupted() , 和 Thread#interrupt() .一旦你理解了这些，就会看到 InterruptedException飞行中是 Thread#isInterrupted() 的另一种表示返回 true，或者 Thread#interrupted() 的礼貌翻译返回 true 后，这一切都应该开始变得更有意义。

如果你需要更多的例子来学习，请说出来，我可以在这里添加建议。