背景

最近解决了个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()
}