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的原創文章，請關注公眾號"汪子熙":

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/24475491/viewspace-2689681/，如需轉載，請註明出處，否則將追究法律責任。