本文介紹了一個 MySQL 數(shù)據(jù)庫死鎖的案例和解決方案。

場景

生產(chǎn)環(huán)境出了一個偶現(xiàn)的數(shù)據(jù)庫死鎖問題，導(dǎo)致少部分業(yè)務(wù)處理失敗。

分析特征之后，發(fā)現(xiàn)是多個線程并發(fā)執(zhí)行同一個方法，更新關(guān)聯(lián)的數(shù)據(jù)時可能會出現(xiàn)，把場景簡化概括一下：

• 有一個數(shù)據(jù)表 tb1，主鍵名 id，有兩條 id 分別為 A1 和 A2 的記錄，對應(yīng)的外鍵 fk_biz_no 相同；
• 方法 myFunc，整體是一個事務(wù)；
• 方法 myFunc 里的邏輯是先更新 tb1 里的一條記錄，執(zhí)行一些邏輯后，再更新該記錄的外鍵對應(yīng)的所有記錄；

這樣 線程1 和 線程2 并發(fā)執(zhí)行 myFunc 方法時，示意如下：

線程1 先更新 A1，此時會對 A1 所在行加寫鎖，再更新 A1 和 A2，此時會同時給 A1 和 A2 所在行都加上寫鎖；

線程2 先更新 A2，此時會對 A2 所在行加寫鎖，再更新 A1 和 A2，此時會同時給 A1 和 A2 所在行都加上寫鎖。

如此一來，如果出現(xiàn)類似以下的執(zhí)行時序，則會形成死鎖：

帶著一點偽裝的 ABBA 死鎖。

解決方案

按照消除死鎖條件的思路，一般會想到將兩個線程里的加鎖順序改為一致，但是此場景并不完全適用。以下是幾種可行的方案：

• 方案一、對 myFunc 方法加分布式鎖，可以用需要更新的記錄的 fk_biz_no 作為鎖的 key，這樣同一個 fk_biz_no 的更新操作就會串行執(zhí)行；
• 方案二、在方法/事務(wù)的最開始，就提前把 A1A2 的寫鎖申請到（比如 SELECT ... FOR UPDATE），然后再執(zhí)行后續(xù)邏輯；
• 方案三、優(yōu)化 myFunc 方法里的邏輯，先將 A1 和 A2 的數(shù)據(jù)都處理好了，然后一次性更新 A1A2，即將方法里的兩次更新合并成一次更新；

方案一 和 方案二 效果類似，都是使同一 fk_biz_no 的更新操作串行了；而方法三則是消除了 ABBA 的情況（實際場景中有可能需要考慮并發(fā)執(zhí)行下的數(shù)據(jù)混亂、數(shù)據(jù)覆蓋的問題，那是另外的話題了，在此不展開）。

小結(jié)

來一起復(fù)習(xí)下死鎖的四個必要條件：

• 互斥條件：一個資源每次只能被一個進(jìn)程使用；
• 請求與保持條件：一個進(jìn)程因請求資源而阻塞時，對已獲得的資源保持不放；
• 不剝奪條件：進(jìn)程已獲得的資源，在末使用完之前，不能強(qiáng)行剝奪；
• 循環(huán)等待條件：若干進(jìn)程之間形成一種頭尾相接的循環(huán)等待資源關(guān)系。

預(yù)防和消除死鎖的思路，則無非是消除上述四個條件中的一個或多個。