阿里一面，說說你對Mysql死鎖的理解

隱風發表於2022-03-22
阿里MySql

又到了金三銀四的時候，大家都按耐不住內心的躁動，我在這裡給大家分享下之前面試中遇到的一個知識點（死鎖問題），如有不足，歡迎大佬們指點指點。

1、什麼是死鎖？

死鎖指的是在兩個或兩個以上不同的程式或執行緒中，由於存在共同資源的競爭或程式（或執行緒）間的通訊而導致各個執行緒間相互掛起等待，如果沒有外力作用，最終會引發整個系統崩潰。

2、Mysql出現死鎖的必要條件

  1. 資源獨佔條件

指多個事務在競爭同一個資源時存在互斥性，即在一段時間內某資源只由一個事務佔用，也可叫獨佔資源（如行鎖）。

  1. 請求和保持條件

指在一個事務a中已經獲得鎖A，但又提出了新的鎖B請求，而該鎖B已被其它事務b佔有，此時該事務a則會阻塞，但又對自己已獲得的鎖A保持不放。

  1. 不剝奪條件

指一個事務a中已經獲得鎖A，在未提交之前，不能被剝奪，只能在使用完後提交事務再自己釋放。

  1. 相互獲取鎖條件

指在發生死鎖時，必然存在一個相互獲取鎖過程，即持有鎖A的事務a在獲取鎖B的同時，持有鎖B的事務b也在獲取鎖A，最終導致相互獲取而各個事務都阻塞。

3、 Mysql經典死鎖案例

假設存在一個轉賬情景，A賬戶給B賬戶轉賬50元的同時，B賬戶也給A賬戶轉賬30元，那麼在這過程中是否會存在死鎖情況呢？

3.1 建表語句

