并发编程 —— 谈谈线程中断

前言

如何中断一个线程，肯定不会使用 stop。而是使用 interrupt 方法。同时，我们知道，中断一个线程只是打个标志位。不会真的中断线程，但，如果线程是阻塞状态的呢？

而 Java 中，想要阻塞一个线程有很多种方式。

synchronized
Object.wait()
Lock
Condition.await()
LockSupport.park()
Thread.join（）

当然上面都是很简单的说说，API 并不是那么的详细。像 Lock 的 api 就有响应中断的。
还有 Thread.sleep()。这个大家都知道，肯定是响应中断的。

下面就来解决我们的问题。

解开迷雾

仔细分析一下，中断其实有 2 种状态，运行时中断，阻塞时中断。

顾名思义，运行时中断指的是线程运行时，我们中断他，当然，这个对线程毫无影响，只能通过标志位来判断。

而阻塞时中断就分为 2 种。一种是在等待锁的时候中断，一种是进入锁的时候，wait 的时候中断。

例如一个 synchronized 同步块，当多线程访问同步块时，同步块外的就是等待锁的状态。进入锁了，执行 wait 方法，也是阻塞的状态。

虽然都是阻塞的状态，但这两种阻塞状态是不同的。

基于前言中的阻塞方式，我们一个个来分析。

总结一下

非 Lock 接口，即 synchronized 和 Object 还有 Thread 的相关方法，除了 synchronized 不会响应中断，其他的都会响应中断并抛出异常。

Lock 接口，无论是使用 lock 系列方法，还是 Condition 的 await 系列方法，都可随心所欲，想使用什么模式，就使用什么模式。在日常的开发，这个特性还是非常有用的。

相比而言，Lock 相关的接口更加的灵活，对于线程中断的响应和处理可自行设置，而非 Lock 接口则需要了解他们的中断特性.

例如 sleep 方法和 wait 方法则会清除中断状态。

Lock 系列方法抛出异常后，也是会清除中断状态的。

Lock 清除中断状态的手段则是 Thread.interrupted 方法。

为什么要清除中断状态呢？如果下次有线程再次中断，此时便可以判断。

有点需要注意，Thread.interrupted 静态方法和 Thraed#isInterrupted() 成员方法的区别

他们都是调用的 Thread 类的 private native boolean isInterrupted(boolean ClearInterrupted) 方法。

这个方法有个布尔参数，true 是清除中断状态，false 则不清除。使用的时候需要注意。

拾遗

线程池的 shutDown 和 shutDownNow 方法是通过设置线程的中断来停止线程的。

shutDown 必须等待任务执行完毕，才会执行线程池线程的 interrupt 方法。
shutDownNow 则不会，直接执行 interrupt 方法。

所以，当你执行一个 shutDown 方法的时候，必须等待任务执行完毕才能设置中断状态。你代码中设置的那些响应中断方法是起不到作用的。真正起作用的，是线程池内部设置的状态变量。设置中断的目的则是打断阻塞在队列上的线程。

当你执行 shutDownNow 方法的时候，线程池会执行所有活动线程的 interrupt 方法，如果你的任务中恰好有以上的那些响应中断的方法。那么，就可以立即中断线程。如果没有，老实等待任务执行结束。

有趣的事情

线程池的 Worker 初始化的时候，会将 AQS 的 state 变量设置为 -1 ，防止用户执行 shutDown 方法试图停止线程。当将要执行真正的任务的时候，会将这个 AQS 变量设置为 0，这个时候，用户执行 shutDwon 方法才有效。那么 shutDownNow 方法呢？同样的，也判断了 state 变量必须大于等于 0 才能执行 interrupt 方法。保证线程池整体的状态安全。

其实，这篇文章还是有点杂乱，东西有点多。但总体还是围绕线程中断来讲的。

熟悉这些 API 的使用，对于并发编程来说，还是非常重要的。