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

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

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

• 用户请求取消

用户点击前端的“取消”按钮或接口调用发出取消请求（例如JMX）

• 有时间限制的操作

比如，某应用需要在有限时间内搜索问题空间，并在这个时间内选择最佳的解决方案。当计时器超时时，需要取消所有正在搜索的任务

• 应用程序事件

例如，应用程序对某个问题空间进行分解并搜索，从而使不同的任务可以搜索问题空间中的不同区域。当其中一一个任务找到了解决方案时，所有其他仍在搜索的任务都将被取消

• 错误

网页爬虫程序搜索相关的页面，并将页面或摘要数据保存到硬盘。当一个爬虫任务

发生错误时(例如，磁盘空间已满)，那么所有搜索任务都会取消，此时可能会记录它们的当前状态，以便稍后重新启动

image

• 关闭

当一个程序或服务关闭时，必须对正在处理和等待处理的工作执行某种操作。在平

缓的关闭过程中，当前正在执行的任务将继续执行直到完成，而在立即关闭过程中，当前的任务则可能取消。

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

其中一种协作机制能设置某个“已请求取消(Cancellation Requested)” 标志，而任务将定

期地查看该标志。如果设置了这个标志，那么任务将提前结束。

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

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

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

这种协作应用场景是很多的，我们其实很少会希望某个任务、线程或服务立即停止，因为这种立即停止会使共享的数据结构处于不一致状态。

在编写任务和服务时可以使用这样的协作：当需要停止时，首先会清除当前正在执行的工作，然后再结束。这提供了更好的灵活性，因为任务本身的代码比发出取消请求的代码更清楚如何执行清理工作。

生命周期结束(End-of-Lifecycle) 的问题会使任务、服务以及程序的设计和实现等过程变

得复杂，而这个在程序设计中非常重要的要素却经常被忽略。

行为良好的软件与勉强运行的软件之间的最主要区别就是，行为良好的软件能很完善地处理失败、关闭和取消等过程。

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

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

• 代码如下：

image.png

一个可取消的任务必须有取消策略(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 {
    }
}

两阶段终止模式

将终止过程分成两阶段：

• 一阶段，主要是线程T1向线程T2发送终止指令
• 二阶段，线程T2响应终止指令

Java里的终止指令是什么呢？还记得这篇Java线程的状态转换图

image

可见，Java线程进入Terminated的前提是线程进入RUNNABLE。而线程此时可能其它状态，比如休眠。要想终止这样的线程，首先要将其状态休眠=》RUNNABLE。

如何做到？就是靠着 Thread#interrupt()。

线程转到RUNNABLE后，如何再将其终止呢？RUNNABLE=》Terminated，优雅方案就是让Java线程自己执行完 run()。所以一般就是设置一个标志位，然后线程在合适时机检查该标志位，若发现符合终止条件，则自动退出run()。该过程就是第二阶段：响应终止指令。

综上，终止指令的关键就是：interrupt()，线程的终止标志位。

• 仅检查终止标志位不够，因为线程状态可能处于休眠
• 仅检查线程的中断状态也不够，因为依赖的第三方类库很可能没有正确处理中断异常

如何优雅终止线程池

线程池提供了两个方法：shutdown()和shutdownNow()：

• shutdown()是种保守的关闭线程池方法。线程池执行shutdown()后，就会拒绝接收新任务，但会等待线程池中正在执行的任务和已进入阻塞队列的任务，都执行完后才最终关闭线程池。
• shutdownNow()相对激进，线程池执行shutdownNow()后，会拒绝接收新任务，同时中断线程池中正在执行的任务，已进入阻塞队列的任务也会被剥夺了执行的机会，不过这些被剥夺执行机会的任务会作为shutdownNow()方法的返回值返回。因为shutdownNow()方法会中断正在执行的线程，所以提交到线程池的任务，如果需要优雅地结束，就需要正确地处理线程中断。

若提交到线程池的任务不允许取消，就不能使用shutdownNow()。但是，若提交到线程池的任务允许后续补偿重新执行，也是可以使用shutdownNow()的。

shutdown()和shutdownNow()方法你会发现，它们实质上使用的也是两阶段终止模式，只是终止指令的范围不同而已，前者只影响阻塞队列接收任务，后者范围扩大到线程池中所有的任务。