day08-领取优惠券（高并发优化：超卖、锁失效、事务边界、事务失效）

由于优惠券的发放数量限制、每人限领数量限制，因此在领取优惠券的过程中必须判断优惠券的库存以及当前用户的领取数量。也就是避免出现超发现象，这跟电商中的库存超卖是处理是类似的。

通过今天的学习，希望大家可以达成下列目标：

• 掌握库存超卖问题的处理方案
• 熟悉并发安全问题的常见处理方案
• 理解锁失效、事务失效的常见原因及对应的解决方案

领券的过程中有大量的校验，这些校验逻辑在高并发的场景下很容易出现问题。因此，我们必须对领券功能做并发测试，看看是否会出现并发安全问题。

并发测试，比较常见的一种工具就是Jemeter了。

1 超卖问题

经过测试，确实出现了超卖（或超发）的现象，优惠只有100个库存，结果发放了109张券！！
那么，为什么出现了超卖的现象呢？

1.1 分析原因

现在我们对于优惠券库存的处理逻辑是这样的：

• 查询优惠券
• 判断库存是否充足（领取数量<总数量）
• 如果充足，更新优惠券已领取数量

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

总结一下，原因是：

• 多线程并行运行
• 多行代码操作共享资源，但不具备原子性

这就是典型的线程并发安全问题，相信大家都能想到解决方案吧。

1.2.解决方案

针对并发安全问题，最广为人知的解决方案就是加锁。不过，加锁的方式多种多样，大家熟悉的Synchronized、ReentrantLock只是其中最基础的锁。

我们今天先不讨论具体的锁的实现方式，而是讲讲加锁的思想。从实现思想上来说，锁可以分为两大类：

• 悲观锁
• 乐观锁

何为悲观锁？

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

何为乐观锁？

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

可见，悲观锁、乐观锁是对并发安全问题的处理态度不同：

• 悲观锁认为安全问题一定会发生，所以直接独占资源。结果就是多个线程会串行执行被保护的代码。
  • 优点：安全性非常高
  • 缺点：性能较差
• 乐观锁则认为安全问题不一定发生，所以不独占资源。结果就是允许多线程并行执行。但如果真的发生并发修改怎么办？？
  • 乐观锁采用CAS（Compare And Set）思想，在更新数据前先判断数据与我之前查询到的是否一致，不一致则证明有其它线程也在更新。为了避免出现安全问题，放弃本次更新或者重新尝试一次。

乐观锁听起来比较抽象，我们举个例子。

比如我们现在total_num为10，issue_num为9，也就是说还剩下1个库存了。现在有两个线程来执行修改操作。

• 线程1、线程2都查询数据，发现total_num为10，issue_num为9
• 线程1、线程2都判断库存是否充足，if(issue_num < total_num)，发现都成立了。
• 线程1和线程2都开始执行数据库写操作，更新issue_num。但是由于数据库的事务互斥，肯定有先有后。我们假设线程1先执行。按照乐观锁机制，在更新时要做数据检查（CAS），判断数据是否变化。因此SQL是这样：
  • UPDATE coupon SET issue_num = issue_num + 1 WHERE id = 1 AND issue_num = 9
    注意SQL语句结尾的AND issue_num = 9 , 这里的9就是之前查询的结果，这里就是校验是否变化，假如issue_num发生变化，此处不一致，肯定SQL就执行失败。当然线程1是第一个执行的，issue_num没有变化，所以这里会成功。因此issue_num的值+1，变为10
• 紧接着，线程2执行，因为线程2查询的时候issue_num是9，所以线程2执行相同SQL：
  • UPDATE coupon SET issue_num = issue_num + 1 WHERE id = 1 AND issue_num = 9
  • 但线程1已经将issue_num的值更新为10，线程2的这条SQL执行时where条件不成立，执行失败，乐观锁生效了。

以上就是乐观锁的工作原理，可以发现乐观锁：

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

