MyBatisPlus乐观锁控制并发生成避免资源冲突

MyBatisPlus 乐观锁控制并发：如何优雅避免资源冲突

在电商大促的深夜，服务器监控突然报警——订单量激增的同时，库存数字却出现了负值。排查日志发现，多个线程几乎在同一毫秒读取到“剩余1件”的库存信息，随后各自执行扣减操作，最终导致超卖。这不是代码逻辑错误，而是典型的并发写入冲突问题。

面对这种高并发场景下的数据安全挑战，我们往往有两种选择：要么让所有请求排队等待（悲观锁），牺牲性能换一致性；要么相信“大多数人不会同时修改同一数据”，只在提交时做一次校验（乐观锁）。显然，在追求高吞吐的现代系统中，后者更具吸引力。

MyBatisPlus 提供的乐观锁支持，正是这样一种“轻量级防护盾”。它不需要复杂的分布式协调机制，也不依赖额外中间件，仅通过一个版本字段和一条 SQL 条件，就能有效防止脏写与覆盖更新。

设想你正在开发一个商品库存管理模块。用户点击“购买”后，系统会先查询当前库存，判断是否足够，然后执行扣减。这个看似简单的流程，在并发环境下却暗藏风险：

Product product = productMapper.selectById(1001); if (product.getStock() > 0) { product.setStock(product.getStock() - 1); productMapper.updateById(product); // 危险！ }

如果两个请求同时进入这段代码，它们都会读取到stock=1，都判断为“有库存”，然后先后执行更新。结果就是库存从1变成0，再变成-1——典型的超卖。

要解决这个问题，传统做法是加数据库行锁：

SELECT * FROM t_product WHERE id = 1001 FOR UPDATE;

这确实能保证安全，但代价高昂：所有后续请求必须排队等待前一个事务结束。在高并发下，响应时间飙升，数据库连接池可能迅速耗尽。

而乐观锁换了一种思路：我不阻塞别人，但我要求你更新时证明“你看到的数据还是最新的”。

实现方式很简单——给表加一个version字段：

ALTER TABLE t_product ADD COLUMN version INT DEFAULT 1;

每次更新时，不仅要改数据，还要带上原始版本号作为条件：

UPDATE t_product SET stock = stock - 1, version = version + 1 WHERE id = 1001 AND version = 1;

这条语句的妙处在于它的原子性：数据库会一次性完成“比对版本 + 更新数据”的动作。如果此时已有其他事务将version改为2，那么这条更新将影响0行，程序即可感知冲突并作出反应。

MyBatisPlus 正是基于这一原理，封装了完整的乐观锁能力。开发者只需在实体类中标注@Version注解：

@Data @TableName("t_product") public class Product { private Long id; private String name; private Integer stock; @Version private Integer version; }

并在配置类中注册拦截器：

@Configuration @MapperScan("com.example.mapper") public class MyBatisPlusConfig { @Bean public OptimisticLockerInterceptor optimisticLockerInterceptor() { return new OptimisticLockerInterceptor(); } }

从此以后，任何调用updateById()的操作，都会被自动增强为带版本条件的更新语句。你不再需要手动拼接AND version = ?，也无需在业务层反复写版本比对逻辑——这一切都由框架透明完成。

但这并不意味着可以高枕无忧。实际使用中仍有不少细节值得推敲。

比如重试策略的设计。当一次更新因版本冲突失败后，是否应该立即重试？如果连续失败三次呢？盲目重试可能导致雪崩效应，尤其在流量高峰期间。合理的做法是设置有限重试次数，并结合指数退避：

public boolean deductStock(Long productId, int count) { int maxRetries = 3; for (int i = 0; i < maxRetries; i++) { try { Product product = productMapper.selectById(productId); if (product.getStock() < count) { throw new RuntimeException("库存不足"); } product.setStock(product.getStock() - count); int rows = productMapper.updateById(product); if (rows > 0) { log.info("库存扣减成功，当前版本: {}", product.getVersion()); return true; } // 冲突发生，准备重试 if (i < maxRetries - 1) { try { Thread.sleep((long) Math.pow(2, i) * 100); // 指数退避 } catch (InterruptedException e) { Thread.currentThread().interrupt(); break; } } } catch (Exception e) { log.warn("第{}次尝试失败: {}", i + 1, e.getMessage()); } } throw new RuntimeException("操作过于频繁，请稍后再试"); }

这样的设计既提升了最终成功率，又避免了对数据库造成持续冲击。

再来看一个更典型的场景：秒杀系统。假设某商品限量100件，瞬间涌入上万请求。即使前端做了按钮置灰、验证码等限制，仍有大量请求落到服务端。此时若直接依赖数据库乐观锁处理全部竞争，失败率可能高达90%以上，造成大量无效查询和连接消耗。

更优的做法是分层设防：

1. 前置缓存预减库存：用 Redis 原子操作DECR预先扣除库存，只有成功才允许进入数据库环节；
2. 异步落库：将成功抢购的记录投递到消息队列，由消费者异步创建订单、持久化库存变更；
3. 数据库乐观锁兜底：对于必须同步返回结果的场景，仍启用 MyBatisPlus 乐观锁作为最后一道防线。

如此一来，真正打到数据库的请求已被大幅削减，系统整体稳定性显著提升。

当然，乐观锁也有其适用边界。它最适合读多写少、冲突概率低的场景。如果你的应用存在高频并发更新（例如多人协作文档编辑），那么乐观锁的失败率会急剧上升，反而降低效率。此时应考虑引入分布式锁或状态机等更强控机制。

此外还需注意一些技术细节：

• version字段建议使用INT UNSIGNED类型，初始值设为1，便于追踪调试；
• 不支持批量更新方法（如updateBatchById）中的版本校验，需自行拆解为单条更新；
• 所有对该记录的修改都必须走 MyBatisPlus 的更新接口，否则可能绕过版本检查；
• 可为version字段添加普通索引以加速 WHERE 条件匹配，但在主键查询为主的场景下收益有限。

从架构角度看，乐观锁的价值不仅在于技术实现本身，更体现在它所倡导的无侵入式并发控制理念。在一个微服务遍布的系统中，不同服务实例独立运行，无法共享内存锁。而基于数据库的版本机制天然具备全局一致性，无需额外协调服务，非常适合分布式环境。

当多个订单服务实例同时尝试更新同一个商品库存时，它们各自读取数据、计算新值，最后通过带有版本条件的 SQL 提交变更。谁先提交谁成功，其余自动失败。整个过程无需跨节点通信，扩展性极强。

我们还可以通过监控手段进一步优化体验。例如记录版本冲突的日志频率，设置告警阈值。一旦发现某商品的更新失败率异常升高，可能是遭遇恶意刷单或流量突增，可及时触发限流或扩容策略。

总结来说，MyBatisPlus 的乐观锁不是银弹，但它是一把锋利的小刀，精准地切开了高并发与数据一致性的矛盾点。它让我们能够在不显著牺牲性能的前提下，守住数据安全的底线。

在真实的生产环境中，很少有单一技术能独挑大梁。真正稳健的系统，往往是多种机制协同作用的结果：Redis 用于缓存与预减，消息队列实现削峰填谷，限流组件保护系统不过载，而 MyBatisPlus 乐观锁则默默守护着数据库的最后一公里。

掌握这项技术的意义，不只是学会了一个注解的用法，更是理解了如何在复杂场景下做出权衡与取舍——何时该乐观，何时该悲观；何时该重试，何时该拒绝。这才是工程师真正的功力所在。