StampedLock锁模式切换需显式控制stamp值，仅支持乐观读→悲观读、写锁→悲观读的安全降级；禁止悲观读升级为写锁、乐观读直接升级为写锁，且悲观读与乐观读不可互转。
StampedLock 的锁模式切换不是自动或隐式的，必须通过 stamp 值显式控制，且仅支持特定方向的安全转换。核心原则是：**乐观读可安全降级为悲观读，写锁可安全降级为悲观读，但悲观读不能升级为写锁，乐观读也不能直接升级为写锁**。
乐观读 → 悲观读：验证失败后安全降级
这是最常用、最推荐的转换路径，适用于读多写少场景。关键在于“先无锁读，再按需加锁”：
- 调用 tryOptimisticRead() 获取初始 stamp，立即读取共享变量（仅限简单字段读取，无副作用）
- 立刻调用 validate(stamp) 判断是否被写操作干扰；若返回 false，说明数据可能已变更
- 此时调用 readLock() 获取悲观读锁（会阻塞后续写操作），重新读取数据
- 最后务必用 unlockRead(stamp) 释放悲观读锁，stamp 来自 readLock() 返回值
写锁 → 悲观读锁：需手动释放再获取
持有写锁时线程独占资源，可安全转为共享读权限，但 StampedLock 不提供原子降级 API：
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 先调用 unlockWrite(writeStamp) 释放写锁
- 再调用 readLock() 获取悲观读锁
- 注意：两次操作之间存在时间窗口，其他线程可能插入写操作；若需强一致性，应在写锁内完成所有修改，并在 unlockWrite 后尽快进入 readLock
写锁 ↔ 乐观读：不可互转，语义不兼容
乐观读本质是无锁快照，不改变锁状态；写锁则完全排斥读操作。二者 stamp 类型不同，无法互相验证或转换：
立即学习“Java免费学习笔记（深入）”；
- 不能 在持有写锁时调用 tryOptimisticRead() —— 此时它总是返回 0
- 不能 用写锁获取的 stamp 去调用 validate() —— 该 stamp 不代表乐观快照
- 若业务需要“读-改-写”，必须走“乐观读验证成功 → 放弃 → writeLock() 重试”流程，而非中途切换
悲观读锁 → 其他模式：禁止升级，也不支持转乐观读
悲观读锁本身会阻塞写操作，使 validate() 失去意义；StampedLock 明确不支持此路径：
- 持有 readLock() 获取的 stamp 时，调用 validate() 恒返回 true，无法反映真实版本变化
- 不能将悲观读锁“转成”乐观读 —— 二者 stamp 类型和用途完全不同，混用会导致逻辑错误或验证失效
- 如需尝试乐观路径，必须先 unlockRead()，再调用 tryOptimisticRead()
