一套学会并发安全、锁失效、事务边界、事务失效

一、并发安全场景

发放优惠券在多线程压测时出现超卖。

问题：使用jmeter对接口进行并发测试发现多次都是超卖9张，这是为什么？

回答：其实这与Tomcat有关，tomcat的默认最大线程数是200，默认最小空闲线程数是10。所以在最后一次时，会超出9个。

这里采用的是先查询，再判断，再更新的方案，而以上三步操作并不具备原子性。单线程的情况下确实没有问题。但如果是多线程并发运行，如果N个线程同时去查询（N大于剩余库存），此时大概率查询到的库存是充足的，然后判断库存自然没问题。最后一起更新库存，自然就会超卖。总结一下就是多线程并行执行，多行代码操作共享资源，但不具备原子性。

解决方案

针对并发安全问题，我们一定知道的就是加锁来保证线程安全了。不过加锁的方式有很多。宏观上分为两大类。乐观锁和悲观锁。乐观锁执行的前提一定是建立在数据库的锁行的特性。数据库锁行就是悲观锁的一种。

悲观锁是一种独占和排他的锁机制，保守地认为数据会被其他事务修改，所以在整个数据处理过程中将数据处于锁定状态。

乐观锁是一种较为乐观的并发控制方法，假设多用户并发的不会产生安全问题，因此无需独占和锁定资源。但在更新数据前，会先检查是否有其他线程修改了该数据，如果有，则认为可能有风险，会放弃修改操作。

• 悲观锁认为安全问题一定会发生，所以直接独占资源。结果就是多个线程会串行执行被保护的代码。

  • 优点：安全性非常高

  • 缺点：性能较差

• 乐观锁则认为安全问题不一定发生，所以不独占资源。结果就是允许多线程并行执行。乐观锁采用CAS（Compare And Set）思想，在更新数据前先判断数据与我之前查询到的是否一致，不一致则证明有其它线程也在更新。为了避免出现安全问题，放弃本次更新或者重新尝试一次。

  • 优点：性能好、安全性也好

  • 缺点：并发较高时，可能出现更新成功率较低的问题（并行的N个线程只会有1个成功）

  • 会出现aba问题，（三个线程执行，线程1的锁把字符a修改为b，线程2把锁由b改为a，线程3以为a还是原来的a这时候就会出现问题，但是一般我们都有自增整数来当乐观锁）

但是针对乐观锁更新成功率低的问题有一个常用的改进方案：

将原先判断相等的条件改为小于，这样只要issue_num小于total_num，不管有多少线程来执行，都会成功。SQL如下

UPDATE coupon SET issue_num = issue_num + 1 WHERE id = 1 AND issue_num < total_num

二、锁失效问题

现在代码还是三步走，查询数据库，判断是否超出领取数量，给用户新增优惠券，这段代码没有加锁，不具备原子性，如果多线程并发访问，肯定会出现安全问题。

Integer count = lambdaQuery()
                .eq(UserCoupon::getUserId, userId)
                .eq(UserCoupon::getCouponId, coupon.getId())
                .count();
        if (count == null) {
            count = 0;
        }
        if (coupon.getUserLimit() <= count) {
            throw new BizIllegalException("超出限领数量");
        }
        // 6.优惠券数量加1
        int update = couponMapper.increseIssueNum(coupon.getId());
        if (update == 0) {
            //乐观锁生效
            throw new BizIllegalException("锁生效库存不足");
        }
        // 7.生成用户券
        UserCoupon userCoupon = new UserCoupon();
        userCoupon.setUserId(userId);
        userCoupon.setCouponId(coupon.getId());
        userCoupon.setStatus(UserCouponStatus.UNUSED);
        if (coupon.getTermDays() != null && coupon.getTermDays() > 0) {
            userCoupon.setTermBeginTime(LocalDateTime.now());
            userCoupon.setTermEndTime(LocalDateTime.now().plusDays(coupon.getTermDays()));
        } else {
            //指定时间领取
            userCoupon.setTermBeginTime(coupon.getTermBeginTime());
            userCoupon.setTermEndTime(coupon.getTermEndTime());
        }
        save(userCoupon);

 分析现在不能使用乐观锁，因为乐观锁常用在更新，而且这里用户和优惠券的关系并不具备唯一性，因此新增时无法基于乐观锁做判断。所以这里使用Synchronized或者 Lock。

使用Synchronized就要想到我们应该锁住哪个对象，这里分析业务是单人领取优惠券，所以可以锁住useId。

但是测试发现并发问题还是存在。为什么锁失效了！！没有生效呢 ？

这是因为我们的userId用toString()转字符时得到的也是不同的对象。

 解决方法也简单锁对象用 userId.toString().intern()。两个字符串equals的结果为true，那么intern就能保证得到的结果用 ==判断也是true，原理就是获取字符串字面值对应到常量池中的字符串常量。因此只要两个字符串一样，intern()返回的一定是同一个对象。

经过同步锁的改造，理论上用户限领数量判断的逻辑应该已经是解决了。经过测试后，发现问题依然存在，用户还是会超领。什么情况？？

三、事务边界

分析原因，是由于事务的隔离导致。现在是在方法上注解形式开启的事务

整体业务流程是这样的：

• 开启事务

• 获取锁

• 统计用户已领券的数量

• 判断是否超出限领数量

• 如果没超，新增一条用户券

• 释放锁

• 提交事务

想象一下场景：

线程1开启事务拿到锁，此时线程2开启事务，但是获取所失败，阻塞等待。

线程1执行业务，执行完成，刚释放锁。此时线程2立刻获得锁成功，开始执行业务。

线程2统计用户领取数量，此时线程1未提交事务，此时线程2读不到线程1修改的数据，所以认为当前还可以操作。这就是事务边界问题。

