超卖等高并发秒杀场景的问题及解决方案

1. 超卖问题（多人秒杀）

1.1 原因

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

例：

1.2 解决方案

针对并发安全问题，最广为人知的解决方案就是加锁。
从实现思想上来说，锁可以分为两大类：

• 悲观锁
• 乐观锁

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

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

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

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

乐观锁：

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

1.3 总结

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

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

2. 锁失效问题（单人重复抢）

2.1 原因

使用Synchronized的代码块作为锁时，锁使用的是方法中的变量时，此时一般会通过tostring()方法将变量转为常量，但由于tostring的底层方法中使用的是：

这种new出来的对象并不相同，从而导致锁不相同，从而引发锁失效的问题。

2.2 解决方案

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

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

3. 事务边界问题（单人重复抢）

3.1 原因

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

3.2 解决方案

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

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

将加锁的部分抽取为一个方法，在方法上加@Transactional事务注解，在调用的方法中将抽取的方法放在锁内即可解决

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;
 }
1
2
3
4
5
6
7
8
9
10
11
12
13

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

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

@Service
public class OrderService {
    
    public void createOrder(){
        // ... 准备订单数据
        
        // 生成订单并扣减库存
        insertOrderAndReduceStock();
    }
    
    @Transactional
    public void insertOrderAndReduceStock(){
        // 生成订单
        insertOrder();
        // 扣减库存
        reduceStock();
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

可以看到，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) {
            // 处理异常
        }
    }

 }
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

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

4.1.4 事务异常类型不对

 
@Service
 public class OrderService {

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

        throw new IOException();
    }
 }
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

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

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

@Transactional(rollbackFor = Exception.class)
1

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() {
    }
 }
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

在示例代码中，事务的入口是createOrder()方法，会开启一个事务，可以成为外部事务。在createOrder()方法内部又调用了insertOrder()方法和reduceStock()方法。这两个都是事务方法。
不过，reduceStock()方法的事务传播行为是REQUIRES_NEW，这会导致在进入reduceStock()方法时会创建一个新的事务，可以成为子事务。insertOrder()则是默认，因此会与createOrder()合并事务。
因此，当createOrder方法最后抛出异常时，只会导致insertOrder方法回滚，而不会导致reduceStock方法回滚，因为reduceStock是一个独立事务。
所以，一定要慎用传播行为，注意外部事务与内部事务之间的关系。

4.1.6 没有被Spring管理

 
//  @Service
 public class OrderService {
    @Transactional
    public void createOrder(){
        // 生成订单
        insertOrder();
        // 扣减库存
        reduceStock();
        throw new RuntimeException("业务异常");
    }
    @Transactional
    public void insertOrder() {
    }
    @Transactional
    public void reduceStock() {
    }
 }
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

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