java - 为什么要同时使用 boolean 值和 interrupt() 来指示线程终止？

Question

我在 https://docs.oracle.com/javase/7/docs/technotes/guides/concurrency/threadPrimitiveDeprecation.html 中阅读有关结束线程的方法的信息，这是我从问题 How do you kill a thread in Java? 中找到的链接

在第一个链接中，他们首先讨论了使用 volatile 变量来向线程发出您想终止的信号。如果变量的值意味着停止(例如，如果它是 null)，线程应该检查这个变量并停止操作。因此，要终止线程，您可以将该变量设置为 null。

然后他们讨论添加中断以帮助处理长时间阻塞的线程。他们给出了以下 stop() 方法示例，该方法将 volatile 变量(等待程序)设置为 null，然后还抛出一个中断。

public void stop() {
    Thread moribund = waiter;
    waiter = null;
    moribund.interrupt();
}

我只是想知道，为什么你需要两者？为什么不只使用 interrupt()，然后妥善处理它呢？这对我来说似乎是多余的。

Answer 1

(第一部分是一般性的，可以说我没有注意问题的细节。跳到最后部分解决问题中讨论的技术规范。)

没有很好的技术原因。这部分与人为限制有关，部分与混淆 api 设计有关。

首先考虑应用程序开发人员的首要任务是创建解决业务问题的工作代码。像这样彻底学习低级 API 会在急于完成工作时迷失方向。

其次，当你学习的东西达到足够好的状态并保持在那里时，会有一种趋势。诸如线程和异常处理之类的东西是被忽视的书本主题。中断是线程书籍的书后主题。

现在想象一个代码库由多个不同技能水平和对细节的关注的人共同工作，他们可能忘记从 wait 和 sleep 中抛出 InterruptedException 会重置中断标志，或者 interrupted 与 isInterrupted 不同，或者 InterruptedIoException也重置中断标志。如果您有一个捕获 IOException 的 finally block ，您可能会错过 InterruptedException 是 IOException 的子类，并且您可能会错过恢复中断标志的机会。可能匆忙的人决定去死吧，我不能指望这个中断的标志

是吗？没有。

• 手摇标志无法像中断那样帮助短路等待或 hibernate 。

• Java 5 并发工具期望任务使用中断来取消。执行者希望提交给他们的任务检查中断以便优雅地退出。您的任务可能会使用其他组件，例如阻塞队列。该队列需要能够响应中断，使用它的东西需要知道中断。 handrolled 标志对此不起作用，因为 java 5 类不知道它。

必须使用中断，因为您使用的是预期它的工具，但由于难以管理的技术问题而对标志值没有信心，将导致这种代码。

(咆哮结束，现在实际回应具体的技术规范示例)

好的，请特别查看这篇技术指南文章。三件事很突出:

1) 除了缩短 sleep 时间外，它根本没有利用中断。然后它只是抑制异常，并且不会费心恢复标志或检查它。您可以使用 InterruptedException 通过在 while 循环外捕获它来终止，但这不是它的作用。这似乎是一种奇怪的方法。

2) 随着示例的充实，可以清楚地看到该标志用于打开和关闭等待。有人可能会为此使用中断，但这不是惯用的。所以在这里有一面旗帜是可以的。

3) 这是技术指南中的玩具示例。并非所有 Oracle 内容都像技术规范或 API 文档那样权威。一些教程有错误陈述或不完整。写成这样的代码可能是作者认为读者不熟悉中断是如何工作的，最好尽量减少它的使用。众所周知，技术作家会做出这样的选择。

如果我重写它以使用中断，我仍然会保留标志；我会使用中断来终止，并使用标志来暂停/恢复功能。