该用 synchronized 而不是版本号更新的情况是：单机 JVM 内保护临界资源（如共享计数器、本地缓存刷新），且操作粒度小、耗时短、不涉及数据库交互。
什么时候该用 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 或状态机校验。漏掉这一环，锁就形同虚设。
