并发编程-——-谈谈线程中断
如何中断一个线程,肯定不会使用 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 方法。