生产问题-死锁情况

情景回顾

最近发现生产环境出现死锁的情况，在这里以简单的例子向大家分享一下，希望能够帮助到大家掌握解决死锁的一个思路。

前置说明

• 数据库连接池配置

spring:
    hikari:
      auto-commit: true
      minimum-idle: 10
      maximum-pool-size: 20
      idle-timeout: 20000
      connection-timeout: 20000
      connection-test-query: select 1

• 日志信息：发现同一时间节点10:11:04 ～ 10:11:24发现有两个线程在执行相同的业务逻辑操作
  • 事务A：在时间节点 10:11:04 ～ 10:11:24 发生java.sql.SQLException: Connection is closed 执行业务失败
  • 事务B：在时间节点 10:11:04 ～ 10:11:24 执行业务成功

伪代码分析

	@Override
    @Transactional(rollbackFor = Exception.class)
    public Resp review(ReviewReq reviewReq) {
        List<Long> ids = reviewReq.getIds();
        for(Long id : ids) {
            RLockTemplate.lockGet("KEY:".concat(id), () -> {
                // 更新状态、额度 update 语句
                // update t_user set status = 'pass' where id = #{id}
                return true;
            });
        }
        return Resp.success();
    }

这段代码出现了如下问题：

• 如果ids的集合过多出现 大长事务 长事务在并发的情况下，导致数据数据库连接池被打满
• 会出现死锁问题，redis分布锁和mysql锁 竞争资源

并发死锁步骤分析

步骤	事务A	事务B
1	分布式锁：KEY1
2	update id为1的数据（占用事务）
3	分布式锁：KEY2
4	update id为2的数据
5		分布式锁：KEY1
6		update id为1的数据（数据库id为1的数据已经被事务A占用，发生锁等待）
7	分布式锁：KEY1（等待事务B的KEY1分布式锁）
8		锁等待，前面数据库连接配置超时是20秒，超过20秒报错java.sql.SQLException: Connection is closed ，主动释放KEY1分布式锁
9	获取KEY1分布式锁：正常执行业务

死锁总结

• 避免大长事务，降低资源消耗
• 事务开始到结束的时间内，避免做耗时的操作，比如网络请求、for循环等
• 一般情况下都是事务需要写在分布式锁里面