Mybatis-Plus可能导致死锁的问题分析及解决办法
1 场景还原
1.1 版本信息
MySQL版本：5.6.36-82.1-log
Mybatis-Plus的starter版本：3.3.2
存储引擎：InnoDB
1.2 死锁现象
A同学在生产环境使用了Mybatis-Plus提供的 com.baomidou.mybatisplus.extension.service.IService#saveOrUpdate(T, com.baomidou.mybatisplus.core.conditions.Wrapper) 方法（以下简称B方法），并发场景下，数据库报了如下错误
2 为什么是间隙锁死锁？
如上图示，数据库报了死锁，那死锁场景千万种，为什么确定B方法是由于间隙锁导致的死锁？
2.1 什么是死锁？
两个事务互相等待对方持有的锁，导致互相阻塞，从而导致死锁。
2.2 什么是间隙锁？
- 间隙锁是MySQL行锁的一种，与Record lock不同的是间隙锁锁定的是一个间隙。
- 锁定规则如下：
MySQL会向左找第一个比当前索引值小的值，向右找第一个比当前索引值大 的值（没有则为正无穷），将此区间锁住，从而阻止其他事务在此区间插入数据。
2.3 MySQL为什么要引入间隙锁？
与Record lock组合成Next-key lock，在可重复读这种隔离级别下一起工作避免幻读。
2.4 间隙锁死锁分析
理论上一款开源的框架，经过了多年打磨，提供的方法不应该造成如此严重的错误，但理论仅仅是理论上，事实就是发生了死锁，于是我们开始了一轮深度排查。首先我们从这个方法的源码入手，源码如下：
default boolean saveOrUpdate(T entity, Wrapper<T> updateWrapper) {
return this.update(entity, updateWrapper) || this.saveOrUpdate(entity);
}
从源码上看此方法就没有按套路出牌，正常逻辑应该是首先执行查询，存在则修改，不存在则新增，但此方法上来就执行了修改。我们就猜想是不是MySQL在修改时增加了什么锁导致了死锁，于是我们找到了DBA获取了最新的死锁日志，即执行show engine innodb status，我们发现了两项关键信息如下：
*** (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
简单翻译一下，就是事务一在获取插入意向锁时，需要等待间隙锁（事务二添加）释放，同时事务二在获取插入意向锁时，也在等待间隙锁释放（事务一添加）， （本文不讨论MySQL在修改与插入时添加的锁，我们把修改时添加间隙锁，插入时获取插入意向锁为已知条件） 那我们回到B方法，并发场景下，是不是就很大几率会满足事务一和事务二相互等待对方持有的间隙锁，从而导致死锁。
现在我们理论有了，我们现在用真实数据来验证此场景。
2.5 验证间隙锁死锁
- 准备如下表结构（以下简称验证一）
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 '间隙锁测试表';
- 准备如下表数据
mysql> select * from t_gap_lock; +----+------+-----+ | id | name | age | +----+------+-----+ | 1 | 张三 | 18 | | 5 | 李四 | 19 | | 6 | 王五 | 20 | | 9 | 赵六 | 21 | | 12 | 孙七 | 22 | +----+------+-----+
- 我们开启事务一，并执行如下语句，注意这个时候我们还没有提交事务
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
- 接下来我们在事务一中执行如下语句
mysql> insert into t_gap_lock(id, name, age) value (7,'间隙锁7',27);
- 我们会发现事务一被阻塞了，然后我们执行以下语句看下当前正在锁的事务。
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)
根据lock_type和lock_mode我们可以很清晰的看到锁类型是行锁，锁模式是间隙锁。
- 与此同时我们在事务二中执行如下语句
insert into t_gap_lock(id, name, age) value (4,'间隙锁4',24);
- 一执行以上语句，数据库就立马报了死锁，并且回滚了事务二（可以在死锁日志中看到*** WE ROLL BACK TRANSACTION (2)）
ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction
到这里，细心的同学就会发现，诶，你这上面故意造了一个间隙，并且让两个事务分别在对方的间隙中插入数据，太刻意了，生产环境基本上不会有这种场景，是的，生产环境怎么会有这种场景呢，上面的数据只是为了让大家直观的看到间隙锁的死锁过程，接下来那我们再来一组数据，我们简称验证二。
- 我们还是以验证一的表结构与数据，我们来执行这样一个操作。首先我们开始开启事务一并且执行如下操作，依然不提交事务
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
- 同时我们开启事务二，执行与事务一一样的操作，我们会惊奇的发现，竟然也成功了。
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
- 于是乎我们在事务一执行如下操作，我们又惊奇的发现事务一被阻塞了。
insert into t_gap_lock(id, name, age) value (4,'间隙锁4',24);
- 在事务一被阻塞的同时，我们在事务二执行同样的语句，我们发现数据库立马就报了死锁。
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
验证二完整的复现了线上死锁的过程，也就是事务一先执行了更新语句，事务二在同一时刻也执行了更新语句，然后事务一发现没有更新到就去执行主键查询语句，发现确实没有，所以执行了插入语句，但是插入要先获取插入意向锁，在获取插入意向锁的时候发现这个间隙已经被事务二加锁了，所以事务一开始等待事务二释放间隙锁，同理，事务二也执行上述操作，最终导致事务一与事务二互相等待对方释放间隙锁，最终导致死锁。
验证二还说明了一个问题，就是间隙锁加锁是非互斥的，也就是事务一对间隙A加锁后，事务二依然可以给间隙A加锁。
3 如何解决？
3.1 关闭间隙锁（不推荐）
- 降低隔离级别，例如降为提交读。
- 直接修改my.cnf，将开关，innodb_locks_unsafe_for_binlog改为1，默认为0即开启
PS：以上方法仅适用于当前业务场景确实不关心幻读的问题。
3.2 自定义saveOrUpdate方法（推荐）
建议自己编写一个saveOrUpdate方法，当然也可以直接采用Mybatis-Plus提供的saveOrUpdate方法，但是根据源码发现，会有很多额外的反射操作，并且还添加了事务，大家都知道，MySQL单表操作完全不需要开事务，会增加额外的开销。
@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 如果两个事务修改是存在的行会发生什么？
在验证二中两个事务修改的都是不存在的行，都能加间隙锁成功，那如果两个事务修改的是存在的行，MySQL还会加间隙锁吗？或者说把间隙锁从锁间隙降为锁一行？带着疑问，我们执行以下数据验证，我们还是使用验证一的表和数据。
- 首先我们开启事务一执行以下语句
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
- 我们再开启事务二，执行同样的语句，发现事务二已经被阻塞
mysql> begin; Query OK, 0 rows affected (0.00 sec) mysql> update t_gap_lock t set t.age = 25 where t.id = 1;
- 这个时候我们执行以下语句看下当前正在锁的事务。
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)
根据lock_type和lock_mode我们看到事务一和二加的锁变成了Record Lock，并没有再添加间隙锁，根据以上数据验证MySQL在修改存在的数据时会给行加上Record Lock，与间隙锁不同的是该锁是互斥的，即不同的事务不能同时对同一行记录添加Record Lock。
5 结语
虽然Mybatis-Plus提供的这个方法可能会造成死锁，但是依然不可否认它是一款非常优秀的增强框架，其提供的lambda写法在日常工作中极大的提高了我们的开发效率，所以凡事都用两面性，我们应该秉承辩证的态度，熟悉的方法尝试用，陌生的方法谨慎用。
以上就是Mybatis-Plus可能导致死锁的问题分析及解决办法的详细内容，更多关于Mybatis-Plus死锁的资料请关注脚本之家其它相关文章！
相关文章
今天小编就为大家分享一篇关于Java多线程工具篇BlockingQueue的详解，小编觉得内容挺不错的，现在分享给大家，具有很好的参考价值，需要的朋友一起跟随小编来看看吧2019-03-03
前面的文章给大家介绍 Spring 的重试机制的时候有提到过 Spring 有很多 @Enable 开头的注解，平时在使用的时候也没有注意过为什么会有这些注解，今天就给大家介绍一下2022-09-09
spring cloud config 配置中心快速实现过程解析
这篇文章主要介绍了spring cloud config 配置中心快速实现过程解析,文中通过示例代码介绍的非常详细，对大家的学习或者工作具有一定的参考学习价值,需要的朋友可以参考下2019-08-08
这篇文章主要介绍了Java判断是否为闰年的方法示例,本文直接给出示例代码,并讲解了判断原理,需要的朋友可以参考下2015-06-06
这篇文章主要介绍了Java常用的八种排序算法及代码实现,在Java的时候，对于排序的应用需要熟练的掌握，这样才能够确保Java学习时候能够有扎实的基础能力。那Java有哪些排序算法呢？本文小编就来详细说说Java经典的8种排序算法,需要的朋友可以参考一下2021-12-12
idea创建的idea项目时springframework出现红色的原因和解决方法
当使用 IntelliJ IDEA 创建 Spring Framework 项目时,springframework 出现红色可能是因为相关的 Spring Framework 依赖没有正确加载或项目的配置有问题,本文给大家介绍了一些常见的原因和解决方法,需要的朋友可以参考下2023-09-09
这篇文章主要介绍了详解Spring Boot 项目启动时执行特定方法，Springboot给我们提供了两种“开机启动”某些方法的方式：ApplicationRunner和CommandLineRunner。感兴趣的小伙伴们可以参考一下2018-06-06
这篇文章主要介绍了Java中的默认方法,包括继承和调用等Java入门学习中的基础知识,需要的朋友可以参考下2015-07-07
这篇文章主要介绍了Activiti如何启动流程并使流程前进,文中通过示例代码介绍的非常详细，对大家的学习或者工作具有一定的参考学习价值,需要的朋友可以参考下2020-03-03
这篇文章主要介绍了java中以DES的方式实现对称加密并提供密钥的实例的相关资料,这里提供实例帮助大家学习理解这部分知识，需要的朋友可以参考下2017-08-08
最新评论