事务代码中加synchronized锁引发的bug

背景

最近解决了个BUG,由于历史背景,在某一个产品里的用户中心有两套系统,两套系统还使用了两个不同的数据库,所以创建用户的时候会有一个新数据库到旧数据库同步的操作。

具体的流程是用户在页面注册了新用户,请求被新用户中心系统a处理,然后通过消息组件同步到用户中心系统b中,用户只要修改了用户的信息不论是手机号、年龄、姓名等等都会异步触发同步机制,一切听起来都很不合理中透露着合理。

BUG从现象上看是出现了一个用户在旧数据库中出现多条的情况。最烦查这种没有具体堆栈报错的bug,因为搞不好得捋一遍祖传的屎山代码。。。

代码分析

出现这种情况肯定是在接受消息的方法那边处理,因为消息组件难免出现重复发送的情况,一般都会在消费端做幂等处理。

@Transactional
public void consumer(String msg) {
    UserDTO userdto = JsonUtil.toObject(msg, UserDTO.class);
    // 一大堆屎山业务逻辑。。。。。
    synchronized(this) {
        //操作数据库读写
        usercenter.save()
    }
}

这里乍一看感觉没啥问题,多看两眼觉得有点奇怪怪的又说不上哪里怪,其实问题就出在了这里。要么说synchronized关键字要慎重使用,

理性分析一波,@Transactional是通过AOP的方式实现对数据库的事务管理,而synchronized代码块又是在一个事务内,就会出现第一个线程释放锁后但是事务还没来得及提交,第二个线程就进入同步代码块获取到未提交的数据库数据。有点类似脏读。

那怎么解决呢

解决方案

这好办,我直接套个方法不就得了,把锁提到方法外面

public synchronized consumer(String msg) {
    consumer(msg);
}

@Transactional
public void consumer(String msg) {
    UserDTO userdto = JsonUtil.toObject(msg, UserDTO.class);
    // 一些业务判断逻辑。。。。。
    //操作数据库读写
    usercenter.save()
}

这样又会出现另一个问题,你会发现事务失效了,同类内方法互调使用不了AOP包装后的事务方法。看起来一个很好改的小BUG,改起来还得细心点,不然解决一个旧BUG出来新BUG。

这里有三个思路吧,大家有好思路也可以提一下:

  1. 拆成两个类,保存用户一个类,synchronized方法放到另一个类
  2. 自己注入自己,使用AOP包装后的对象调用consumer方法
  3. 手动管理事务

这种老功能最怕乱改代码,所以尽量选择改动量最少的方法,最终使用第二种方法解决

@Autowire
UserServiceImpl userServiceImpl;

public synchronized consumerProxy(String msg) {
    userServiceImpl.consumer(msg);
}

@Transactional
public void consumer(String msg) {
    UserDTO userdto = JsonUtil.toObject(msg, UserDTO.class);
    // 一些业务判断逻辑。。。。。
    //操作数据库读写
    usercenter.save()
}
相关推荐
苏-言3 分钟前
Spring IOC实战指南:从零到一的构建过程
java·数据库·spring
Ljw...9 分钟前
索引(MySQL)
数据库·mysql·索引
菠萝咕噜肉i22 分钟前
超详细:Redis分布式锁
数据库·redis·分布式·缓存·分布式锁
长风清留扬25 分钟前
一篇文章了解何为 “大数据治理“ 理论与实践
大数据·数据库·面试·数据治理
OpsEye38 分钟前
MySQL 8.0.40版本自动升级异常的预警提示
数据库·mysql·数据库升级
Ljw...38 分钟前
表的增删改查(MySQL)
数据库·后端·mysql·表的增删查改
远歌已逝4 小时前
维护在线重做日志(二)
数据库·oracle
qq_433099405 小时前
Ubuntu20.04从零安装IsaacSim/IsaacLab
数据库
Dlwyz5 小时前
redis-击穿、穿透、雪崩
数据库·redis·缓存
工业甲酰苯胺7 小时前
Redis性能优化的18招
数据库·redis·性能优化