前言
如何中断一个线程，肯定不会使用 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 的使用，对于并发编程来说，还是非常重要的。
再次总结
本文说了哪些东西：
- Java 中同步和锁相关的 API 哪些可响应中断，哪些不可响应中断。总结下来就是 Lock 更灵活的对待中断。
- Thread 类的两个判断中断的方法，静态方法会清除中断状态，成员方法则不会。
- 线程池的 shutDownNow 方法会根据任务中是否有响应中断的 API 来决定是否立即中断任务，如果有，则立即中断，反之，等待任务完成。
- 线程池有趣的现象：Worker 初始化的时候，有一个变量设置成 -1 ，防止初始化的时候，用户调用 shutDown 和 shutDownNow 方法。
