高并发领取优惠卷加锁的坑！（事务边界问题/事务失效问题）

在一个对优惠价领取的场景中有以下步骤：

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

为避免超卖问题，我们对其进行加锁，用户限领数量判断是针对单个用户的，因此锁的范围不需要是整个方法，**只要锁定某个用户即可。**并且同步代码块的锁指定为用户id，那么同一个用户并发操作时会被锁定，不同用户互相没有影响，整体效率也是可以接受的。

   public void checkAndCreateUserCoupon(Long userId, Coupon coupon,Long serialNum) {
     
        synchronized (userId.toString()){
            Integer count = this.lambdaQuery()
                    .eq(UserCoupon::getUserId, userId)
                    .eq(UserCoupon::getCouponId, coupon.getId())
                    .count();
            if(count!=null&&count>=coupon.getUserLimit()){
                throw new BadRequestException("已达到领取上限");
            }
            couponMapper.incrIssueNum(coupon.getId());//采用这种方式，考虑并发控制，后期仍需修改
            //3.生成用户卷
            saveUserCoupon(userId,coupon);

            if(serialNum!=null){
                //修改兑换码的状态
                exchangeCodeService.lambdaUpdate()
                        .eq(ExchangeCode::getId,serialNum)
                        .set(ExchangeCode::getStatus, ExchangeCodeStatus.USED)
                        .set(ExchangeCode::getUserId,userId)
                        .update();
            }
        }


    }

这里有个坑，我们测试会发现锁并没有生效，为什么呢？

答案是用了不同的锁。

我们期望同一个用户用同一把锁，那就要去锁对象必须是同一个。但是我们刚才的锁是userId.toString();

userId是Long类型，其中toString方法源码如下：

可以看到，这里竟然采用的是new String()的方式。

也就是说，哪怕是同一个用户，其id是一样，但toString()得到的也是多个不同对象！也就是多把不同的锁！

怎么解决呢？

解决方案

String类中提供了一个intern()方法：

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

因此，我们这样改造：

事务边界问题

经过同步锁的改造，理论上用户限领数量判断的逻辑应该已经是解决了。

不过，经过测试后，发现问题依然存在，用户还是会超领。这又是怎么回事呢？

分析原因

其实这次的问题并不是由于锁导致的，而是由于事务的隔离导致。

要知道，整个领券发放是加了事务的：

注：刚刚说的那个方法，是这个方法中的子方法。

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

整体业务流程是这样的：

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

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

假如用户限领数量为1，当前用户没有领过券。但是这个人写了一个抢券程序，用自己的账号并发的来访问我们。

假设此时有两个线程并行执行这段逻辑：

• 线程1开启事务，然后获取锁成功；线程2开启事务，但是获取锁失败，被阻塞

• 线程1执行业务，由于没领过，所有业务都能正常执行，不再赘述

• 线程1释放锁。此时线程2立刻获取锁成功，开始执行业务：

  • 线程2统计用户已领取数量。由于线程1尚未提交事务，此时线程2读取不到未提交数据。因此认为当前用户没有领券。
  • 判断限领数量通过，于是也新增一条券
  • 安全问题发生了！

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

  这其实就是事务边界和锁边界的问题。

3.3.2.解决方案

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

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

具体代码如下：

// 。。。略
@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接口中：

import com.baomidou.mybatisplus.extension.service.IService;
import com.tianji.promotion.domain.po.UserCoupon;

import java.util.List;

/**
 * <p>
 * 用户领取优惠券的记录，是真正使用的优惠券信息 服务类
 * </p>
 *
 * @author 虎哥
 */
public interface IUserCouponService extends IService<UserCoupon> {
    void receiveCoupon(Long couponId);

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

}

总结

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

事务失效问题

虽然解决了并发安全问题，但其实我们的改造却埋下了另一个隐患。一起测试一下。

我们在领券业务的最后故意抛出一个异常：

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

分析原因

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

事务方法非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;
 }

非事务方法调用事务方法

有这样一段代码：

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

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

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

事务方法的异常被捕获了

示例：

 @Service
 public class OrderService {

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

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

 }

在这段代码中，reduceStock方法内部直接捕获了Exception类型的异常，也就是说方法执行过程中即便出现了异常也不会向外抛出。

而Spring的事务管理就是要感知业务方法的异常，当捕获到异常后才会回滚事务。

现在事务被捕获，就会导致Spring无法感知事务异常，自然不会回滚，事务就失效了。

事务异常类型不对

示例代码：

 
@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)

事务传播行为不对

原理：Spring 事务传播的底层实现主要依赖于 AOP（面向切面编程）和事务管理器。具体来说，Spring 使用代理模式，在方法调用前后插入事务管理逻辑。通过切面拦截方法调用，Spring 根据配置的传播行为（如 REQUIRES_NEW、REQUIRED 等）决定如何处理当前事务。例如，如果当前存在事务，REQUIRED 会加入该事务；而 REQUIRES_NEW 会暂停当前事务，创建一个新事务。最终，Spring 通过 PlatformTransactionManager 接口与底层事务管理框架（如 JDBC、JPA）进行交互，以管理事务的提交和回滚。

比如：

 
@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是一个独立事务。

所以，一定要慎用传播行为，注意外部事务与内部事务之间的关系。

没有被Spring管理

示例代码：

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

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

解决方案

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

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

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

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

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

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

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

1）引入AspectJ依赖：

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

2）暴露代理对象

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

3）使用代理对象

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

问题解决。

原文地址：https://blog.csdn.net/weixin_61558375/article/details/142715561

免责声明：本站文章内容转载自网络资源，如本站内容侵犯了原著者的合法权益，可联系本站删除。更多内容请关注自学内容网（zxcms.com）！