我们在计算机操作系统这门专业课上，学过死锁(Deadlock)的概念：两个或两个以上的进程(或线程)在执行过程中，由于竞争资源而造成的一种阻塞的现象，称为死锁。若无外力干预，这些处于死锁状态的进程将永远处于互相等待的阻塞状态中。
![]()
正好我儿子走到我电脑前看到文章标题，好奇地问我什么是死锁。我解释道，“假设你和白妹妹(他的玩伴)手上都有一张奥特曼白金卡，你特别想要白妹妹手上那张白金卡，白妹妹也特别想要你手上那张白金卡。你们都想让对方把他/她手上那张卡送给你们，但你们都舍不得把自己手上那张卡送出去。这就是死锁。”
儿子又问，那这种情况咋办。
我说，只有靠大人的介入。比如你老爸出马，把你们手中两张卡都没收了，等我玩够了再还给你们，这样你们就不会死锁了。
![]()
![]()
不过Jerry仔细端详了这些一零后们喜欢玩的奥特曼卡片，发现毫无吸引我之处。我还是更喜欢欣赏和收藏这些反映祖国传统文化的水浒传人物卡片。
![]()
![]()
![]()
言归正传，在使用ABAP答这道面试题之前，我们先看看如何用Java编写一个会出现死锁的程序。
不到40行代码就完成任务。为了便于ABAP从业人员理解，没有使用Java里的Lambda表达式，否则代码可以更短。
该程序逻辑如下：
线程1持有资源1，试图持有资源2；
线程2持有资源2，试图持有资源1；
死锁发生；
![]()
现在进入ABAP部分。
ABAP帮助文档提到，使用SELECT SINGLE FOR UPDATE读取单条记录时，会自动在数据库层面为该条记录设置一把锁(Exclusive lock，有的中文文档翻译成排他锁)。如果上锁操作会导致死锁发生，则会抛出异常。
![]()
于是我们首先创建一个ABAP数据库表，插入两条记录：
![]()
再开发两个ABAP程序ZLOCK1和ZLOCK2，分别按照Z01, Z02和Z02, Z01的顺序使用SELECT SINGLE FOR UPDATE向数据库发起读取请求。
![]()
![]()
开启两个SAPGUI窗口，按照下面的步骤执行这两个程序，即可产生死锁。
(1) 以调试模式单步执行程序ZLOCK1，成功执行完SELECT SINGLE FOR UPDATE .. WHERE object_id = 'Z01', 意味着此时程序ZLOCK1在数据库层面对Z01这条记录设置了一把锁。
![]()
(2) 切换到另一个SAPGUI窗口，执行程序ZLOCK2, 单步调试执行完语句SELECT SINGLE FOR UPDATE .. WHERE object_id = 'Z02'，即此时程序ZLOCK2在数据库层面对Z02成功上锁。
![]()
(3) 再回到窗口1，继续调试程序ZLOCK1，此时调试器会阻塞，因为ZLOCK1试图对Z02上锁，而此时程序ZLOCK2持有记录Z02的锁。程序ZLOCK1处于阻塞状态，等待ZLOCK2释放对记录Z02设置的锁。
![]()
(3) 回到窗口2，继续在调试模式下执行ZLOCK2程序第12行语句。此时程序ZLOCK2试图对记录Z01上锁，但该记录已经被程序ZLOCK1锁住了，程序ZLOCK2只好等待程序ZLOCK1释放对记录Z01的锁；而程序ZLOCK1永远也不可能释放对记录Z01上的锁，因为此刻它已经处于阻塞状态了，在等待程序ZLOCK2释放对记录Z02的锁。
![]()
此时ABAP Kernel检测到程序ZLOCK2发生了死锁，抛出一个运行时异常，结束了ZLOCK2的执行。程序ZLOCK2持有对记录Z02的锁也自动释放了。最后的结果是，程序ZLOCK1成功地对记录Z02上了锁。
![]()
在事务码ST22里，我们能观察到这次死锁的详情。
![]()
ABAP Kernel这种检测到死锁发生后，立刻终止程序运行的方式，节省了应用开发人员通过阅读代码去分析死锁的时间。
回到Jerry之前的Java程序，运行之后两个线程陷入死锁，在控制台上没有打印任何可供排错的信息。然而JDK本身提供了方便的检查Java应用死锁状态的命令行工具：jstack.
![]()
命令行执行jstack，传入Java程序的进程id，如果该程序发生了死锁，该工具会打印出程序里具体是哪一行代码，在试图对何种资源进行上锁操作时出现的死锁，从而帮助开发人员迅速定位到逻辑上存在缺陷的代码位置。
![]()
希望本文这个小小的例子能帮助大家回忆起死锁这个基础知识点，感谢阅读。
本文来自云栖社区合作伙伴“汪子熙”，了解相关信息可以关注微信公众号"汪子熙"。