解决方案很简单，就是调整边界：

• 业务开始前，先获取锁，再开启事务

• 业务结束后：先提交事务，再释放锁

在事务和锁并行存在时，一定要考虑事务和锁的边界问题。由于事务的隔离级别问题，可能会导致不同事务之间数据不可见，往往会产生一些不可预期的现象。

四、事务失效问题

虽然解决了并发安全问题，但其实改造却埋下了另一个隐患。测试一下，在领券业务的最后故意抛出一个异常：

经过测试，发现虽然抛出了异常，但是库存、用户券都没有回滚！事务失效了！

分析原因：

首先统一知道的一点是，事务本身不会失效，失效的是@Transactional注解。而注解依赖于动态代理，在service中this走的是当前对象而不是proxy代理对象。所以解决方案就有两种方式，既然你注解失效，那我就编码开启事务。另一种思想，当前方法走的是this，那我想办法拿到代理对象不就好了。

OK先说常见的事务失效的原因，接下来我们就逐一分析一些常见的原因：

（1）事务方法非public修饰

由于Spring的事务是基于AOP的方式结合动态代理来实现的。因此事务方法一定要是public的，这样才能便于被Spring做事务的代理和增强。

（2）非事务方法调用事务方法

@Service
public class OrderService {
    
    
    public void createOrder(){
        // ... 准备订单数据
        
        // 生成订单并扣减库存
        insertOrderAndReduceStock();
    }
    
    @Transactional
    public void insertOrderAndReduceStock(){
        // 生成订单
        insertOrder();
        // 扣减库存
        reduceStock();
    }
}

这种是最常见的原因了，

insertOrderAndReduceStock方法是一个事务方法，肯定会被Spring事务管理。Spring会给OrderService类生成一个动态代理对象，对insertOrderAndReduceStock方法做增加，实现事务效果。但是现在createOrder方法是一个非事务方法，在其中调用了insertOrderAndReduceStock方法，这个调用其实隐含了一个this.的前缀。也就是说，这里相当于是直接调用原始的OrderService中的普通方法，而非被Spring代理对象的代理方法。那事务肯定就失效了！

（3）事务方法的异常被捕获了

 @Service
 public class OrderService {

    @Transactional
    public void createOrder(){
        // ... 准备订单数据
        // 生成订单
        insertOrder();
        // 扣减库存
        reduceStock();
    }

    private void reduceStock() {
        try {
            // ...扣库存
        } catch (Exception e) {
            // 处理异常
        }
    }

 }

reduceStock方法内部直接捕获了Exception类型的异常，也就是说方法执行过程中即便出现了异常也不会向外抛出。而Spring的事务管理就是要感知业务方法的异常，当捕获到异常后才会回滚事务。现在事务被捕获，就会导致Spring无法感知事务异常，自然不会回滚，事务就失效了。

（4）事务异常类型不对

@Service
 public class OrderService {

    @Transactional(rollbackFor = RuntimeException.class)
    public void createOrder() throws IOException {
        // ... 准备订单数据
        
        // 生成订单
        insertOrder();
        // 扣减库存
        reduceStock();

        throw new IOException();
    }
 }

Spring的事务管理默认感知的异常类型是RuntimeException，当事务方法内部抛出了一个IOException时，不会被Spring捕获，因此就不会触发事务回滚，事务就失效了。所以要捕获Exception.class。

（5）事务传播行为不对

@Service
 public class OrderService {
    @Transactional
    public void createOrder(){
        // 生成订单
        insertOrder();
        // 扣减库存
        reduceStock();
        throw new RuntimeException("业务异常");
    }
    @Transactional
    public void insertOrder() {
    }
    @Transactional(propagation = Propagation.REQUIRES_NEW)
    public void reduceStock() {
    }
 }

在这段代码中事务的入口是createOrder()方法，会开启一个事务。在createOrder()方法内部又调用了insertOrder()方法和reduceStock()方法。这两个都是事务方法。但是reduceStock()方法的事务传播行为是REQUIRES_NEW，这会导致在进入reduceStock()方法时会创建一个新的事务 ；insertOrder()则是默认，因此会与createOrder()合并事务。所以当createOrder()方法抛出异常时只会导致insertOrder()方法回滚，而不会导致reduceStock方法回滚，因为reduceStock是一个独立事务。

（6）没有被Spring管理

低级错误，比如Service类没有添加@Service注解，因此就没有被Spring管理。你在方法上添加的@Transactional注解根本不会有人帮你动态代理，事务自然失效。

一开始分析了从两方面解决事务失效问题（再强调是注解失效，并不是真正的事务失效）来说一下两种解决方案。

方案一想办法获取代理对象：

1）我们可以借助AspectJ来实现。引入AspectJ依赖：

<!--aspecj-->
<dependency>
    <groupId>org.aspectj</groupId>
    <artifactId>aspectjweaver</artifactId>
</dependency>

2）暴露代理对象

在启动类上添加注解，暴露代理对象：

3）使用代理对象

最后，改造领取优惠券的代码，把方法抽取到接口中去，给Spring管理。获取代理对象来调用事务方法：

 方案二使用编程式事务：

使用编程式事务的好处就是，灵活想象场景一段很长的代码块，没必要整体开启事务的时候，编程式事务就凸显出来了。直接上代码。

synchronized (userId.toString().intern()){
            checkAndSave(coupon, null);
            //IUserCouponService userCouponService = (IUserCouponService) AopContext.currentProxy();
            //userCouponService.checkAndSaveCoupon(coupon,null);
            //使用“编程式事务
            transactionTemplate.executeWithoutResult(action->{
                try{
                    this.checkAndSave(coupon,null);
                }catch (Exception e){
                    //要回滚
                    action.setRollbackOnly();
                    throw e;
                }
            });
        }