记一次@Transactional和Synchronized使用时的那点事~

前言：

想起写这篇文章主要是在写业务代码时突然发现的一点问题。

业务步骤：

1、查找A表中的数量，根据数量生成批次号，插入A表中。
2、插入A表的数据之后，再执行其它相关业务。

先给大家看下我的第一版代码

注：本文中出现的皆为伪代码！

@Transactional(rollbackFor = Exception.class)
public void functionA() {
  synchronized(this) {
    Integer maxNum = userMapper.selectMaxCount();
    User user = new User();  
    user.setBatch(maxNum);
    userMapper.insert(user);
  }
  if(true) {
  // 这里是处理其它业务逻辑的代码
  }
  if(true) {
  // 这里是处理其它业务逻辑的代码
  }
}

这段代码乍一看没问题，其实对事物不是很了解的已经看到问题所在了。

虽然加锁可以解决batch的重复性问题，但是！

在user插入之后，我们还要去处理其他的业务。这里的业务是并没有在synchronized代码块里面的。

当线程T1执行完加锁代码块之后，线程T2又进来运行加锁的代码块。但是此时T1的事务还没有进行提交，T2读取到的最大数量和T1读取到的是同一个最大数量。那么就出现batch重复的问题了。

这里虽然在没有并发量的情况下，用户是不会出现batch重复的情况的。但是在并发量大的情况下。就比如在synchronized代码之后加上一个Thread.sleep(1000);那么就可以马上复现出batch重复的问题，就像这样。

@Transactional(rollbackFor = Exception.class)
public void functionA() {
  synchronized(this) {
    Integer maxNum = userMapper.selectMaxCount();
    User user = new User();  
    user.setBatch(maxNum);
    userMapper.insert(user);
  }
  Thread.sleep(1000);
  if(true) {
  // 这里是处理其它业务逻辑的代码
  }
  if(true) {
  // 这里是处理其它业务逻辑的代码
  }
}

那么这种问题我们应该怎么解决呢？有的小伙伴就会想到把锁的范围加大，直接锁整个方法。

@Transactional(rollbackFor = Exception.class)
public synchronized void functionA() {
  Integer maxNum = userMapper.selectMaxCount();
  User user = new User();  
  user.setBatch(maxNum);
  userMapper.insert(user);
  if(true) {
  // 这里是处理其它业务逻辑的代码
  }
  if(true) {
  // 这里是处理其它业务逻辑的代码
  }
}

这样锁住整个方法之后，是不是就没问题了呢？

其实并不是，为什么呢？

因为，我们的事物@Transactional注解是要在synchronized之前加在代码块上的。

想一下，当我们的线程A执行完代码，并且释放了锁，还没有提交当前事务。

线程B刚好又进来获取锁，但是此时线程A还没有提交事务。那么还是会出现batch重复的问题。

因此，又进行了代码的改进：

class userServiceImpl {
  @Autowired
  private UserService userService;
  @Resource
  private UserMapper userMapper;
  
  public synchronized void functionB() {
    userService.functionA();
  }
  
  @Transactional(rollbackFor = Exception.class, 
                 propagation = Propagation.REQUIRES_NEW)
  @Override
  public void functionA() {
    Integer maxNum = userMapper.selectMaxCount();
    User user = new User();  
    user.setBatch(maxNum);
    userMapper.insert(user);
    if(true) {
    // 这里是处理其它业务逻辑的代码
    }
    if(true) {
    // 这里是处理其它业务逻辑的代码
    }
  }
}

可以看到，我在第三版方案上，用了functionB调用了functionA，在functionB加锁，functionA加事务。这样就可以使锁的粒度大于当前事务的粒度，从而达到真正的线程安全。

这里有几个需要注意的点给大家说下：

1、调用本类加@Transactional的方法时，要使用一个AOP对象来进行代理，获取到代理对象之后@Trasactional才会正常生效，否则是不生效的。

2、synchronized要比事务的粒度要大，否则还是会出现重复读的现象。

3、被调用的A为什么要使用 REQUIRES_NEW的隔离级别呢？ 因为这样就可以实现锁的粒度大于事务的粒度啦。

以上的情况是基于数据库隔离级别为可重复读的基础上进行操作的。其他的就由小伙伴们再进行发掘吧~

感兴趣的小伙伴可以看我公众号看更多学习资料哦~

原文地址: https://mp.weixin.qq.com/s?__biz=Mzg5MTU3MTgyOQ==&mid=2247483691&idx=1&sn=e2e62bf1b6a67ed4a3ef0c18044c983a&chksm=cfca1a31f8bd9327ebd8390113515ab74974d97d376c15b240866611e0decb1477cc190b4fa7&token=105039798&lang=zh_CN#rd