当前位置：首页 > news >正文

高并发环境下超发现象的详细分析，包含场景示例、影响分析及解决方案(悲观锁、乐观锁、分布式锁）

news 来源：原创 2025/9/17 6:36:29

以下是针对高并发环境下超发现象的详细分析，包含场景示例、影响分析及解决方案：

高并发下的超发详解

1. 超发现象定义

超发（Over-issuance）指在并发操作中，系统实际发放的资源（如商品库存）超过实际可用量。例如，用户下单时系统显示库存充足，但实际扣减后库存为负数，导致超发。

2. 超发现象的典型场景

场景示例：商品抢购

假设某商品库存为 100，在高并发环境下，多个用户同时发起购买请求，可能导致以下流程：

3. 超发现象的时间线分析（表格）

在这里插入图片描述
|

超发现象结果：

线程1和线程2在开始阶段都同时读入库存为1，但是在T3时刻线程1扣减库存后产品就没有库存了，线程2此时并不会感知线程1的这个操作，而是继续按自己原有的判断，按照库存为1扣减库存，这样就出现了T4时刻库存为−1，而T6时刻插入错误记录的超发现象在高并发的环境下，除了考虑超发的问题，还应该考虑性能问题，因为速度太慢会影响用户的体验。

4. 超发现象的影响

数据不一致：
- 库存显示与实际不符，导致用户收到订单但商品已售罄。
- 系统账目混乱，可能引发财务问题。
用户体验差：
- 用户支付后无法收到商品，引发投诉。
系统稳定性：
- 频繁的超发现象可能导致系统崩溃或数据损坏。

5. 超发的根源分析

超发现象的根本原因是 并发操作未保证原子性和一致性。具体原因如下：

读-修改-写操作的非原子性：
- 多个线程同时读取库存，各自计算后写回，导致覆盖。
缺乏锁机制：
- 未对共享资源（如库存）加锁，导致多个线程同时修改。
事务隔离级别不足：
- 默认的读已提交（Read Committed）隔离级别无法避免脏读或不可重复读。

6. 解决方案：悲观锁与乐观锁

6.1 悲观锁（Pessimistic Lock）

悲观锁是使用数据库内部的锁对记录进行加锁，从而使其他事务等待，以保证数据的一致性。但这样会造成过多的等待和事务上下文的切换，导致系统运行缓慢，因为使用悲观锁时资源只能被一个事务锁持有，所以悲观锁也被称为独占锁或者排他锁

原理：

通过数据库锁（如 SELECT FOR UPDATE）独占资源，阻塞其他事务，确保操作原子性。
在这里插入图片描述

实现步骤：

加锁查询：

SELECT * FROM product WHERE id = 1 FOR UPDATE;  -- 加锁查询库存

扣减库存：

UPDATE product SET stock = stock - 1 WHERE id = 1;

代码示例（Spring Boot + MyBatis）：

@Service
public class ProductService {@Autowiredprivate ProductMapper productMapper;@Transactional(rollbackFor = Exception.class)public boolean deductStockWithPessimisticLock(Long productId, Integer quantity) {// 1. 加锁查询库存Product product = productMapper.queryForUpdate(productId);if (product == null || product.getStock() < quantity) {throw new RuntimeException("库存不足");}// 2. 扣减库存（锁定期间数据一致）productMapper.deductStock(productId, quantity);return true;}
}// Mapper接口
public interface ProductMapper {// 悲观锁查询（锁定行）@Select("SELECT * FROM product WHERE id = #{id} FOR UPDATE")Product queryForUpdate(@Param("id") Long id);// 扣减库存@Update("UPDATE product SET stock = stock - #{quantity} WHERE id = #{id}")void deductStock(@Param("id") Long id, @Param("quantity") Integer quantity);
}

优点：

数据一致性强，避免超发。
实现简单，直接依赖数据库锁。

缺点：

阻塞导致吞吐量低，高并发下性能下降。
易引发死锁（如多个线程相互等待锁）。

6.2 乐观锁（Optimistic Lock）

乐观锁是一种不使用数据库锁的机制，不会造成线程的阻塞，而是采用多版本号机制来实现请求。但是，因为版本的冲突造成请求失败的概率剧增，所以这时往往需要通过重入机制降低请求失败的概率。不过，多次的重入会带来过多运行SQL语句的问题。为了克服这个问题，可以考虑使用按时间戳或者限定重入次数的办法。可，乐观锁是一个相对复杂的机制

—比较交换（compare and swap，CAS）

在这里插入图片描述

—比较交换（compare and swap，CAS）方案会引发一种ABA问题

在这里插入图片描述
在T2到T5时刻，线程1计算剩余商品总价格的时候，当前库存会被线程2修改，它是一个
A→B→A的过程，所以被形象地称为“ABA问题”。换句话说，线程1在计算剩余商品总价格时，当前库存是一个变化的值，这样就可能出现错误的计算。显然，表14-2所示的共享值回退导致了数据的不一致，为了克服这个问题，开发者引入了一些规则，典型的如增加版本号（version），并且规定：只要操作过程中修改共享值，无论业务是正常、回退还是异常，版本号只能递增，不能递减。使用这个规则重新执行数据库事务

使用版本号解决ABA问题

在这里插入图片描述
可以看出，由于版本号只能递增而不能递减，因此无论是线程2进行扣减库存还是回退商品，版本号都只会递增而不会递减，这样在T6时刻，线程1使用其保存的version旧值1与当前version值3进行比较，就会发现商品被修改过了，数据已经不可信，于是便取消业务。

加入版本号导致失败数量多，请求量大，对数据库造成压力，一般会考虑使用限制时间或者重入次数的办法，压制过多的SQL语句被运行。

因为加入了版本号的判断，所以大量的请求得到了失败的结果，而且这个失败率有点高。下面我们要处理这个问题。在上面的测试中，可以看到大量的请求更新失败。为了处理这个问题，乐观锁还可以引入重入机制，也就是一旦更新失败，就重新做一次，因此有时候也可以称乐观锁为可重入的锁。其原理是一旦发现版本号被更新，不结束请求，而是重新运行一次乐观锁流程，直至成功为止。但是流程的重入可能造成大量的SQL语句被运行。例如，原本一个请求需要运行3条SQL语句，如果需要重入4次才能成功，那么就会有十几条SQL语句被运行，在高并发场景下，会给数据库带来很大的压力。为了克服这个问题，一般会考虑使用限制时间或者重入次数的办法，压制过多的SQL语句被运行。

按时间戳重入的乐观锁测试

进入方法后则记录了开始时间，然后进入循环。在执行业务逻辑之前，先判断结束时间
（end）和开始时间（start）的时间戳。如果循环时间小于等于100 ms，则继续尝试；如果大于100 ms，则返回失败。在扣减库存的时候，如果扣减成功，则返回更新条数不为0；如果为0，则扣减失败，进入下一次循环，直至扣减成功或者超时

按时间戳限制重入的方法也有一个弊端，就是系统会因为自身的忙碌而大大减少重入的次数。因此有时候也会采用限定重入次数的机制来避免重试过多

但是按时间戳限制重入的方法也有一个弊端，就是系统会因为自身的忙碌而大大减少重入的次数。因此有时候也会采用限定重入次数的机制来避免重试过多的情况，不同的地方在于使用for循环限定了最多3次尝试。在实际的测试中可以发现，请求失败的次数也会大大降低

原理：

通过版本号（Version）或时间戳检测冲突，在提交时验证数据未被修改。若冲突则回滚并重试。

实现步骤：

读取数据：

SELECT * FROM product WHERE id = 1;  -- 读取库存和版本号

验证版本号：

UPDATE product 
SET stock = stock - 1, version = version + 1 
WHERE id = 1 AND version = #{currentVersion};  -- 带版本号校验的更新

代码示例（Spring Boot + MyBatis）：

@Service
public class ProductService {@Autowiredprivate ProductMapper productMapper;@Transactional(rollbackFor = Exception.class)public boolean deductStockWithOptimisticLock(Long productId,Integer quantity,int retryCount) {int retry = 0;while (retry < retryCount) {// 1. 获取当前库存和版本号Product product = productMapper.queryProduct(productId);if (product == null || product.getStock() < quantity) {throw new RuntimeException("库存不足");}// 2. 尝试扣减库存（带版本号校验）int affectedRows = productMapper.deductStockWithOptimisticLock(productId, quantity, product.getVersion());if (affectedRows > 0) {return true;}// 3. 版本冲突，重试retry++;try {Thread.sleep(10); // 避免频繁重试} catch (InterruptedException e) {Thread.currentThread().interrupt();}}throw new RuntimeException("库存扣减失败，版本冲突");}
}// Mapper接口
public interface ProductMapper {// 查询库存（不加锁）@Select("SELECT * FROM product WHERE id = #{id}")Product queryProduct(@Param("id") Long id);// 乐观锁扣减库存（带版本号校验）@Update("UPDATE product SET stock = stock - #{quantity}, version = version + 1 " +"WHERE id = #{id} AND version = #{version}")int deductStockWithOptimisticLock(@Param("id") Long id,@Param("quantity") Integer quantity,@Param("version") Integer version);
}

优点：

避免阻塞，高并发下吞吐量更高。
减少锁竞争，降低系统开销。

缺点：

需处理版本冲突，重试可能增加开销。
多次重试可能导致过多SQL语句执行。

7. 其他解决方案

7.1 分布式锁（如Redis）

通过Redis的SETNX命令实现分布式锁，确保跨节点资源操作的原子性。

7.2 预扣减策略

预扣减缓存：将库存预扣减到缓存（如Redis），再异步更新数据库。
优点：减少数据库压力，提升性能。
缺点：需处理缓存与数据库的最终一致性。

7.3 限流降级

通过熔断器（如Hystrix）、限流算法（如令牌桶）限制并发请求，避免系统过载。

8. 总结

场景	推荐方案	原因
高并发低冲突	乐观锁	减少锁竞争，提升吞吐量，版本冲突概率低时无需频繁重试。
高冲突且数据敏感	悲观锁	保证数据绝对一致性，适用于金融等对数据强一致要求高的场景。
混合场景	乐观锁+重试机制	结合版本号和有限次数的重试，在保证性能的同时降低冲突影响。

9. 关键代码注释说明

悲观锁代码关键点

SELECT FOR UPDATE：锁定记录，阻塞其他事务。
事务注解 @Transactional：确保查询和更新操作的原子性。

乐观锁代码关键点

版本号字段 version：记录数据修改次数。
重试机制：通过有限次数的重试降低版本冲突的影响。

通过以上方案，可以有效解决高并发下的超发现象，确保系统数据一致性与性能平衡。

高并发下的超发详解

1. 超发现象定义

2. 超发现象的典型场景

场景示例：商品抢购

3. 超发现象的时间线分析（表格）

4. 超发现象的影响

5. 超发的根源分析

6. 解决方案：悲观锁与乐观锁

6.1 悲观锁（Pessimistic Lock）

原理：

实现步骤：

代码示例（Spring Boot + MyBatis）：

优点：

缺点：

6.2 乐观锁（Optimistic Lock）

—比较交换（compare and swap，CAS）

—比较交换（compare and swap，CAS）方案会引发一种ABA问题

使用版本号解决ABA问题

加入版本号导致失败数量多，请求量大，对数据库造成压力，一般会考虑使用限制时间或者重入次数的办法，压制过多的SQL语句被运行。

按时间戳重入的乐观锁测试

按时间戳限制重入的方法也有一个弊端，就是系统会因为自身的忙碌而大大减少重入的次数。因此有时候也会采用限定重入次数的机制来避免重试过多

原理：

实现步骤：

代码示例（Spring Boot + MyBatis）：

优点：

缺点：

7. 其他解决方案

7.1 分布式锁（如Redis）

7.2 预扣减策略

7.3 限流降级

8. 总结

9. 关键代码注释说明

悲观锁代码关键点

乐观锁代码关键点

相关文章：