ABAP面試題系列：寫一組會出現死鎖(Deadlock)的ABAP程序

咱們在計算機操做系統這門專業課上，學過死鎖(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的原創文章，請關注公衆號"汪子熙":