从JDK源码角度看java并发线程的中断

时间:2021-11-22 09:19:25

线程的定义给我们提供了并发执行多个任务的方式,大多数情况下我们会让每个任务都自行执行结束,这样能保证事务的一致性,但是有时我们希望在任务执行中取消任务,使线程停止。在java中要让线程安全、快速、可靠地停下来并不是一件容易的事,java也没有提供任何可靠的方法终止线程的执行。

线程调度策略中有抢占式和协作式两个概念,与之类似的是中断机制也有协作式和抢占式。

历史上Java曾经使用stop()方法终止线程的运行,他们属于抢占式中断。但它引来了很多问题,早已被JDK弃用。调用stop()方法则意味着

①将释放该线程所持的所有锁,而且锁的释放不可控。

②即刻将抛出ThreadDeath异常,不管程序运行到哪里,但它不总是有效,如果存在被终止线程的锁竞争;

第一点将导致数据一致性问题,这个很好理解,一般数据加锁就是为了保护数据的一致性,而线程停止伴随所持锁的释放,很可能导致被保护的数据呈现不一致性,最终导致程序运算出现错误。第二点比较模糊,它要说明的问题就是可能存在某种情况stop()方法不能及时终止线程,甚至可能终止不了线程。看如下代码会发生什么情况,看起来线程mt因为执行了stop()方法将停止,按理来说就算execut方法是一个死循环,只要执行了stop()方法线程将结束,无限循环也将结束。其实不会,因为我们在execute方法使用了synchronized修饰,同步方法表示在执行execute时将对mt对象进行加锁,另外,Thread的stop()方法也是同步的,于是在调用mt线程的stop()方法前必须获取mt对象锁,但mt对象锁被execute方法占用,且不释放,于是stop()方法永远获取不了mt对象锁,最后得到一个结论,使用stop()方法停止线程不可靠,它未必总能有效终止线程。

public class ThreadStop {
public static voidmain(String[] args) {
           Thread mt= new MyThread();
           mt.start();
           try {
                    Thread.currentThread().sleep(100);
           } catch(InterruptedException e) {
                    e.printStackTrace();
           }
           mt.stop();
}

static classMyThread extends Thread {
           publicvoid run() {
                    execute();
           }
           privatesynchronized void execute() {
                    while(true) {
                    }
           }
}
}

经历了很长时间的发展,Java最终选择用一种协作式的中断机制实现中断。协作式中断的原理很简单,其核心是先对中断标识进行标记,某线程设置某线程的中断标识位,被标记了中断位的线程在适当的时间节点会抛出异常,捕获异常后做相应的处理。实现协作中断有三个要点需要考虑:①是在Java层面实现轮询中断标识还是在JVM中实现;②轮询的颗粒度的控制,一般颗粒度要尽量小周期尽量短以保证响应的及时性;③轮询的时间节点的选择,其实就是在哪些方法里面轮询,例如JVM将Thread类的wait()、sleep()、join()等方法都实现中断标识的轮询操作。

中断标识放在哪里?中断是针对线程实例而言,从Java层面上看,标识变量放到线程中肯定再合适不过了,但由于由JVM维护,所以中断标识具体由本地方法维护。在Java层面仅仅留下几个API用于操作中断标识,如下,

public class Thread{
    public voidinterrupt() {……}
    public BooleanisInterrupted() {……}
    public static Booleaninterrupted() {……}
}

上面三个方法依次用于设置线程为中断状态、判断线程状态是否中断、清除当前线程中断状态并返回它之前的值。通过interrupt()方法设置中断标识,假如在非阻塞线程则仅仅只是改变了中断状态,线程将继续往下运行,但假如在可取消阻塞线程中,如正在执行sleep()、wait()、join()等方法的线程则会因为被设置了中断状态而抛出InterruptedException异常,程序对此异常捕获处理。

上面提到的三个要点,第一是轮询在哪个层面实现,这个没有特别的要求,在实际中只要不出现逻辑问题,在Java层面或JVM层面实现都是可以的,例如常用的线程睡眠、等待等操作是通过JVM实现,而java并发框架工具里面的中断则放到Java实现,不管在哪个层面上去实现,在轮询过程中都一定要能保证不会产生阻塞。第二是要保证轮询的颗粒度尽可能的小周期尽可能短,这关系到中断响应的速度。第三点是关于轮询的时间节点的选取。

针对三要点来看看java并发框架中是如何支持中断的,主要在等待获取锁的过程中提供中断操作,下面是伪代码。只需增加加红加粗部分逻辑即可实现中断支持,在循环体中每次循环都对当前线程中断标识位进行判断,一旦检查到线程被标记为中断则抛出InterruptedException异常,高层代码对此异常捕获处理即完成中断处理。总结起来就是java并发工具获取锁的中断机制是在Java层面实现的,轮询时间节点选择在不断做尝试获取锁操作过程中,每个循环的颗粒度比较小,响应速度得以保证,且循环过程不存在阻塞风险,保证中断检测不会失效。

if(尝试获取锁失败) {
    创建node
    使用CAS方式把node插入到队列尾部
    while(true){
    if(尝试获取锁成功并且 node的前驱节点为头节点){
把当前节点设置为头节点
    跳出循环
}else{
    使用CAS方式修改node前驱节点的waitStatus标识为signal
    if(修改成功){
        挂起当前线程
        if(当前线程中断位标识为true)
           抛出InterruptedException异常
}
}
}

判断线程是否处于中断状态其实很简单,只需使用Thread.interrupted()操作,如果为true则说明线程处于中断位,并清除中断位。至此java并发工具实现了支持中断的获取锁操作。

本文从java发展过程分析了抢占式中断及协作式中断,由于抢占式存在一些缺陷现在已不推荐使用,而协作式中断作为推荐做法,尽管在响应时间较长,但其具有无可比拟的优势。协作式中断我们可以在JVM层面实现,同样也可以在Java层面实现,例如JDK并发工具的中断即是在Java层面实现,不过如果继续深究是因为Java留了几个API供我们操作线程的中断标识位,这才使Java层面实现中断操作得以实现。            对于java的协作式中断机制有人肯定有人批评,批评者说java没有抢占式中断机制,且协作式中断机制迫使开发者必须维护中断状态,迫使开发者必须处理InterruptedException。但肯定者则认为,虽然协作式中断机制推迟了中断请求的处理,但它为开发人员提供更灵活的中断处理策略,响应性可能不及抢占式,但程序健壮性更强。

喜欢研究java的同学可以交个朋友:

从JDK源码角度看java并发线程的中断