慎用，Mybatis-Plus这个方法可能导致死锁

A同学在生产环境使用了Mybatis-Plus提供的 com.baomidou.mybatisplus.extension.service.IService#saveOrUpdate(T, com.baomidou.mybatisplus.core.conditions.Wrapper) 方法（以下简称B方法），并发场景下，数据库报了如下错误,,两个事务互相等待对方持有的锁，导致互相阻塞，从而导致死锁。,MySQL会向左找第一个比当前索引值小的值，向右找第一个比当前索引值大 的值（没有则为正无穷），将此区间锁住，从而阻止其他事务在此区间插入数据。,与Record lock组合成Next-key lock，在可重复读这种隔离级别下一起工作避免幻读。,理论上一款开源的框架，经过了多年打磨，提供的方法不应该造成如此严重的错误，但理论仅仅是理论上，事实就是发生了死锁，于是我们开始了一轮深度排查。首先我们从这个方法的源码入手，源码如下：,从源码上看此方法就没有按套路出牌，正常逻辑应该是首先执行查询，存在则修改，不存在则新增，但此方法上来就执行了修改。我们就猜想是不是MySQL在修改时增加了什么锁导致了死锁，于是我们找到了DBA获取了最新的死锁日志，即执行show engine innodb status，我们发现了两项关键信息如下：,简单翻译一下，就是事务一在获取插入意向锁时，需要等待间隙锁（事务二添加）释放，同时事务二在获取插入意向锁时，也在等待间隙锁释放（事务一添加），（本文不讨论MySQL在修改与插入时添加的锁，我们把修改时添加间隙锁，插入时获取插入意向锁为已知条件）那我们回到B方法，并发场景下，是不是就很大几率会满足事务一和事务二相互等待对方持有的间隙锁，从而导致死锁。,现在我们理论有了，我们现在用真实数据来验证此场景。,根据lock_type和lock_mode我们可以很清晰的看到锁类型是行锁，锁模式是间隙锁。,到这里，细心的同学就会发现，诶，你这上面故意造了一个间隙，并且让两个事务分别在对方的间隙中插入数据，太刻意了，生产环境基本上不会有这种场景，是的，生产环境怎么会有这种场景呢，上面的数据只是为了让大家直观的看到间隙锁的死锁过程，接下来那我们再来一组数据，我们简称验证二。,验证二完整的复现了线上死锁的过程，也就是事务一先执行了更新语句，事务二在同一时刻也执行了更新语句，然后事务一发现没有更新到就去执行主键查询语句，发现确实没有，所以执行了插入语句，但是插入要先获取插入意向锁，在获取插入意向锁的时候发现这个间隙已经被事务二加锁了，所以事务一开始等待事务二释放间隙锁，同理，事务二也执行上述操作，最终导致事务一与事务二互相等待对方释放间隙锁，最终导致死锁。,验证二还说明了一个问题，就是间隙锁加锁是非互斥的，也就是事务一对间隙A加锁后，事务二依然可以给间隙A加锁。,PS：以上方法仅适用于当前业务场景确实不关心幻读的问题。,建议自己编写一个saveOrUpdate方法，当然也可以直接采用Mybatis-Plus提供的saveOrUpdate方法，但是根据源码发现，会有很多额外的反射操作，并且还添加了事务，大家都知道，MySQL单表操作完全不需要开事务，会增加额外的开销。,在验证二中两个事务修改的都是不存在的行，都能加间隙锁成功，那如果两个事务修改的是存在的行，MySQL还会加间隙锁吗？或者说把间隙锁从锁间隙降为锁一行？带着疑问，我们执行以下数据验证，我们还是使用验证一的表和数据。,根据lock_type和lock_mode我们看到事务一和二加的锁变成了Record Lock，并没有再添加间隙锁，根据以上数据验证MySQL在修改存在的数据时会给行加上Record Lock，与间隙锁不同的是该锁是互斥的，即不同的事务不能同时对同一行记录添加Record Lock。,虽然Mybatis-Plus提供的这个方法可能会造成死锁，但是依然不可否认它是一款非常优秀的增强框架，其提供的lambda写法在日常工作中极大的提高了我们的开发效率，所以凡事都有两面性，我们应该秉承辩证的态度，熟悉的方法尝试用，陌生的方法谨慎用。,以上就是我们在生产环境间隙锁死锁分析的全过程，如果大家觉得本文让你对间隙锁，以及间隙锁死锁有一点的了解，别忘记一键三连，多多支持转转技术，转转技术在未来将会给大家带来更多的生产实践与探索。