不过，针对更新成功率低的问题，在优惠券库存这个业务中，有一个乐观锁的改进方案：
我们无需判断issue_num是否与原来一致，只要判断issue_num是否小于total_num即可。这样，只要issue_num小于total_num，不管有多少线程来执行，都会成功。

综上，我们最终的执行SQL是这样的：

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

1.3.解决超卖问题

首先，我们要修改com.tianji.promotion.mapper.CouponMapper中的更新库存的SQL语句：

需要注意的是，where条件不成立不会报错，而是更新失败，返回0. 因此，我们还应该对这个方法的返回值做判断，如果返回值是0，则应该抛出异常，触发回滚。

修改com.tianji.promotion.service.impl.UserCouponServiceImpl中的checkAndCreateUserCoupon方法：

1.4.总结

超卖这样的线程安全问题，解决方案有哪些？

• 悲观锁：添加同步锁，让线程串行执行
  • 优点：简单粗暴
  • 缺点：性能一般
• 乐观锁：不加锁，在更新时判断是否有其它线程在修改
  • 优点：性能好
  • 缺点：存在成功率低的问题

2.锁失效问题

其实，除了优惠券库存判断，领券时还有对于用户限领数量的判断：

可以看到，这部分逻辑也是按照三步走：

• 查询数据库
• 判断是否超出限领数量
• 新增用户券

这段代码没有加锁，不具备原子性，如果多线程并发访问，肯定会出现安全问题（一个人领多个卷的情况）。怎么办？是不是跟上节课一样，使用乐观锁解决？

显然不行，因为乐观锁常用在更新（基于数据库的某一个字段去处理），而且这里用户和优惠券的关系并不具备唯一性（一个用户可以领多份），因此新增时无法基于乐观锁做判断。

所以，这里只能采用悲观锁方案，也就是大家熟悉的Synchronized或者Lock.

2.1.锁对象问题

用户限领数量判断是针对单个用户的，因此锁的范围不需要是整个方法，只要锁定某个用户即可。所以这里建议采用Synchronized的代码块，而不是同步方法。
并且同步代码块的锁指定为用户id，那么同一个用户并发操作时会被锁定，不同用户互相没有影响，整体效率也是可以接受的。
代码如下：

经过测试，发现并发安全问题依然存在，锁没有生效！！！什么情况？

加了锁，但锁没生效，可能的原因是什么？答案是用了不同的锁。 userId的类型时Long的，其中在-128~127是在常量池中缓存的数，在这范围内，是同一个对象没问题，但是超过了这个范围就是不同的对象（比如128）。所以转换成字符串形式，使用了toString(),但是还是有问题。

我们期望同一个用户用同一把锁，那就要去锁对象必须是同一个。但是我们刚才的锁是userId.toString();
userId是Long类型，其中toString方法源码如下：

可以看到，这里竟然采用的是new String()的方式。
也就是说，哪怕是同一个用户，其id是一样，但toString()得到的也是多个不同对象！也就是多把不同的锁！

怎么解决呢？

2.2.解决方案

String类中提供了一个intern()方法：
只要两个字符串equals的结果为true，那么intern就能保证得到的结果用 ==判断也是true，其原理就是获取字符串字面值对应到常量池中的字符串常量。因此只要两个字符串一样，intern()返回的一定是同一个对象。（指向常量池中的字符串）

因此，我们这样改造：

3.事务边界问题

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

3.1.分析原因

其实这次的问题并不是由于锁导致的，而是由于事务的隔离导致。
要知道，整个领券方法是加了事务的：

而在方法内部，我们加锁，处理限领数量的判断。

整体业务流程是这样的：

• 开启事务
• 获取锁
• 统计用户已领券的数量
• 判断是否超出限领数量
• 如果没超，新增一条用户券
• 释放锁
• 提交事务

