乐观锁与悲观锁详解：不同冲突场景选型指南

本文深入剖析了乐观锁与悲观锁的核心原理、适用边界及典型陷阱，直击高并发场景下数据一致性保障的关键痛点：在单机JVM内操作轻量级临界资源时，synchronized或ReentrantLock比数据库版本号更高效可靠；而SELECT ... FOR UPDATE的真实行为高度依赖事务隔离级别、索引命中和唯一性条件，稍有疏忽就会引发超卖或锁失效；乐观锁的UPDATE返回0不是失败而是明确的数据变更信号，必须重读最新状态、限制重试次数并剥离副作用逻辑；AtomicInteger的CAS虽是JVM内优雅的乐观实现，却受限于单变量原子性与ABA问题。真正决定锁成败的，从来不是锁本身，而是能否精准感知“数据是否已被他人修改”——这需要贯穿数据库ROW_COUNT、Java返回值、HTTP幂等机制的统一校验意识。

什么时候该用 synchronized 而不是版本号更新？

当你在单机 JVM 内做临界资源保护（比如共享计数器、本地缓存刷新），且操作粒度小、耗时短、不涉及数据库交互时，synchronized 或 ReentrantLock 是更直接的选择。它不需要改表结构、不依赖 SQL 返回行数判断、也不会因重试导致业务逻辑重复执行。

常见错误现象：UPDATE user SET balance = balance - 100 WHERE id = 1 AND version = 12 影响行为 0，但 Java 层没检查就认为扣款成功；或者在高并发下反复重试造成 CPU 暴涨、请求堆积。

• 适用场景：账户余额本地扣减、订单状态机切换（内存中完成）、配置热加载的原子替换
• 不适用场景：跨服务调用、长事务（比如含 HTTP 外部调用）、需要强一致读的报表生成
• 性能影响：锁竞争激烈时，线程阻塞排队，吞吐量下降明显；但无网络/SQL 解析开销

MySQL 中 SELECT ... FOR UPDATE 的真实行为边界

SELECT ... FOR UPDATE 不是“给某条记录上把锁就完事了”，它的生效依赖事务隔离级别、索引命中情况、是否为唯一条件——漏掉任一环，就可能升级成表锁或根本没锁住。

常见错误现象：执行 SELECT * FROM order WHERE status = 'pending' FOR UPDATE 却发现其他事务仍能插入新 pending 订单；或者并发下单时多个线程都查到同一条未锁住的记录，导致超卖。

• 必须走索引：否则 InnoDB 会退化为临键锁（Next-Key Lock），锁住整个范围
• 事务要显式开启：不能在自动提交模式下使用，否则语句执行完立即释放锁
• 锁只在事务结束（COMMIT 或 ROLLBACK）时释放，不是语句执行完就释放
• 若查询条件不唯一（如 WHERE category = 'book'），可能锁住多行甚至间隙，影响并发写入

用 version 字段实现乐观锁时，为什么 UPDATE 返回 0 就得重试？

因为这不是“失败”，而是“数据已变”的明确信号。数据库层面的 WHERE version = ? 条件不成立，说明在你读取之后、提交之前，有别的事务抢先更新了这条记录，并把 version 加了 1。此时你的计算基础已经失效，继续覆盖会丢数据。

典型陷阱：把重试逻辑写在 DAO 层最外层，却没控制最大重试次数；或在重试前没重新 SELECT 最新数据（包括最新 version 和业务字段），导致第二次更新还是基于过期快照。

• 必须重读：每次重试前都要重新 SELECT id, balance, version FROM account WHERE id = ?
• 限制重试次数：一般 3–5 次足够，再失败应降级为抛异常或转人工干预
• 避免业务逻辑重复执行：如扣款操作含日志、消息发送等副作用，需提取纯计算逻辑，重试时只跑更新部分
• 注意时钟漂移：如果用 update_time 替代 version，分布式节点时间不同步会导致校验失效

Java 里 AtomicInteger.compareAndSet() 是怎么模拟乐观锁的？

它底层调用的是 CPU 的 CAS（Compare-And-Swap）指令，一次完成“读值 → 比较 → 写新值”三个动作的原子性，不依赖操作系统锁。和数据库版本号机制本质一致：先读当前值（相当于读 version），更新时比对是否仍是原值，是则写入并返回 true，否则返回 false。

容易被忽略的点：CAS 只保证单个变量的原子更新，无法原子地更新多个字段。比如想同时更新 balance 和 version，用两个 AtomicInteger 无法保证二者同步成功。

• 适合场景：计数器、开关标记、简单状态位（如 isProcessing）
• ABA 问题存在：值从 A→B→A，CAS 会误认为没变；Java 提供 AtomicStampedReference 带版本戳解决
• 不能替代数据库一致性：JVM 进程内有效，跨实例、跨服务不适用
• 高争用下自旋成本高：线程反复尝试 CAS，可能比加锁更耗 CPU

真正难的从来不是选乐观还是悲观，而是判断「这个操作到底有没有被别人动过」——数据库里看 ROW_COUNT()，Java 里看 compareAndSet() 返回值，HTTP 调用里得靠幂等 token 或状态机校验。漏掉这一环，锁就形同虚设。

好了，本文到此结束，带大家了解了《乐观锁与悲观锁详解：不同冲突场景选型指南》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多文章知识！