Java并发编程实战之 取消与关闭、线程池的使用

第六章 取消与关闭

6.1 任务取消

协作机制能设置某个标志位，任务会定期查看这个标志，如果设置了标志，那么任务将提前结束。

如果外部代码能在某个操作正常完成之前将其置入“完成”状态，那么这个操作就可以称为可取消的。

如何取消一般有两种方法：

1. 使用状态变量。线程中循环遍历状态变量，检测是否需要结束当前线程。
2. 使用中断。系统提供的大多数阻塞方法会相应中断Thread.interrupt：清除中断状态Thread.isinterrupted；抛出InterruptedException异常；表示阻塞操作由于中断而提前结束。

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

6.2 Java 中断机制

当我们点击某个杀毒软件的取消按钮来停止查杀病毒时，当我们在控制台敲入quit命令以结束某个后台服务时……都需要通过一个线程去取消另一个线程正在执行的任务。

Java没有提供一种安全直接的方法来停止某个线程，但是Java提供了中断机制。

• 中断机制是如何工作的？
• 捕获或检测到中断后，是抛出InterruptedException还是重设中断状态以及在方法中吞掉中断状态会有什么后果？
• Thread.stop与中断相比又有哪些异同？什么情况下需要使用中断？

6.2.1 中断的原理

Java中断机制是一种协作机制，也就是说通过中断并不能直接终止另一个线程，而需要被中断的线程自己处理中断。

Java中断模型也是这么简单，每个线程对象里都有一个boolean类型的标识，代表着是否有中断请求（该请求可以来自所有线程，包括被中断的线程本身）。

java.lang.Thread类提供了几个方法来操作这个中断状态，这些方法包括：

• public static boolean interrupted

  清除当前线程的中断状态，并返回它之前的值，这也是清除中断状态的唯一方法

• public boolean isInterrupted()
  返回目标线程的中断状态。线程的中断状态不受该方法的影响。

• public void interrupt()
  中断线程。

调用 interrupt 并不意味着立即停止目标线程正在进行的工作，而只是传递了请求中断的消息。

此外，类库中的有些类的方法也可能会调用中断，如FutureTask中的cancel方法，如果传入的参数为true，它将会在正在运行异步任务的线程上调用interrupt方法，如果正在执行的异步任务中的代码没有对中断做出响应，那么cancel方法中的参数将不会起到什么效果。

又如ThreadPoolExecutor中的shutdownNow方法会遍历线程池中的工作线程并调用线程的interrupt方法来中断线程，所以如果工作线程中正在执行的任务没有对中断做出响应，任务将一直执行直到正常结束。

6.2.2 中断的处理

既然Java中断机制只是设置被中断线程的中断状态，那么被中断线程该做些什么？

处理时机

显然，作为一种协作机制，不会强求被中断线程一定要在某个点进行处理。实际上，被中断线程只需在合适的时候处理即可，如果没有合适的时间点，甚至可以不处理。“合适的时候”与线程正在处理的业务逻辑紧密相关，例如，每次迭代的时候，进入一个可能阻塞且无法中断的方法之前等，但多半不会出现在某个临界区更新另一个对象状态的时候，因为这可能会导致对象处于不一致状态。

频繁的检查中断状态可能会使程序执行效率下降，而检查的较少可能使中断请求得不到及时响应。如果发出中断请求之后，被中断的线程继续执行一段时间不会给系统带来灾难，那么就可以将中断处理放到方便检查中断，同时又能从一定程度上保证响应灵敏度的地方。当程序的性能指标比较关键时，可能需要建立一个测试模型来分析最佳的中断检测点，以平衡性能和响应灵敏性。

处理方式

1、 中断状态的管理

一般说来，当可能阻塞的方法声明中有抛出InterruptedException则暗示该方法是可中断的，如BlockingQueue#put、BlockingQueue#take、Object#wait、Thread#sleep等，如果程序捕获到这些可中断的阻塞方法抛出的InterruptedException或检测到中断后，这些中断信息该如何处理？一般有以下两个通用原则：

• 如果遇到的是可中断的阻塞方法抛出InterruptedException，可以继续向方法调用栈的上层抛出该异常，如果是检测到中断，则可清除中断状态并抛出InterruptedException，使当前方法也成为一个可中断的方法。
• 若有时候不太方便在方法上抛出InterruptedException，比如要实现的某个接口中的方法签名上没有throws InterruptedException，这时就可以捕获可中断方法的InterruptedException并通过Thread.currentThread.interrupt() 来重新设置中断状态。如果是检测并清除了中断状态，亦是如此。

一般的代码中，尤其是作为一个基础类库时，绝不应当吞掉中断，即捕获到InterruptedException后在catch里什么也不做，清除中断状态后又不重设中断状态也不抛出InterruptedException等。因为吞掉中断状态会导致方法调用栈的上层得不到这些信息。

总得来说，就是要让方法调用栈的上层获知中断的发生。假设你写了一个类库，类库里有个方法amethod，在amethod中检测并清除了中断状态，而没有抛出InterruptedException，作为amethod的用户来说，他并不知道里面的细节，如果用户在调用amethod后也要使用中断来做些事情，那么在调用amethod之后他将永远也检测不到中断了，因为中断信息已经被amethod清除掉了。如果作为用户，遇到这样有问题的类库，又不能修改代码，那该怎么处理？只好在自己的类里设置一个自己的中断状态，在调用interrupt方法的时候，同时设置该状态，这实在是无路可走时才使用的方法。

2、 中断的响应

程序里发现中断后该怎么响应？这就得视实际情况而定了。有些程序可能一检测到中断就立马将线程终止，有些可能是退出当前执行的任务，继续执行下一个任务……作为一种协作机制，这要与中断方协商好，当调用interrupt会发生些什么都是事先知道的，如做一些事务回滚操作，一些清理工作，一些补偿操作等。

不可取消的任务在退出前恢复中断

public Task getNextTask(BlockingQueue<Task> queue) {
   
    boolean interruptted = false;
    try {
   
        while (true) {
   
            try {
   
                return queue.take();
            } catch (InterrupttedException e) {
   
                interruptted = true;
            }
        }
    } finally {