nangongyanya 2020-03-02
CPU 在运行时为了响应外部的请求,对外提供了一个中断引脚。CPU 在每个指令周期的最后一个晶振周期检查中断引脚,如果有中断任务,则立即停止手中的工作(当然要先保存现场)调用相应中断号的中断处理程序对中断做出响应。
进程在运行时为了响应外部请求,对外提供了信号队列。在每次由核心态转为用户态(比如由进程调度方法转到用户进程)时,会先检查自己的信号队列是否存在外部发来的信号,如果有则调用对应信号的信号处理程序对信号做出响应(Linux 下由 OS 在调度某进程前检查其信号队列,如果存在需要处理的信号则开启一个新线程调用信号处理程序)。
程序在运行过程中总是需要对外部发来的信号做出响应。因为这些信号是脱离于既定的运行逻辑之外的,我们不知道什么时候会发生这些事件,所以我们只能在现有调度方式的基础上,周期性的检查是否有信号到达。对中断信号的检查是基于处理器对指令的调度方式,每条指令的逻辑执行完成时去检查是否中断信号发生;对进程信号的检查是基于 OS 对进程的调度方式,每次调度该进程前检查是否有信号发生。
JVM 在线程层面为我们提供了类似的方法,线程的 interrupt 信号。
但是对于 interrupt 信号的处理与上面两位有很大的不同,线程的调度是基于 OS 的,JVM 除调用 OS 的系统函数外很难在其调度机制上做文章。
比如我们无法干预 OS 在调度线程运行前应该先去做点什么。
另外无论是中断处理程序还是信号处理程序,都是既定任务外的事件,对线程来讲,这些异步任务的处理是在其它线程中进行的,仅仅是延缓了本线程的调度,并没有改变本线程的任务。或者从底层说,没有改变本线程的堆栈/PC等现场。
这样我们就无法干预本线程的运行,比如将其从死锁中解放出来/终止当前方法的调用回滚堆栈。
interrupt 却在一定程度上做到了这一点。JVM 无法干预 OS 对线程的调度,但 JVM 可以从自身调度线程的层面上,在自己提供的基于 OS 线程调度的那些方法上做文章。
比如 sleep/wait/join 均是基于 OS 阻塞线程的方法对线程进行了阻塞,那么以 sleep 为例,我们可以这样写,伪代码:
public void sleep(Long sleepTime){ if(sleepTime<=0){ throw new RunTimeException("xxx"); } //OS阻塞线程的方法 os_park(sleepTime); if(interrupt==true){ throw new InterruptedException("xxx"); } }
在上述标红的地方调用 OS 阻塞线程的方法,线程运行到这一句是会阻塞住。
那么我们发送 interrupt 信号时线程会继续在 sleep 方法内向下执行,去检查 interrupt 信号,如果信号存在,抛出异常。这样便在本线程内,做出了对信号的响应。
事实上 JVM 也是这样做的,hotspot源码\src\share\vm\prims\jvm.cpp:
接着看其内部的sleep:
基于 ParkEvent 的 unpark 和 park 阻塞和唤醒对象,但在阻塞对象之后和唤醒对象之前,JVM 提供的方法是可以做点什么的。
本质上,硬件/OS/JVM 对信号的响应是相通的,都是基于自身提供的调度程序运行的机制,在调度的间隙对信号进行检查和处理。JVM 对信号的检查和处理逻辑因为封装在调用线程调用的方法内部,所以可以在调用线程中处理这些信号,也就可以对调用线程做更多的事情,比如 interrupt() 方法发生在因 sleep/wait/join 方法而阻塞的线程上时,由 sleep/wait/join 方法在其调用线程中抛出异常。