我們在計算機操作系統這門專業課上，學過死鎖(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，如果該程序發生了死鎖，該工具會打印出程序里具體是哪一行代碼，在試圖對何種資源進行上鎖操作時出現的死鎖，從而幫助開發人員迅速定位到邏輯上存在缺陷的代碼位置。

希望本文這個小小的例子能幫助大家回憶起死鎖這個基礎知識點，感謝閱讀。

要獲取更多Jerry的原創文章，請關注公眾號"汪子熙":

總結

以上是生活随笔為你收集整理的ABAP面试题系列：写一组会出现死锁(Deadlock)的ABAP程序的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。