本文介紹了一個 MySQL 數據庫死鎖的案例和解決方案。
場景
生產環境出了一個偶現的數據庫死鎖問題，導致少部分業務處理失敗。
分析特征之后，發現是多個線程并發執行同一個方法，更新關聯的數據時可能會出現，把場景簡化概括一下：
-
有一個數據表 tb1，主鍵名 id，有兩條 id 分別為 A1 和 A2 的記錄，對應的外鍵 fk_biz_no 相同；
-
方法 myFunc，整體是一個事務；
-
方法 myFunc 里的邏輯是先更新 tb1 里的一條記錄，執行一些邏輯后，再更新該記錄的外鍵對應的所有記錄；
這樣 線程1 和 線程2 并發執行 myFunc 方法時，示意如下：
線程1 先更新 A1，此時會對 A1 所在行加寫鎖，再更新 A1 和 A2，此時會同時給 A1 和 A2 所在行都加上寫鎖；
線程2 先更新 A2，此時會對 A2 所在行加寫鎖，再更新 A1 和 A2，此時會同時給 A1 和 A2 所在行都加上寫鎖。
如此一來，如果出現類似以下的執行時序，則會形成死鎖：
帶著一點偽裝的 ABBA 死鎖。
解決方案
按照消除死鎖條件的思路，一般會想到將兩個線程里的加鎖順序改為一致，但是此場景并不完全適用。以下是幾種可行的方案：
方案一、對 myFunc 方法加分布式鎖，可以用需要更新的記錄的 fk_biz_no 作為鎖的 key，這樣同一個 fk_biz_no 的更新操作就會串行執行；
方案二、在方法/事務的最開始，就提前把 A1A2 的寫鎖申請到（比如 SELECT ... FOR UPDATE），然后再執行后續邏輯；
方案三、優化 myFunc 方法里的邏輯，先將 A1 和 A2 的數據都處理好了，然后一次性更新 A1A2，即將方法里的兩次更新合并成一次更新；
方案一 和 方案二 效果類似，都是使同一 fk_biz_no 的更新操作串行了；而方法三則是消除了 ABBA 的情況（實際場景中有可能需要考慮并發執行下的數據混亂、數據覆蓋的問題，那是另外的話題了，在此不展開）。
小結
來一起復習下死鎖的四個必要條件：
-
互斥條件：一個資源每次只能被一個進程使用；
-
請求與保持條件：一個進程因請求資源而阻塞時，對已獲得的資源保持不放；
-
不剝奪條件：進程已獲得的資源，在末使用完之前，不能強行剝奪；
-
循環等待條件：若干進程之間形成一種頭尾相接的循環等待資源關系。
預防和消除死鎖的思路，則無非是消除上述四個條件中的一個或多個。
