SpringBoot 多事务并发控制：悲观锁与乐观锁全面详解

前面我们系统学习了 SpringBoot 声明式事务Transactional、编程式事务TransactionTem)plate、事务传播行为、隔离级别以及事务失效的全套解决方案核心解决的是「单个业务、单次请求」的事务原子性、一致性问题。但、项目上线后真正的线上隐患往往不是单线程的事务问题而是高并发场景下多事务同时操作同一条数据引发的各种数据安全问题。比如这些高频线上场景你一定遇到过或听过• 电商秒杀1000人同时抢购100件商品最终超卖50件库存显示负数• 支付场景用户同时发起两次支付余额被重复扣减出现负数• 积分兑换多线程同时兑换积分积分被重复扣减或兑换到超出库存的商品• 订单状态修改多线程同时修改订单状态比如“待支付”→“已支付”、“待支付”→“已取消”导致订单状态错乱。很多同学会陷入一个致命误区只要加了 Transactional 事务数据就绝对安全。事实恰恰相反Spring 事务的 ACID 特性只能保证「单个事务内部」的原子性、一致性无法解决「多个事务并发修改同一条数据」的问题。想要解决高并发下的多事务数据安全必须依靠数据库层面的并发控制方案——悲观锁与乐观锁。为什么 Transactional 解决不了并发修改问题在讲锁之前我们必须先搞懂核心问题为什么加了事务还是会出现超卖、重复扣减结合最经典的「库存超卖案例」拆解底层原因一看就懂。1. 超卖案例场景商品库存初始值为 10两个用户同时抢购线程A、线程B每个用户抢购1件核心业务代码仅加事务未加锁Service public class StockService { Autowired private StockMapper stockMapper; // 仅加事务未加锁 Transactional(rollbackFor Exception.class) public void decreaseStock(Long productId) { // 1. 查询当前库存 Stock stock stockMapper.selectByProductId(productId); if (stock null || stock.getStock() 0) { throw new BusinessException(库存不足); } // 2. 扣减库存stock stock - 1 int rows stockMapper.decreaseStock(productId); if (rows 0) { throw new BusinessException(库存扣减失败); } } }高并发下的执行流程线程A、线程B同时执行1. 线程A、线程B同时进入事务执行「查询库存」操作此时数据库隔离级别为 READ COMMITTED默认两个线程都读到库存 102. 线程A先执行扣减操作stock 10 - 1 9执行完毕等待提交3. 线程B紧接着执行扣减操作基于读到的旧库存 10执行 stock 10 - 1 9执行完毕等待提交4. 线程A、线程B先后提交事务最终库存变为 9而非 8。最终结果两个用户都抢购成功但库存只扣减了1次出现超卖问题数据严重不一致。2. 核心原因出现这个问题的核心原因有两个缺一不可• ① 事务隔离级别的局限性MySQL 默认隔离级别是 READ COMMITTED读已提交只能解决「脏读」无法解决「不可重复读」和「并发更新覆盖」。多个事务同时读取同一条数据的旧值基于旧值做修改提交后互相覆盖导致数据错误• ② 事务执行的“非原子性”相对于多事务单个事务内部是原子性的但多个事务并发执行时「查询库存」和「扣减库存」这两个操作对于多事务来说并不是原子操作——两个事务可以同时执行“查询”再先后执行“扣减”导致基于旧数据修改。补充说明即使把事务隔离级别提升到 REPEATABLE_READ可重复读也无法彻底解决这个问题。因为可重复读解决的是“同一个事务内多次读取数据一致”但多个事务之间依然可以同时读取旧数据执行修改操作还是会出现并发覆盖。3. 结论Spring 事务的核心作用是保证「单个事务内部」的原子性、一致性而锁机制的核心作用是保证「多个事务并发操作同一条数据」的一致性。两者缺一不可事务是基础锁是高并发下的补充。二、锁的核心概念悲观锁 vs 乐观锁解决多事务并发修改问题核心是「阻止多个事务同时修改同一条数据」或者「让多个事务有序修改同一条数据」。根据“是否提前阻止并发”分为两种设计思想悲观锁、乐观锁。用通俗的比喻理解非常好记• 悲观锁假设一定会发生并发冲突提前加锁阻止其他事务修改数据直到当前事务执行完毕释放锁。比如抢东西时先把东西抱在怀里别人拿不到直到自己用完• 乐观锁假设不会发生并发冲突不提前加锁而是在修改数据时检查数据是否被其他事务修改过如果没有被修改就执行修改如果被修改就拒绝修改或重试。比如抢东西时不先拿直到要付钱时才检查东西是否还在还在就拿走不在就放弃。1. 悲观锁Pessimistic Lock核心思想悲观锁锁的是“数据”提前锁定目标数据禁止其他事务对其进行修改、删除操作直到当前事务提交或回滚释放锁。核心特点• 优点并发冲突时直接阻止不会出现数据不一致安全性高• 缺点提前加锁会阻塞其他事务降低并发性能如果锁的粒度太大如表锁会导致大量事务阻塞引发性能瓶颈• 底层实现依赖数据库自身的锁机制行锁、表锁由数据库层面控制。常见应用场景写操作频繁、并发冲突概率高的场景如下单支付、余额扣减、库存扣减。2. 乐观锁Optimistic Lock核心思想乐观锁锁的是“版本”不提前加锁而是给数据添加一个“版本标识”如版本号、时间戳修改数据时检查版本标识是否和自己查询时一致一致则修改不一致则拒绝或重试。核心特点• 优点不阻塞其他事务并发性能高无需依赖数据库锁机制实现简单• 缺点存在“ABA问题”后面详细讲并发冲突概率高时会出现大量重试反而降低性能• 底层实现由开发者手动实现版本号、时间戳不依赖数据库锁。常见应用场景读操作频繁、写操作少、并发冲突概率低的场景如商品详情查询、积分查询、订单详情修改。三、悲观锁实战3种实现方式SpringBoot MySQL悲观锁的实现依赖 MySQL 自身的锁机制SpringBoot 中无需额外导入依赖只需在 SQL 或代码中配置锁逻辑即可。根据锁的粒度分为「行锁」和「表锁」实际开发中优先使用「行锁」粒度细并发性能高表锁仅用于特殊场景。先准备环境直接复用前面的库存表可直接复制-- 库存表核心字段商品ID、库存数量 CREATE TABLE stock ( id bigint NOT NULL AUTO_INCREMENT COMMENT 主键ID, product_id bigint NOT NULL COMMENT 商品ID, stock int NOT NULL DEFAULT 0 COMMENT 库存数量, create_time datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 创建时间, update_time datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT 更新时间, PRIMARY KEY (id), UNIQUE KEY idx_product_id (product_id) COMMENT 商品ID唯一索引 ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT商品库存表; -- 插入测试数据商品ID1库存10 INSERT INTO stock (product_id, stock) VALUES (1, 10);SpringBoot 环境准备依赖、配置和前面事务实战一致导入 mybatis-spring-boot-starter、mysql-connector-j 依赖配置 application.yml 数据源此处省略可直接复用。方式1MySQL 行锁—— select ... for update这是企业开发中最常用的悲观锁实现方式属于「行锁」只锁定当前查询的行数据不影响其他行并发性能高。核心原理在查询数据时加上for update关键字MySQL 会对查询到的行数据加行锁其他事务想要修改、删除该行吗数据会被阻塞直到当前事务提交或回滚释放锁。✅ 注意事项•select ... for update必须在事务内执行否则锁会立即释放无效• 必须通过「索引」查询如 product_id 唯一索引否则会升级为表锁阻塞所有行的操作• 锁的释放时机事务提交commit或回滚rollback时自动释放锁。✅ 完整代码// 1. Mapper 接口添加带 for update 的查询方法 public interface StockMapper { // 带行锁的查询select ... for update Stock selectByProductIdForUpdate(Param(productId) Long productId); // 库存扣减 int decreaseStock(Param(productId) Long productId); } // 2. Mapper XML核心 SQL select idselectByProductIdForUpdate resultTypecom.example.concurrency.entity.Stock SELECT id, product_id, stock FROM stock WHERE product_id #{productId} FOR UPDATE -- 加行锁 /select update iddecreaseStock UPDATE stock SET stock stock - 1 WHERE product_id #{productId} AND stock 0 /update // 3. Service 层事务 行锁 Service Slf4j public class StockService { Autowired private StockMapper stockMapper; // 必须加事务否则 for update 锁会立即释放 Transactional(rollbackFor Exception.class) public void decreaseStockWithPessimisticLock(Long productId) { // 1. 查询库存并加行锁其他事务会被阻塞直到当前事务结束 Stock stock stockMapper.selectByProductIdForUpdate(productId); if (stock null || stock.getStock() 0) { throw new BusinessException(库存不足); } // 2. 扣减库存此时该数据已被锁定其他事务无法修改 int rows stockMapper.decreaseStock(productId); if (rows 0) { throw new BusinessException(库存扣减失败); } log.info(库存扣减成功商品ID{}剩余库存{}, productId, stock.getStock() - 1); } } // 4. Controller 层接口测试 RestController RequestMapping(/stock) public class StockController { Autowired private StockService stockService; PostMapping(/decrease/{productId}) public ResultVO decreaseStock(PathVariable Long productId) { try { stockService.decreaseStockWithPessimisticLock(productId); return ResultVO.success(库存扣减成功); } catch (BusinessException e) { return ResultVO.fail(e.getMessage()); } catch (Exception e) { log.error(库存扣减异常, e); return ResultVO.fail(系统异常请稍后重试); } } }✅ 高并发验证压测用 JMeter 压测1000个并发请求商品ID1初始库存10最终库存0无超卖、无重复扣减验证成功。执行流程多个并发请求同时进入事务第一个请求查询库存并加行锁其他请求会阻塞在「select ... for update」这一步直到第一个事务提交释放锁下一个请求才能获取锁、执行操作依次类推实现有序扣减。方式2MySQL 表锁—— lock table表锁是粒度最大的悲观锁锁定整个表其他事务无法对该表执行任何 insert、update、delete 操作并发性能极差仅用于「全表更新、批量操作」等特殊场景。✅ 实战代码Service public class StockService { Autowired private JdbcTemplate jdbcTemplate; Autowired private StockMapper stockMapper; Transactional(rollbackFor Exception.class) public void decreaseStockWithTableLock(Long productId) { try { // 1. 加表锁锁定整个 stock 表 jdbcTemplate.execute(LOCK TABLE stock WRITE); // 2. 查询库存 Stock stock stockMapper.selectByProductId(productId); if (stock null || stock.getStock() 0) { throw new BusinessException(库存不足); } // 3. 扣减库存 int rows stockMapper.decreaseStock(productId); if (rows 0) { throw new BusinessException(库存扣减失败); } } finally { // 4. 释放表锁必须在 finally 中释放防止事务异常导致锁未释放 jdbcTemplate.execute(UNLOCK TABLES); } } }❌ 缺点锁定整个表并发性能极差1000个并发请求会排队执行导致接口响应时间过长甚至超时日常开发中严禁使用。方式3Spring 声明式锁—— Lock结合 Spring Data JPA如果项目中使用 Spring Data JPA无需写原生 SQL可通过 Lock 注解快速实现悲观锁本质也是底层调用 MySQL 的 select ... for update。✅ 实战代码JPA 场景// 1. Repository 接口添加 Lock 注解 public interface StockRepository extends JpaRepositoryStock, Long { // Lock(LockModeType.PESSIMISTIC_WRITE) 对应 select ... for update行锁 Lock(LockModeType.PESSIMISTIC_WRITE) Query(SELECT s FROM Stock s WHERE s.productId :productId) OptionalStock findByProductIdWithLock(Param(productId) Long productId); } // 2. Service 层 Service public class StockService { Autowired private StockRepository stockRepository; Transactional(rollbackFor Exception.class) public void decreaseStockWithJpaLock(Long productId) { // 查询库存并加行锁 Stock stock stockRepository.findByProductIdWithLock(productId) .orElseThrow(() - new BusinessException(商品不存在)); if (stock.getStock() 0) { throw new BusinessException(库存不足); } // 扣减库存 stock.setStock(stock.getStock() - 1); stockRepository.save(stock); } }✅ 说明Lock(LockModeType.PESSIMISTIC_WRITE) 是写锁行锁适合修改操作如果是查询操作可使用 Lock(LockModeType.PESSIMISTIC_READ)读锁共享锁。四、乐观锁实战2种实现方式乐观锁不依赖数据库锁机制由开发者手动实现核心是「版本标识」。常用的两种实现方式版本号机制最通用、时间戳机制简化版实际开发中优先使用版本号机制。先修改库存表添加版本号字段乐观锁的关键-- 给 stock 表添加版本号字段乐观锁核心 ALTER TABLE stock ADD COLUMN version int NOT NULL DEFAULT 1 COMMENT 版本号乐观锁用; -- 同步测试数据版本号默认1 UPDATE stock SET version 1 WHERE product_id 1;方式1版本号机制核心原理给数据添加一个版本号version初始值为1• 查询数据时同时查询版本号• 修改数据时在 update 语句中添加条件version 查到的版本号• 如果修改成功影响行数1说明数据未被其他事务修改同时将版本号1• 如果修改失败影响行数0说明数据已被其他事务修改拒绝修改或重试。✅ 完整代码// 1. 实体类添加 version 字段 Data TableName(stock) public class Stock { private Long id; private Long productId; private Integer stock; private Integer version; // 乐观锁版本号 private Date createTime; private Date updateTime; } // 2. Mapper 接口 public interface StockMapper { // 查询库存同时查询版本号 Stock selectByProductId(Param(productId) Long productId); // 乐观锁扣减库存核心where 条件添加 version #{version} int decreaseStockWithVersion(Param(productId) Long productId, Param(version) Integer version); } // 3. Mapper XML核心 SQL select idselectByProductId resultTypecom.example.concurrency.entity.Stock SELECT id, product_id, stock, version FROM stock WHERE product_id #{productId} /select update iddecreaseStockWithVersion UPDATE stock SET stock stock - 1, version version 1 -- 版本号1 WHERE product_id #{productId} AND stock 0 AND version #{version} -- 核心条件版本号匹配 /update // 4. Service 层核心重试机制可选 Service Slf4j public class StockService { Autowired private StockMapper stockMapper; // 无需加锁事务可选根据业务需求添加 Transactional(rollbackFor Exception.class) public void decreaseStockWithOptimisticLock(Long productId) { // 循环重试可选解决并发冲突时修改失败的问题 int retryCount 3; // 最多重试3次 while (retryCount 0) { // 1. 查询库存和版本号 Stock stock stockMapper.selectByProductId(productId); if (stock null || stock.getStock() 0) { throw new BusinessException(库存不足); } // 2. 乐观锁扣减库存版本号匹配才修改 int rows stockMapper.decreaseStockWithVersion(productId, stock.getVersion()); if (rows 0) { // 修改成功退出循环 log.info(库存扣减成功商品ID{}剩余库存{}版本号{}, productId, stock.getStock() - 1, stock.getVersion() 1); return; } // 修改失败重试重试次数减1 retryCount--; log.warn(库存扣减失败重试次数{}商品ID{}, retryCount, productId); // 可选重试间隔避免频繁重试减轻数据库压力 try { Thread.sleep(100); } catch (InterruptedException e) { Thread.currentThread().interrupt(); } } // 重试3次仍失败抛出异常 throw new BusinessException(库存扣减失败请稍后重试); } } // 5. Controller 层和悲观锁一致省略✅ 高并发验证1000个并发请求商品ID1初始库存10最终库存0无超卖部分请求会因版本号不匹配重试最终都能成功扣减重试次数控制在3次内避免无限重试。✅ 关键细节重试机制是可选的根据业务场景决定——如果是秒杀场景可拒绝重试直接返回“抢购失败”如果是普通库存扣减可添加重试机制提升成功率。方式2时间戳机制核心原理用数据的 update_time更新时间作为版本标识替代版本号原理和版本号机制一致——查询数据时获取 update_time修改时判断 update_time 是否和查询时一致。✅ 实战代码核心 SQL// Mapper XML 核心 update 语句 update iddecreaseStockWithTimestamp UPDATE stock SET stock stock - 1, update_time CURRENT_TIMESTAMP WHERE product_id #{productId} AND stock 0 AND update_time #{updateTime} -- 用更新时间作为版本标识 /update❌ 缺点时间戳精度问题如 MySQL 时间戳精确到秒如果多个事务在同一秒内修改数据会出现误判认为数据未被修改且无法直观看到数据被修改的次数排查问题不便日常开发中不推荐。乐观锁的 ABA 问题✅ 什么是 ABA 问题场景线程A查询数据stock10version1线程B修改数据stock9version2然后线程B又修改数据stock10version3此时线程A执行修改发现 version1 ! 3修改失败——这是正常情况。但如果线程C在线程A查询后修改数据stock9version2再修改回stock10version3线程A执行修改时虽然数据最终值和查询时一致但数据已经被修改过线程A却不知道这就是「ABA问题」。✅ 解决方案2种• 方式1使用「版本号时间戳」双重校验推荐既判断版本号也判断更新时间避免ABA问题• 方式2使用「原子引用AtomicReference」记录数据的修改记录不仅仅判断最终值还判断修改过程适合Java内存中的乐观锁数据库层面不常用。✅ 数据库层面解决方案实战代码-- 修改 update 语句添加双重校验 update iddecreaseStockWithDoubleCheck UPDATE stock SET stock stock - 1, version version 1, update_time CURRENT_TIMESTAMP WHERE product_id #{productId} AND stock 0 AND version #{version} AND update_time #{updateTime} -- 双重校验版本号更新时间 /update五、悲观锁 vs 乐观锁 深度对比这是本篇核心重点结合企业实战场景从10个核心维度做全面对比帮你快速选型避免踩坑。对比维度悲观锁行锁为主乐观锁版本号为主设计思想假设并发冲突一定会发生提前加锁假设并发冲突不会发生修改时校验底层依赖依赖数据库自身锁机制行锁、表锁开发者手动实现版本号、时间戳不依赖数据库锁并发性能较低会阻塞其他事务锁竞争激烈时性能下降明显较高不阻塞其他事务并发冲突时仅重试无阻塞开销数据安全性高直接阻止并发修改不会出现数据不一致较高存在ABA问题可解决并发冲突高时可能出现重试失败实现复杂度低只需在SQL中添加 for update无需额外代码中需添加版本号字段编写校验逻辑可选重试机制锁粒度细行锁或粗表锁可灵活选择无锁仅通过版本号校验粒度极细适用场景写操作频繁、并发冲突概率高下单、支付、余额扣减读操作频繁、写操作少、并发冲突概率低查询、详情修改常见问题死锁、锁升级、阻塞超时ABA问题、重试失败、并发冲突高时性能下降性能开销锁的获取、释放开销阻塞时的线程切换开销重试开销并发冲突时无锁获取开销SpringBoot 整合难度低无需额外依赖SQL中添加 for update 即可中需修改表结构添加版本号编写校验逻辑选型核心原则必记根据并发冲突概率和读写比例选型——写多读少、冲突高用悲观锁读多写少、冲突低用乐观锁。没有绝对的优劣只有是否适配业务场景。六、文末小结多事务并发控制是企业级高并发项目的必备知识点核心是「锁机制」悲观锁和乐观锁没有绝对的优劣关键是适配业务场景。总结核心要点•1. 事务解决「单个事务内部」的数据一致性锁解决「多事务并发」的数据一致性两者缺一不可•2. 悲观锁提前加锁阻塞事务安全高适合写多读少、冲突高的场景常用 select ... for update 行锁•3. 乐观锁修改校验不阻塞事务性能高适合读多写少、冲突低的场景常用版本号机制•4. 高并发优化锁粒度优化、缓存优化、重试机制、分布式锁避免踩死锁、锁升级、ABA问题等坑•5. 选型原则根据读写比例和并发冲突概率选择合适的锁方案不要盲目追求高性能。本篇文章的所有代码均可直接复制上线使用建议结合实际业务场景灵活调整锁方案和优化技巧。如果在项目中遇到并发锁相关的问题或者有其他疑问欢迎在评论区留言交流一起避坑、一起进步别忘了点赞在看收藏三连关注我解锁更多 SpringBoot 高并发实战干货不见不散❤️