搞定学妹男神必备技术!这一篇包你精通Java线程的取消

Posted 2021-05-18 公众号-JavaEdge

为什么需要线程的取消机制？

开启一个线程很容易。绝大多数时间，我们都会让它们自己运行直到结束。
但有时，我们希望提前结束线程。

哪些情况会需要提前结束呢？

• 用户请求取消
  用户点击前端的“取消”按钮或接口调用发出取消请求（例如JMX）
• 有时间限制的操作
  比如，某应用需要在有限时间内搜索问题空间，并在这个时间内选择最佳的解决方案。当计时器超时时，需要取消所有正在搜索的任务
• 应用程序事件
  例如，应用程序对某个问题空间进行分解并搜索，从而使不同的任务可以搜索问题空间中的不同区域。当其中一一个任务找到了解决方案时，所有其他仍在搜索的任务都将被取消
• 错误
  网页爬虫程序搜索相关的页面，并将页面或摘要数据保存到硬盘。当一个爬虫任务
  发生错误时(例如，磁盘空间已满)，那么所有搜索任务都会取消，此时可能会记录它们的当前状态，以便稍后重新启动
• 关闭
  当一个程序或服务关闭时，必须对正在处理和等待处理的工作执行某种操作。在平
  缓的关闭过程中，当前正在执行的任务将继续执行直到完成，而在立即关闭过程中，当前的任务则可能取消。

在Java中没有一种安全的抢占式方法来停止线程，只有一些协作式的机制，使请求取消的任务和代码都遵循一种协商好的协议。

其中一种协作机制能设置某个“已请求取消(Cancellation Requested)” 标志，而任务将定
期地查看该标志。如果设置了这个标志，那么任务将提前结束。

要使任务和线程能安全、快速、可靠地停止下来，并非易事。Java 没有提供任何机制来安全地终止线程。

曾经的 Thread.stop 和 suspend 问题很大，禁止使用！

但Java提供了中断(Interruption)， 这是一种协作机制，能够使一个线程终止另一个线程的当前工作。

这种协作应用场景是很多的，我们其实很少会希望某个任务、线程或服务立即停止，因为这种立即停止会使共享的数据结构处于不一致状态。
在编写任务和服务时可以使用这样的协作：当需要停止时，首先会清除当前正在执行的工作，然后再结束。这提供了更好的灵活性，因为任务本身的代码比发出取消请求的代码更清楚如何执行清理工作。

生命周期结束(End-of-Lifecycle) 的问题会使任务、服务以及程序的设计和实现等过程变
得复杂，而这个在程序设计中非常重要的要素却经常被忽略。
行为良好的软件与勉强运行的软件之间的最主要区别就是，行为良好的软件能很完善地处理失败、关闭和取消等过程。

有哪些任务取消的方案呢？

其实一种就是“标记位”。例如使用volatile类型的域保存取消状态标识。

• 代码如下：
  

一个可取消的任务必须有取消策略(CancellationPolicy)，在这个策略中将详细定义：

• 其他代码如何(How)请求取消该任务
• 任务在何时(When)检查是否已经请求了取消
• 在响应取消请求时应该执行哪些(What) 操作

考虑现实世界中停止支付(Stop-Payment) 支票的示例。银行通常都会规定如何提交一个
停止支付的请求，在处理这些请求时需要做出哪些响应性保证，以及当支付中断后需要遵守哪些流程(例如通知该事务中涉及的其他银行，以及对付款人的账户进行费用评估)。这些流程和保证放在一起就构成了支票支付的取消策略。

PrimeGenerator使用了一种简单的取消策略：客户代码通过调用cancel来请求取消，
PrimeGenerator在每次搜索素数前首先检查是否存在取消请求，若存在则退出。

中断

下面的例子会出现死锁，线程根本不会停止

class BrokenPrimeProducer extends Thread {
    private final BlockingQueue<BigInteger> queue;
    private volatile boolean cancelled = false;

    BrokenPrimeProducer(BlockingQueue<BigInteger> queue) {
        this.queue = queue;
    }

    public void run() {
        try {
            BigInteger p = BigInteger.ONE;
            while (!cancelled)
                queue.put(p = p.nextProbablePrime());
        } catch (InterruptedException consumed) {
        }
    }

    public void cancel() {
        cancelled = true;
    }
}

• interrupt 方法：中断目标线程
• isInterrupted：返回目标线程的中断状态
• 静态的 interrupted方法：清除当前线程的中断状态，并返回它之前的值。

大多数可中断的阻塞方法会在入口处检查中断状态

对中断操作（调用interrupt）的正确理解

它并不会真正的中断一个正在运行的线程，而只是发出中断请求，然后由线程在下一个合适的时候中断自己。比如，wait、sleep、join等方法，当他们收到中断请求或开始执行时，发现某个已被设置好的中断状态，则抛出异常interruptedException。

每个线程都有一个boolean类型的中断状态。当调用Thread.interrupt方法时，该值被设置为true，Thread.interruptted可以恢复中断。

阻塞库方法，例如sleep和wait、join都会检查中断，并且发现中断则提前返回，他们会清楚中断状态，并抛出InterruptedException。

但是对于其他方法interrupt仅仅是传递了中断的请求消息，并不会使线程中断，需要由线程在下一个合适的时刻中断自己。

通常，用中断是取消的最合理的实现方式。

上面的例子的改进方法就是

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();
    }
}

中断策略

发生了中断，需要尽快退出执行流程，并把中断信息传递给调用者，从而使调用栈中的上层代码可以采取进一步的操作。当然任务也可以不需要放弃所有操作，可以推迟处理中断清楚，知道某个时机。

响应中断

• 传递异常
• 回复中断状态

public class NoncancelableTask {
    public Task getNextTask(BlockingQueue<Task> queue) {
        boolean interrupted = false;
        try {
            while (true) {
                try {
                    return queue.take();
                } catch (InterruptedException e) {
                    interrupted = true;
                    // fall through and retry
                }
            }
        } finally {
            if (interrupted)
                Thread.currentThread().interrupt();
        }
    }

    interface Task {
    }
}