注意，这里是先开启事务，再获取锁；而业务执行完毕后，是先释放锁，再提交事务。

假如用户限领数量为1，当前用户没有领过券。但是这个人写了一个抢券程序，用自己的账号并发的来访问我们。
假设此时有两个线程并行执行这段逻辑：

• 线程1开启事务，然后获取锁成功；线程2开启事务，但是获取锁失败，被阻塞
• 线程1执行业务，由于没领过，所有业务都能正常执行，不再赘述
• 线程1释放锁。此时线程2立刻获取锁成功，开始执行业务：
  • 线程2统计用户已领取数量。由于线程1尚未提交事务，此时线程2读取不到未提交数据。因此认为当前用户没有领券。
  • 判断限领数量通过，于是也新增一条券
  • 安全问题发生了！

总结：由于锁过早释放，导致了事务尚未提交，判断出现错误，最终导致并发安全问题发生。
这其实就是事务边界和锁边界的问题。

3.2.解决方案

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

• 业务开始前，先获取锁，再开启事务
• 业务结束后：先提交事务，再释放锁

具体代码如下：

 // 4.校验并生成用户券
        synchronized(userId.toString().intern()){ // 这里加锁，这样锁在事务之外
            checkAndCreateUserCoupon(coupon, userId, null);
        }
    }

    @Transactional // 这里进事务，同时，事务方法一定要public修饰
    public void checkAndCreateUserCoupon(Coupon coupon, Long userId, Integer serialNum){
    }

完整代码：

// 。。。略
@Service
@RequiredArgsConstructor
public class UserCouponServiceImpl extends ServiceImpl<UserCouponMapper, UserCoupon> implements IUserCouponService {
    private final CouponMapper couponMapper;
    private final IExchangeCodeService codeService;
    @Override
    // @Transactional 此处的事务注解取消
    public void receiveCoupon(Long couponId) {
        // 1.查询优惠券
        Coupon coupon = couponMapper.selectById(couponId);
        if (coupon == null) {
            throw new BadRequestException("优惠券不存在");
        }
        // 2.校验发放时间
        LocalDateTime now = LocalDateTime.now();
        if (now.isBefore(coupon.getIssueBeginTime()) || now.isAfter(coupon.getIssueEndTime())) {
            throw new BadRequestException("优惠券发放已经结束或尚未开始");
        }
        // 3.校验库存
        if (coupon.getIssueNum() >= coupon.getTotalNum()) {
            throw new BadRequestException("优惠券库存不足");
        }
        Long userId = UserContext.getUser();
        // 4.校验并生成用户券
        synchronized(userId.toString().intern()){ // 这里加锁，这样锁在事务之外
            checkAndCreateUserCoupon(coupon, userId, null);
        }
    }

    @Transactional // 这里进事务，同时，事务方法一定要public修饰
    public void checkAndCreateUserCoupon(Coupon coupon, Long userId, Integer serialNum){
        // 1.校验每人限领数量
        // 1.1.统计当前用户对当前优惠券的已经领取的数量
        Integer count = lambdaQuery()
                .eq(UserCoupon::getUserId, userId)
                .eq(UserCoupon::getCouponId, coupon.getId())
                .count();
        // 1.2.校验限领数量
        if (count != null && count >= coupon.getUserLimit()) {
            throw new BadRequestException("超出领取数量");
        }
        // 2.更新优惠券的已经发放的数量 + 1
        int r = couponMapper.incrIssueNum(coupon.getId());
        if (r == 0) {
            throw new BizIllegalException("优惠券库存不足");
        }
        // 3.新增一个用户券
        saveUserCoupon(coupon, userId);
        // 4.更新兑换码状态
        if (serialNum != null) {
            codeService.lambdaUpdate()
                    .set(ExchangeCode::getUserId, userId)
                    .set(ExchangeCode::getStatus, ExchangeCodeStatus.USED)
                    .eq(ExchangeCode::getId, serialNum)
                    .update();
        }
    }
    
    
    private void saveUserCoupon(Coupon coupon, Long userId) {
        // 1.基本信息
        UserCoupon uc = new UserCoupon();
        uc.setUserId(userId);
        uc.setCouponId(coupon.getId());
        // 2.有效期信息
        LocalDateTime termBeginTime = coupon.getTermBeginTime();
        LocalDateTime termEndTime = coupon.getTermEndTime();
        if (termBeginTime == null) {
            termBeginTime = LocalDateTime.now();
            termEndTime = termBeginTime.plusDays(coupon.getTermDays());
        }
        uc.setTermBeginTime(termBeginTime);
        uc.setTermEndTime(termEndTime);
        // 3.保存
        save(uc);
    }
    // 。。。 略
}

