- 前言
- Parker 源码调试与分析
- park/unpark 原理总结
- 补充:jstack 命令和 kill 命令
前言
熟悉 Java 并发包的人一定对 LockSupport 的 park/unpark
方法不会感到陌生,它是 Lock(AQS)的基石,给 Lock(AQS)提供了挂起/恢复当前线程的能力。
LockSupport 的 park/unpark
方法本质上是对 Unsafe 的 park/unpark
方法的简单封装,而后者是 native 方法,对 Java 程序来说是一个黑箱操作,那么要想了解它的底层实现,就必须深入 Java 虚拟机的源码。
本篇将介绍 park/unpark
方法在 Hotsport 虚拟机中的具体实现。
Parker 源码调试与分析
在 Hotspot 源码中,unsafe.cpp 文件专门用于为 Java Unsafe 类中的各种 native 方法提供具体实现。
其中 park
方法的实现代码如下:
unpark
方法的实现代码如下:
两者的核心操作都是通过委托当前线程所关联的 Parker 对象来完成的(每个线程都会关联一个自己的 Parker 对象),于是,Parker 对象的 park/unpark
方法就成为了我们的焦点。
下面我将联合 Java 程序与 Hotspot 源码一起调试,观察 Parker 对象的 park/unpark
方法的内部操作。
其中 Java 程序的代码如下:
public static void main(String[] args) {
Thread t1 = new Thread(() -> {
System.out.println("park开始");
LockSupport.park();
System.out.println("park结束");
}, "t1");
Thread t2 = new Thread(() -> {
System.out.println("unpark开始");
LockSupport.unpark(t1);
System.out.println("unpark结束");
}, "t2");
Scanner scanner = new Scanner(System.in);
String input;
System.out.println("输入“1”启动t1线程,输入“2”启动t2线程,输入“quit”退出");
while (!(input = scanner.nextLine()).equals("quit")) {
if (input.equals("1")) {
if (t1.getState().equals(Thread.State.NEW)) {
t1.start();
}
} else if (input.equals("2")) {
if (t2.getState().equals(Thread.State.NEW)) {
t2.start();
}
}
}
}
我们采用远程调试的方式运行上面的 Java 程序,然后通过在控制台输入“1” 来启动 t1 线程。当 t1 线程启动后,LockSupport.park
方法就会得以执行。
如图所示,当前 t1 线程停在了断点处,即停在了 Parker::park
方法的第一条语句上。
我们来分析一下该方法主要做的事情。
它首先利用一个原子交换操作将计数器的值改为 0,同时检查计数器的原值是否大于 0,如果大于 0,表示当前 Parker 对象的 unpark 方法先于 park 方法执行了(因为 unpark 方法会把计数器的值改为 1),那么本次 park 方法将直接返回,表示取消本次操作。如果计数器的原值不大于 0,则继续往下执行。
接着判断当前线程是否被标记了中断,如果是的话就直接返回,否则就通过 pthread_mutex_trylock
函数尝试加 mutex 锁,如果加锁失败也直接返回。(pthread_mutex_trylock
函数是一个系统调用,它会针对操作系统的一个互斥量进行加锁,加锁成功将返回 0)。
在我们的调试中,以上所有条件判断都不命中,于是线程顺利地执行到了下图所示的位置。
图中断点处的代码相当关键,它完成了对 pthread_cond_wait
函数的调用,该函数是 Linux 标准线程库(libpthread.so)中的一个系统调用,它会使当前线程加入操作系统的条件等待队列,同时释放 mutex 锁并使当前线程挂起。
Java 中的
wait
和await
方法提供了和pthread_cond_wait
函数同样的功能,前者本质上是对后者的封装。如果对pthread_cond_wait
函数的具体实现感兴趣,可以参考: https://code.woboq.org/userspace/glibc/nptl/pthread_cond_wait.c.html
由于 pthread_cond_wait
函数会使当前线程挂起,所以在我点击 “Step Over” 之后,线程阻塞在了 pthread_cond_wait
函数上,并等待被唤醒。
下图显示了通过 jstack 命令打印的线程堆栈信息,可以看到 t1 线程已经处于 waiting (parking) 状态。
至此,park 操作暂时告一段落。
接下来,我们通过在控制台输入“2” 来启动 t2 线程。当 t2 线程启动后,LockSupport.unpark(t1)
就会得以执行。
如图所示,当前 t2 线程停在了断点处,即停在了 Parker::unpark
方法的第二行代码上。
该方法做的事情相对简单,它先是给当前线程加锁,然后将计数器的值改为 1,接着判断 Parker 对象所关联的线程是否被 park,如果是,则通过 pthread_mutex_signal
函数唤醒该线程,最后释放锁。
pthread_mutex_signal
函数通常与 pthread_cond_wait
函数配套使用,其作用是唤醒操作系统中在某个条件变量上等待着的线程。
当 unpark 操作完成后,之前被 park 的线程将恢复至运行状态(需要先拿到 mutex 锁),然后从 pthread_cond_wait
方法中返回,接着执行剩余代码。下图显示了Parker::park
方法的剩余代码。
可以看到,当线程恢复运行后,计数器的值会再次被置为 0,然后线程会释放锁,并结束整个 park 操作。
park/unpark 原理总结
每个线程都会关联一个 Parker 对象,每个 Parker 对象都各自维护了三个角色:计数器、互斥量、条件变量。
park 操作:
-
获取当前线程关联的 Parker 对象。
-
将计数器置为 0,同时检查计数器的原值是否为 1,如果是则放弃后续操作。
-
在互斥量上加锁。
-
在条件变量上阻塞,同时释放锁并等待被其他线程唤醒,当被唤醒后,将重新获取锁。
-
当线程恢复至运行状态后,将计数器的值再次置为 0。
-
释放锁。
unpark 操作:
-
获取目标线程关联的 Parker 对象(注意目标线程不是当前线程)。
-
在互斥量上加锁。
-
将计数器置为 1。
-
唤醒在条件变量上等待着的线程。
-
释放锁。
补充:jstack 命令和 kill 命令
jstack 命令会给 Java 虚拟机进程发送一个 SIGQUIT 信号,当 Java 虚拟机收到信号后,会另起一个线程专门执行打印线程堆栈的任务。如图,从 GDB
标签页中可以观察到 SIGQUIT 信号。
在 Linux 中使用 kill -3 命令也可以实现和 jstack 命令几乎一样的效果,这是因为 kill 命令本身就是一个用于给进程发送信号的工具,只不过默认发送的是 SIGTERM 信号(终止信号),该信号用于终止一个进程。可以通过 kill -l 命令查看所有可用信号,kill -3 表示发送 SIGQUIT 信号。