乐观锁不能直接替代悲观锁，关键在于根据读写比例和冲突概率重构协作方式：从“先锁再干”变为“先干再验”，通过版本号或cas实现无锁更新，适合读多写少、冲突低的场景。
直接用乐观锁替代悲观锁，关键不是“换锁”，而是根据读写比例和冲突概率，把原本粗粒度、全程加锁的操作，改成细粒度、只在提交时校验的无锁协作方式。它不靠阻塞等待，而靠快速验证+重试来避免锁开销。
核心思路：从“先锁再干”变成“先干再验”
悲观锁（如 synchronized、ReentrantLock）一进来就抢锁，其他线程只能排队；乐观锁则默认没人改数据，你直接读、计算、准备更新，最后一步才比对“我读的时候的值/版本”是否还有效——有效就写入，无效就重来。
- 适合场景：读远多于写（比如商品详情页浏览 vs 库存扣减）、单次操作快、冲突概率低（如用户资料修改频率不高）
- 不适合强行替换的场景：高频写入（如秒杀下单）、长事务、必须强一致且不允许重试的业务逻辑
- 替换不是删掉 synchronized 就完事，而是要重构数据模型和更新逻辑，比如加 version 字段或用原子类
两种主流实现方式及对应代码要点
1. 数据库层：版本号（Version）机制
在表中增加 int 类型的 version 字段，每次更新都带条件：
UPDATE order SET status = ?, version = version + 1 WHERE id = ? AND version = ?
Java 中用 MyBatis 或 JPA 可自动处理：JPA 加 @Version 注解，MyBatis 在 XML 中手写 WHERE 条件。执行后检查 updateCount == 1，为 0 则说明已被他人更新，需重新查最新数据再试。
2. JVM 层：CAS 原子操作
用 java.util.concurrent.atomic 包下的类，比如：
-
AtomicInteger.compareAndSet(expected, updated)：成功返回 true，失败不抛异常，由你决定是否重试 -
AtomicStampedReference解决 ABA 问题（加版本戳），适合需要严格顺序判断的场景 - 自定义对象可封装为
AtomicReference<yourdata></yourdata>，配合compareAndSet(old, new)实现对象级乐观更新
进阶技巧：StampedLock 的乐观读模式
当读操作极频繁、写操作极少时，StampedLock 提供了比 ReentrantReadWriteLock 更轻量的读路径：
- 先调
tryOptimisticRead()获取一个戳记（stamp），直接读字段 - 再调
validate(stamp)检查期间是否有写操作发生 - 若未被修改，直接返回结果；若被修改，再走标准的
readLock()保证一致性
这种方式让绝大多数读请求完全不加锁、不阻塞、不参与锁队列，显著降低读线程调度开销。
注意事项：别忽略重试逻辑和边界控制
乐观锁不是“免死金牌”，它把冲突处理从“系统阻塞”转移到“应用层重试”，所以必须主动管理：
- 重试次数要设上限（比如 3～5 次），避免无限循环拖垮 CPU
- 重试前建议加小延时（如
Thread.sleep(1)或LockSupport.parkNanos），缓解竞争 - 对业务敏感的操作（如支付扣款），重试前需确认状态是否已变更，防止重复执行
- 注意 ABA 问题：值变回原样 ≠ 没人动过，必要时用带版本戳的原子引用
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