由于事务方法需要public修饰，并且被spring管理。因此要把事务方法向上抽取到service接口中：

public interface IUserCouponService extends IService<UserCoupon> {
    void receiveCoupon(Long couponId);

    void checkAndCreateUserCoupon(Coupon coupon, Long userId, Integer serialNum);

}

3.3.总结

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

4.事务失效问题

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

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

4.1.分析原因

事务失效的原因有很多，接下来我们就逐一分析一些常见的原因：

4.1.1.事务方法非public修饰

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

而且，在Spring内部也会有一个 org.springframework.transaction.interceptor.AbstractFallbackTransactionAttributeSource类，去检查事务方法的修饰符：

@Nullable
 protected TransactionAttribute computeTransactionAttribute(
  Method method, @Nullable Class<?> targetClass) {
   // Don't allow non-public methods, as configured.
   if (allowPublicMethodsOnly() && 
  !Modifier.isPublic(method.getModifiers())) {
      return null;
   }

    // ... 略

   return null;
 }

所以，事务方法一定要被public修饰！

4.1.2 非事务方法调用事务方法

有这样一段代码：

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

可以看到，insertOrderAndReduceStock方法是一个事务方法，肯定会被Spring事务管理。Spring会给OrderService类生成一个动态代理对象，对insertOrderAndReduceStock方法做增加，实现事务效果。

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

4.1.3.事务方法的异常被捕获了

示例：

 @Service
 public class OrderService {

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

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

 }

在这段代码中，reduceStock方法内部直接捕获了Exception类型的异常，也就是说方法执行过程中即便出现了异常也不会向外抛出。
而Spring的事务管理就是要感知业务方法的异常，当捕获到异常后才会回滚事务。（意思是本来该Spring事务管理的异常被开发人员自己处理了）
现在事务被捕获，就会**导致Spring无法感知事务异常，**自然不会回滚，事务就失效了。

4.1.4.事务异常类型不对

示例代码：

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

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

因此，当我们的业务中会抛出RuntimeException以外的异常时，应该通过@Transactional注解中的rollbackFor属性来指定异常类型：
@Transactional(rollbackFor = Exception.class)

4.1.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是一个独立事务。
所以，一定要慎用传播行为，注意外部事务与内部事务之间的关系。

4.1.6.没有被Spring管理

示例代码：

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

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

4.2.解决方案

结合上节课的分析，大家应该能发现我们的事务失效的原因是什么了。

为了控制事务边界，我们改变了事务注解标记的位置，这就导致了非事务方法调用了事务方法。

怎么办？难道再把注解移回去？

这显然不合适，因为移回去就会导致并发安全问题。我们陷入了两难境地。

那么，有没有办法让这个事务再次生效呢？

答案是有的，既然事务失效的原因是方法内部调用走的是this，而不是代理对象。那我们只要想办法获取代理对象不就可以了嘛。

这里，我们可以借助AspectJ来实现。

1）引入AspectJ依赖：

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

2）暴露代理对象

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

3）使用代理对象
最后，改造领取优惠券的代码，获取代理对象来调用事务方法：