使用JDK自带的工具jstack找出造成运行程序死锁的原因

Java多线程编程也是Java面试中经常考察的内容。刚接触Java多线程编程的朋友们，可能会不慎写出一些会导致死锁(deadlock)的应用出来。如何分析造成Java多线程的原因呢？很多时候我们在怀疑造成死锁的语句设置断点，单步调试，反而又不能重现了。这种现象很正常，因为咱们单步调试和直接运行程序，代码执行的时序是不同的，很可能无法满足死锁的触发条件。

实际上，JDK已经给Java程序员提供了强大的死锁分析工具，能够直接分析一个正在运行的并且处于死锁状态的应用，并给出具体是哪一行Java代码引起的死锁。

这篇文章就以一个例子来给大家演示如何使用这个JDK提供的标准工具。

这个工具叫jstack，就是JDK安装目录的bin文件夹下的一个执行文件。

我们首先写一个会导致死锁的应用出来。

public class DeadLockExample {
	public static void main(String[] args) {
		final String resource1 = "ABAP";
		final String resource2 = "Java";
		Thread t1 = new Thread() {
			public void run() {
				synchronized (resource1) {
					System.out.println("Thread 1: locked resource 1");
					try {
						Thread.sleep(100);
					}
					catch (Exception e) {
					}
					synchronized (resource2) {
						System.out.println("Thread 1: locked resource 2");
					}
				}
			}
		}
		;
		Thread t2 = new Thread() {
			public void run() {
				synchronized (resource2) {
					System.out.println("Thread 2: locked resource 2");
					try {
						Thread.sleep(100);
					}
					catch (Exception e) {
					}
					synchronized (resource1) {
						System.out.println("Thread 2: locked resource 1");
					}
				}
			}
		}
		;
		t1.start();
		t2.start();
	}
}

这个应用思路很简单，同时启动两个线程，分别锁住了resource1和resource2，然后休眠0.1秒，接着分别尝试去请求资源resource2和resource1。

执行应用，在控制台打印出下列输出后，进入死锁状态：

Thread 1: locked resource 1

Thread 2: locked resource 2

使用命令行 jps -l -m找到处于死锁状态应用的进程id。从下图得知死锁进程为51476:

然后使用命令行jstack 51476打印这个进程的运行栈信息。

我上图红色高亮出的 0x00000000d6f64988 和 0x00000000d6f649b8代表了代码中的两个资源“ABAP” 和“Java”。

jstack打印的输出非常清晰，显示了具体哪行Java代码试图去锁定哪一个Java资源(下图的waiting to lock)但是没有成功, 并且将失败的原因，即拥有当前请求资源的线程名称也打印了出来。

有了jstack，Java程序员不用对着冗长烧脑的多线程代码去冥思苦想了，JDK会自动把死锁原因打印出来，太方便了。

相信对于"开发一个会产生死锁的Java应用”这类需求，大家都能顺利完成。但是如果题目要求得更具体一些，要求这个死锁发生在数据库层面，应该怎样完成呢？

下面我提供一种答案，采用SAP的编程语言ABAP(Advanced Business Application Programming)实现。

我们从ABAP帮助文档中得知，SELECT SINGLE FOR UPDATE在从数据库读取一条记录时，会在数据库里将该条记录上锁。帮助文档里也提到，如果编程不恰当，会引起死锁(deadlock)。

所以我们的答题就利用SELECT SINGLE FOR UPDATE这条语句。

首先在数据库里插入两条记录，主键分别为Z01和Z02。

开发两个应用，第一个应用依次锁Z01和Z02。

REPORT zlock1.

DATA: ls_prod TYPE zorder_header.

SELECT SINGLE FOR UPDATE * FROM zorder_header INTO ls_prod WHERE object_id = 'Z01'.

SELECT SINGLE FOR UPDATE * FROM zorder_header INTO ls_prod WHERE object_id = 'Z02'.

第二个应用依次锁Z02和Z01。

REPORT zlock2.

DATA: ls_prod TYPE zorder_header.

SELECT SINGLE FOR UPDATE * FROM zorder_header INTO ls_prod WHERE object_id = 'Z02'.

SELECT SINGLE FOR UPDATE * FROM zorder_header INTO ls_prod WHERE object_id = 'Z01'.

下面的步骤会造成数据库层面的死锁。

1. 以调试模式运行第一个应用，单步执行完代码第10行，成功锁住Z01。

2. 新开一个窗口，以调试模式运行第二个应用，单步执行完代码第10行，成功锁住Z02。

3. 回到应用1的窗口，继续执行。此时应用1试图锁Z02，但是Z02已经被应用2锁住了，因此应用1处于等待状态。

4. 回到应用2的窗口，继续执行。此时应用2试图锁Z01，但是Z01已经被应用1锁住了，所以应用2只有等待应用1释放出Z01的锁。但应用1此时也在等待应用2，因此造成了死锁。

ABAP和Java不同，一旦检测到死锁，应用会抛运行时异常并自动终止，异常信息里说得很清楚：Deadlock detected while executing transaction…

要获取更多Jerry的原创技术文章，请关注公众号"汪子熙"。