CREATE TABLE `account` (
  `id` int(11) NOT NULL COMMENT '主鍵',
  `user_id` varchar(56) NOT NULL COMMENT '使用者id',
  `balance` float(10,2) DEFAULT NULL COMMENT '餘額',
  PRIMARY KEY (`id`),
  UNIQUE KEY `idx_user_id` (`user_id`) USING BTREE
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='賬戶餘額表';

3.2 初始化相關資料

INSERT INTO `test`.`account` (`id`, `user_id`, `balance`) VALUES (1, 'A', 80.00);
INSERT INTO `test`.`account` (`id`, `user_id`, `balance`) VALUES (2, 'B', 60.00);

在這裡插入圖片描述

3.3 正常轉賬過程

在說死鎖問題之前，我們們先來看看正常的轉賬過程。
正常情況下，A使用者給B使用者轉賬50元，可在一個事務內完成，需要先獲取A使用者的餘額和B使用者的餘額，因為之後需要修改這兩條資料，所以需要通過寫鎖（for UPDATE）鎖住他們，防止其他事務更改導致我們的更改丟失而引起髒資料。
相關sql如下：

開啟事務之前需要先把mysql的自動提交關閉

set autocommit=0;
# 檢視事務自動提交狀態狀態
show VARIABLES like 'autocommit';![在這裡插入圖片描述](https://img-blog.csdnimg.cn/a486a4ed5c9d4240bd115ac7b3ce5a39.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA6ZqQIOmjjg==,size_20,color_FFFFFF,t_70,g_se,x_16)


# 轉賬sql
START TRANSACTION;
# 獲取A 的餘額並存入A_balance變數：80
SELECT user_id,@A_balance:=balance from account where user_id = 'A' for UPDATE;
# 獲取B 的餘額並存入B_balance變數:60
SELECT user_id,@B_balance:=balance from account where user_id = 'B' for UPDATE;

# 修改A 的餘額
UPDATE account set balance = @A_balance - 50 where user_id = 'A';
# 修改B 的餘額
UPDATE account set balance = @B_balance + 50 where user_id = 'B';
COMMIT;

執行後的結果：
在這裡插入圖片描述
可以看到資料更新都是正常的情況

3.4 死鎖轉賬過程

初始化的餘額為：
在這裡插入圖片描述

假設在高併發情況下存在這種場景，A使用者給B使用者轉賬50元的同時，B使用者也給A使用者轉賬30元。

那麼我們的java程式操作的過程和時間線如下：

  1. A使用者給B使用者轉賬50元，需在程式中開啟事務1來執行sql，並獲取A的餘額同時鎖住A這條資料。
# 事務1
set autocommit=0;
START TRANSACTION;
# 獲取A 的餘額並存入A_balance變數：80
SELECT user_id,@A_balance:=balance from account where user_id = 'A' for UPDATE;
  1. B使用者給A使用者轉賬30元，需在程式中開啟事務2來執行sql，並獲取B的餘額同時鎖住B這條資料。
# 事務2
set autocommit=0;
START TRANSACTION;
# 獲取A 的餘額並存入A_balance變數：60
SELECT user_id,@A_balance:=balance from account where user_id = 'B' for UPDATE;
  1. 在事務1中執行剩下的sql
# 獲取B 的餘額並存入B_balance變數:60
SELECT user_id,@B_balance:=balance from account where user_id = 'B' for UPDATE;

# 修改A 的餘額
UPDATE account set balance = @A_balance - 50 where user_id = 'A';
# 修改B 的餘額
UPDATE account set balance = @B_balance + 50 where user_id = 'B';
COMMIT;

在這裡插入圖片描述

可以看到，在事務1中獲取B資料的寫鎖時出現了超時情況。為什麼會這樣呢？主要是因為我們在步驟2的時候已經在事務2中獲取到B資料的寫鎖了，那麼在事務2提交或回滾前事務1永遠都拿不到B資料的寫鎖。

  1. 在事務2中執行剩下的sql
# 獲取A 的餘額並存入B_balance變數:60
SELECT user_id,@B_balance:=balance from account where user_id = 'A' for UPDATE;

# 修改B 的餘額
UPDATE account set balance = @A_balance - 30 where user_id = 'B';
# 修改A 的餘額
UPDATE account set balance = @B_balance + 30 where user_id = 'A';
COMMIT;

在這裡插入圖片描述

同理可得，在事務2中獲取A資料的寫鎖時也出現了超時情況。因為步驟1的時候已經在事務1中獲取到A資料的寫鎖了，那麼在事務1提交或回滾前事務2永遠都拿不到A資料的寫鎖。

  1. 為什麼會出現這種情況呢？

主要是因為事務1和事務2存在相互等待獲取鎖的過程，導致兩個事務都掛起阻塞，最終丟擲獲取鎖超時的異常。

在這裡插入圖片描述

3.5 死鎖導致的問題

眾所周知，資料庫的連線資源是很珍貴的，如果一個連線因為事務阻塞長時間不釋放，那麼後面新的請求要執行的sql也會排隊等待，越積越多，最終會拖垮整個應用。一旦你的應用部署在微服務體系中而又沒有做熔斷處理，由於整個鏈路被阻斷，那麼就會引發雪崩效應，導致很嚴重的生產事故。

4、如何解決死鎖問題？

要想解決死鎖問題，我們可以從死鎖的四個必要條件入手。
由於資源獨佔條件和不剝奪條件是鎖本質的功能體現，無法修改，所以我們們從另外兩個條件嘗試去解決。

4.1 打破請求和保持條件

根據上面定義可知，出現這個情況是因為事務1和事務2同時去競爭鎖A和鎖B，那麼我們是否可以保證鎖A和鎖B一次只能被一個事務競爭和持有呢？
答案是肯定可以的。下面我們們通過虛擬碼來看看：

/**
* 事務1入參(A, B)
* 事務2入參(B, A)
**/
public void transferAccounts(String userFrom, String userTo) {
     // 獲取分散式鎖
     Lock lock = Redisson.getLock();
     // 開啟事務
     JDBC.excute("START TRANSACTION;");
     // 執行轉賬sql
     JDBC.excute("# 獲取A 的餘額並存入A_balance變數：80\n" +
             "SELECT user_id,@A_balance:=balance from account where user_id = '" + userFrom + "' for UPDATE;\n" +
             "# 獲取B 的餘額並存入B_balance變數:60\n" +
             "SELECT user_id,@B_balance:=balance from account where user_id = '" + userTo + "' for UPDATE;\n" +
             "\n" +
             "# 修改A 的餘額\n" +
             "UPDATE account set balance = @A_balance - 50 where user_id = '" + userFrom + "';\n" +
             "# 修改B 的餘額\n" +
             "UPDATE account set balance = @B_balance + 50 where user_id = '" + userTo + "';\n");
     // 提交事務
     JDBC.excute("COMMIT;");
     // 釋放鎖
     lock.unLock();
}

上面的虛擬碼顯而易見可以解決死鎖問題，因為所有的事務都是通過分散式鎖來序列執行的。

那麼這樣就真的萬事大吉了嗎？

在小流量情況下看起來是沒問題的，但是在高併發場景下這裡將成為整個服務的效能瓶頸，因為即使你部署了再多的機器，但由於分散式鎖的原因，你的業務也只能序列進行，服務效能並不因為叢集部署而提高併發量，完全無法滿足分散式業務下快、準、穩的要求，所以我們們不妨換種方式來看看怎麼解決死鎖問題。

4.2 打破相互獲取鎖條件（推薦）

要打破這個條件其實也很簡單，那就是事務再獲取鎖的過程中保證順序獲取即可，也就是鎖A始終在鎖B之前獲取。
我們來看看之前的虛擬碼怎麼優化？

/**
* 事務1入參(A, B)
* 事務2入參(B, A)
**/
public void transferAccounts(String userFrom, String userTo) {
     // 對使用者A和B進行排序，讓userFrom始終為使用者A，userTo始終為使用者B
     if (userFrom.hashCode() > userTo.hashCode()) {
         String tmp = userFrom;
         userFrom = userTo;
         userTo = tmp;
     }
     // 開啟事務
     JDBC.excute("START TRANSACTION;");
     // 執行轉賬sql
     JDBC.excute("# 獲取A 的餘額並存入A_balance變數：80\n" +
             "SELECT user_id,@A_balance:=balance from account where user_id = '" + userFrom + "' for UPDATE;\n" +
             "# 獲取B 的餘額並存入B_balance變數:60\n" +
             "SELECT user_id,@B_balance:=balance from account where user_id = '" + userTo + "' for UPDATE;\n" +
             "\n" +
             "# 修改A 的餘額\n" +
             "UPDATE account set balance = @A_balance - 50 where user_id = '" + userFrom + "';\n" +
             "# 修改B 的餘額\n" +
             "UPDATE account set balance = @B_balance + 50 where user_id = '" + userTo + "';\n");
     // 提交事務
     JDBC.excute("COMMIT;");
 }

假設事務1的入參為(A, B)，事務2入參為(B, A)，由於我們對兩個使用者引數進行了排序，所以在事務1中需要先獲取鎖A在獲取鎖B，事務2也是一樣要先獲取鎖A在獲取鎖B，兩個事務都是順序獲取鎖，所以也就打破了相互獲取鎖的條件，最終完美解決死鎖問題。

5、總結

因為mysql在網際網路中的大量使用，所以死鎖問題還是經常會被問到，希望兄弟們能掌握這方面的知識，提高自己的競爭力。

最後，外出打工不易，希望各位兄弟找到自己心儀的工作，虎年發發發！
也希望兄弟們能關注、點贊、收藏、評論支援一波，非常感謝大家！

相關文章