Mybatis-Plus可能導致死鎖的問題分析及解決辦法
1 場景還原
1.1 版本信息
MySQL版本：5.6.36-82.1-log
Mybatis-Plus的starter版本：3.3.2
存儲引擎：InnoDB
1.2 死鎖現(xiàn)象
A同學在生產(chǎn)環(huán)境使用了Mybatis-Plus提供的 com.baomidou.mybatisplus.extension.service.IService#saveOrUpdate(T, com.baomidou.mybatisplus.core.conditions.Wrapper) 方法（以下簡稱B方法），并發(fā)場景下，數(shù)據(jù)庫報了如下錯誤
2 為什么是間隙鎖死鎖？
如上圖示，數(shù)據(jù)庫報了死鎖，那死鎖場景千萬種，為什么確定B方法是由于間隙鎖導致的死鎖？
2.1 什么是死鎖？
兩個事務(wù)互相等待對方持有的鎖，導致互相阻塞，從而導致死鎖。
2.2 什么是間隙鎖？
- 間隙鎖是MySQL行鎖的一種，與Record lock不同的是間隙鎖鎖定的是一個間隙。
- 鎖定規(guī)則如下：
MySQL會向左找第一個比當前索引值小的值，向右找第一個比當前索引值大 的值（沒有則為正無窮），將此區(qū)間鎖住，從而阻止其他事務(wù)在此區(qū)間插入數(shù)據(jù)。
2.3 MySQL為什么要引入間隙鎖？
與Record lock組合成Next-key lock，在可重復讀這種隔離級別下一起工作避免幻讀。
2.4 間隙鎖死鎖分析
理論上一款開源的框架，經(jīng)過了多年打磨，提供的方法不應(yīng)該造成如此嚴重的錯誤，但理論僅僅是理論上，事實就是發(fā)生了死鎖，于是我們開始了一輪深度排查。首先我們從這個方法的源碼入手，源碼如下：
default boolean saveOrUpdate(T entity, Wrapper<T> updateWrapper) {
return this.update(entity, updateWrapper) || this.saveOrUpdate(entity);
}
從源碼上看此方法就沒有按套路出牌，正常邏輯應(yīng)該是首先執(zhí)行查詢，存在則修改，不存在則新增，但此方法上來就執(zhí)行了修改。我們就猜想是不是MySQL在修改時增加了什么鎖導致了死鎖，于是我們找到了DBA獲取了最新的死鎖日志，即執(zhí)行show engine innodb status，我們發(fā)現(xiàn)了兩項關(guān)鍵信息如下：
*** (1) TRANSACTION: ...省略日志 *** (1) WAITING FOR THIS LOCK TO BE GRANTED: RECORD LOCKS space id 0 page no 347 n bits 80 index `PRIMARY` of table `database_name`.`table_name` trx id 71C lock_mode X locks gap before rec insert intention waiting *** (2) TRANSACTION: ...省略日志 *** (2) WAITING FOR THIS LOCK TO BE GRANTED: RECORD LOCKS space id 0 page no 347 n bits 80 index `PRIMARY` of table `database_name`.`table_name` trx id 71D lock_mode X locks gap before rec insert intention waiting
簡單翻譯一下，就是事務(wù)一在獲取插入意向鎖時，需要等待間隙鎖（事務(wù)二添加）釋放，同時事務(wù)二在獲取插入意向鎖時，也在等待間隙鎖釋放（事務(wù)一添加）， （本文不討論MySQL在修改與插入時添加的鎖，我們把修改時添加間隙鎖，插入時獲取插入意向鎖為已知條件） 那我們回到B方法，并發(fā)場景下，是不是就很大幾率會滿足事務(wù)一和事務(wù)二相互等待對方持有的間隙鎖，從而導致死鎖。
現(xiàn)在我們理論有了，我們現(xiàn)在用真實數(shù)據(jù)來驗證此場景。
2.5 驗證間隙鎖死鎖
- 準備如下表結(jié)構(gòu)（以下簡稱驗證一）
create table t_gap_lock( id int auto_increment primary key comment '主鍵ID', name varchar(64) not null comment '名稱', age int not null comment '年齡' ) comment '間隙鎖測試表';
- 準備如下表數(shù)據(jù)
mysql> select * from t_gap_lock; +----+------+-----+ | id | name | age | +----+------+-----+ | 1 | 張三 | 18 | | 5 | 李四 | 19 | | 6 | 王五 | 20 | | 9 | 趙六 | 21 | | 12 | 孫七 | 22 | +----+------+-----+
- 我們開啟事務(wù)一，并執(zhí)行如下語句，注意這個時候我們還沒有提交事務(wù)
mysql> begin; Query OK, 0 rows affected (0.00 sec) mysql> update t_gap_lock t set t.age = 25 where t.id = 4; Query OK, 0 rows affected (0.00 sec) Rows matched: 0 Changed: 0 Warnings: 0
- 接下來我們在事務(wù)一中執(zhí)行如下語句
mysql> insert into t_gap_lock(id, name, age) value (7,'間隙鎖7',27);
- 我們會發(fā)現(xiàn)事務(wù)一被阻塞了，然后我們執(zhí)行以下語句看下當前正在鎖的事務(wù)。
mysql> SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCKS \G;
*************************** 1. row ***************************
lock_id: 749:0:360:3
lock_trx_id: 749
lock_mode: X,GAP
lock_type: RECORD
lock_table: `test`.`t_gap_lock`
lock_index: `PRIMARY`
lock_space: 0
lock_page: 360
lock_rec: 3
lock_data: 5
*************************** 2. row ***************************
lock_id: 74A:0:360:3
lock_trx_id: 74A
lock_mode: X,GAP
lock_type: RECORD
lock_table: `test`.`t_gap_lock`
lock_index: `PRIMARY`
lock_space: 0
lock_page: 360
lock_rec: 3
lock_data: 5
2 rows in set (0.00 sec)
根據(jù)lock_type和lock_mode我們可以很清晰的看到鎖類型是行鎖，鎖模式是間隙鎖。
- 與此同時我們在事務(wù)二中執(zhí)行如下語句
insert into t_gap_lock(id, name, age) value (4,'間隙鎖4',24);
- 一執(zhí)行以上語句，數(shù)據(jù)庫就立馬報了死鎖，并且回滾了事務(wù)二（可以在死鎖日志中看到*** WE ROLL BACK TRANSACTION (2)）
ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction
到這里，細心的同學就會發(fā)現(xiàn)，誒，你這上面故意造了一個間隙，并且讓兩個事務(wù)分別在對方的間隙中插入數(shù)據(jù)，太刻意了，生產(chǎn)環(huán)境基本上不會有這種場景，是的，生產(chǎn)環(huán)境怎么會有這種場景呢，上面的數(shù)據(jù)只是為了讓大家直觀的看到間隙鎖的死鎖過程，接下來那我們再來一組數(shù)據(jù)，我們簡稱驗證二。
- 我們還是以驗證一的表結(jié)構(gòu)與數(shù)據(jù)，我們來執(zhí)行這樣一個操作。首先我們開始開啟事務(wù)一并且執(zhí)行如下操作，依然不提交事務(wù)
mysql> begin; Query OK, 0 rows affected (0.00 sec) mysql> update t_gap_lock t set t.age = 25 where t.id = 4; Query OK, 0 rows affected (0.00 sec) Rows matched: 0 Changed: 0 Warnings: 0
- 同時我們開啟事務(wù)二，執(zhí)行與事務(wù)一一樣的操作，我們會驚奇的發(fā)現(xiàn)，竟然也成功了。
mysql> begin; Query OK, 0 rows affected (0.00 sec) mysql> update t_gap_lock t set t.age = 25 where t.id = 4; Query OK, 0 rows affected (0.00 sec) Rows matched: 0 Changed: 0 Warnings: 0
- 于是乎我們在事務(wù)一執(zhí)行如下操作，我們又驚奇的發(fā)現(xiàn)事務(wù)一被阻塞了。
insert into t_gap_lock(id, name, age) value (4,'間隙鎖4',24);
- 在事務(wù)一被阻塞的同時，我們在事務(wù)二執(zhí)行同樣的語句，我們發(fā)現(xiàn)數(shù)據(jù)庫立馬就報了死鎖。
insert into t_gap_lock(id, name, age) value (4,'間隙鎖4',24); ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction
驗證二完整的復現(xiàn)了線上死鎖的過程，也就是事務(wù)一先執(zhí)行了更新語句，事務(wù)二在同一時刻也執(zhí)行了更新語句，然后事務(wù)一發(fā)現(xiàn)沒有更新到就去執(zhí)行主鍵查詢語句，發(fā)現(xiàn)確實沒有，所以執(zhí)行了插入語句，但是插入要先獲取插入意向鎖，在獲取插入意向鎖的時候發(fā)現(xiàn)這個間隙已經(jīng)被事務(wù)二加鎖了，所以事務(wù)一開始等待事務(wù)二釋放間隙鎖，同理，事務(wù)二也執(zhí)行上述操作，最終導致事務(wù)一與事務(wù)二互相等待對方釋放間隙鎖，最終導致死鎖。
驗證二還說明了一個問題，就是間隙鎖加鎖是非互斥的，也就是事務(wù)一對間隙A加鎖后，事務(wù)二依然可以給間隙A加鎖。
3 如何解決？
3.1 關(guān)閉間隙鎖（不推薦）
- 降低隔離級別，例如降為提交讀。
- 直接修改my.cnf，將開關(guān)，innodb_locks_unsafe_for_binlog改為1，默認為0即開啟
PS：以上方法僅適用于當前業(yè)務(wù)場景確實不關(guān)心幻讀的問題。
3.2 自定義saveOrUpdate方法（推薦）
建議自己編寫一個saveOrUpdate方法，當然也可以直接采用Mybatis-Plus提供的saveOrUpdate方法，但是根據(jù)源碼發(fā)現(xiàn)，會有很多額外的反射操作，并且還添加了事務(wù)，大家都知道，MySQL單表操作完全不需要開事務(wù)，會增加額外的開銷。
@Transactional(
rollbackFor = {Exception.class}
)
public boolean saveOrUpdate(T entity) {
if (null == entity) {
return false;
} else {
Class<?> cls = entity.getClass();
TableInfo tableInfo = TableInfoHelper.getTableInfo(cls);
Assert.notNull(tableInfo, "error: can not execute. because can not find cache of TableInfo for entity!", new Object[0]);
String keyProperty = tableInfo.getKeyProperty();
Assert.notEmpty(keyProperty, "error: can not execute. because can not find column for id from entity!", new Object[0]);
Object idVal = ReflectionKit.getFieldValue(entity, tableInfo.getKeyProperty());
return !StringUtils.checkValNull(idVal) && !Objects.isNull(this.getById((Serializable)idVal)) ? this.updateById(entity) : this.save(entity);
}
}
4 拓展
4.1 如果兩個事務(wù)修改是存在的行會發(fā)生什么？
在驗證二中兩個事務(wù)修改的都是不存在的行，都能加間隙鎖成功，那如果兩個事務(wù)修改的是存在的行，MySQL還會加間隙鎖嗎？或者說把間隙鎖從鎖間隙降為鎖一行？帶著疑問，我們執(zhí)行以下數(shù)據(jù)驗證，我們還是使用驗證一的表和數(shù)據(jù)。
- 首先我們開啟事務(wù)一執(zhí)行以下語句
mysql> begin; Query OK, 0 rows affected (0.00 sec) mysql> update t_gap_lock t set t.age = 25 where t.id = 1; Query OK, 1 row affected (0.00 sec) Rows matched: 1 Changed: 1 Warnings: 0
- 我們再開啟事務(wù)二，執(zhí)行同樣的語句，發(fā)現(xiàn)事務(wù)二已經(jīng)被阻塞
mysql> begin; Query OK, 0 rows affected (0.00 sec) mysql> update t_gap_lock t set t.age = 25 where t.id = 1;
- 這個時候我們執(zhí)行以下語句看下當前正在鎖的事務(wù)。
mysql> SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCKS \G;
*************************** 1. row ***************************
lock_id: 75C:0:360:2
lock_trx_id: 75C
lock_mode: X
lock_type: RECORD
lock_table: `test`.`t_gap_lock`
lock_index: `PRIMARY`
lock_space: 0
lock_page: 360
lock_rec: 2
lock_data: 1
*************************** 2. row ***************************
lock_id: 75B:0:360:2
lock_trx_id: 75B
lock_mode: X
lock_type: RECORD
lock_table: `test`.`t_gap_lock`
lock_index: `PRIMARY`
lock_space: 0
lock_page: 360
lock_rec: 2
lock_data: 1
2 rows in set (0.00 sec)
根據(jù)lock_type和lock_mode我們看到事務(wù)一和二加的鎖變成了Record Lock，并沒有再添加間隙鎖，根據(jù)以上數(shù)據(jù)驗證MySQL在修改存在的數(shù)據(jù)時會給行加上Record Lock，與間隙鎖不同的是該鎖是互斥的，即不同的事務(wù)不能同時對同一行記錄添加Record Lock。
5 結(jié)語
雖然Mybatis-Plus提供的這個方法可能會造成死鎖，但是依然不可否認它是一款非常優(yōu)秀的增強框架，其提供的lambda寫法在日常工作中極大的提高了我們的開發(fā)效率，所以凡事都用兩面性，我們應(yīng)該秉承辯證的態(tài)度，熟悉的方法嘗試用，陌生的方法謹慎用。
以上就是Mybatis-Plus可能導致死鎖的問題分析及解決辦法的詳細內(nèi)容，更多關(guān)于Mybatis-Plus死鎖的資料請關(guān)注腳本之家其它相關(guān)文章！
相關(guān)文章
SpringBoot用配置影響B(tài)ean加載@ConditionalOnProperty
這篇文章主要為大家介紹了SpringBoot用配置影響B(tài)ean加載@ConditionalOnProperty示例詳解，有需要的朋友可以借鑒參考下，希望能夠有所幫助，祝大家多多進步，早日升職加薪2023-04-04
SpringBoot注解@EnableScheduling定時任務(wù)詳細解析
這篇文章主要介紹了SpringBoot注解@EnableScheduling定時任務(wù)詳細解析,@EnableScheduling 開啟對定時任務(wù)的支持,啟動類里面使用@EnableScheduling 注解開啟功能,自動掃描,需要的朋友可以參考下2024-01-01
在本篇文章里小編給大家整理的是一篇關(guān)于java類成員中的訪問級別淺析內(nèi)容，有興趣的朋友們跟著學習下。2021-01-01
RocketMQ producer同步發(fā)送單向發(fā)送源碼解析
這篇文章主要為大家介紹了RocketMQ producer同步發(fā)送單向發(fā)送源碼解析，有需要的朋友可以借鑒參考下，希望能夠有所幫助，祝大家多多進步，早日升職加薪2023-03-03
JAVA中常用的設(shè)計模式：單例模式，工廠模式，觀察者模式
設(shè)計模式（Design pattern）代表了最佳的實踐，通常被有經(jīng)驗的面向?qū)ο蟮能浖_發(fā)人員所采用。設(shè)計模式是軟件開發(fā)人員在軟件開發(fā)過程中面臨的一般問題的解決方案。這些解決方案是眾多軟件開發(fā)人員經(jīng)過相當長的一段時間的試驗和錯誤總結(jié)出來的。2020-04-04
這篇文章主要介紹了Java基礎(chǔ)之數(shù)組詳解,文中有非常詳細的代碼示例,對正在學習java的小伙伴們有很好的幫助,需要的朋友可以參考下2021-04-04
這篇文章主要介紹了Apache Camel的Java編程入門指南,Apache Camel規(guī)則路由引擎中提供了很多Java可擴展接口,需要的朋友可以參考下2015-07-07
這篇文章主要介紹了Java IO流和文件操作實現(xiàn)過程解析,文中通過示例代碼介紹的非常詳細，對大家的學習或者工作具有一定的參考學習價值,需要的朋友可以參考下2019-10-10
Eclipse中導入Maven Web項目并配置其在Tomcat中運行圖文詳解
這篇文章主要介紹了Eclipse中導入Maven Web項目并配置其在Tomcat中運行圖文詳解,需要的朋友可以參考下2017-12-12
Spring?Security實現(xiàn)添加圖片驗證功能
這篇文章主要為大家介紹了Spring?Security實現(xiàn)添加圖片驗證功能詳解，有需要的朋友可以借鑒參考下，希望能夠有所幫助，祝大家多多進步，早日升職加薪2023-01-01