stampedlock 的三种模式按场景分层设计：乐观读适用于极轻量高频率读取，悲观读用于强一致且读逻辑稍重的场景，写锁用于修改；乐观读失败后应先重试再降级为悲观读，且不可与asreadlock()混用。
StampedLock 的三种模式不是并列选择，而是按场景分层设计：乐观读用于极轻量、高频率读取；悲观读用于需要强一致但读逻辑稍重的场景；写锁用于修改。它们之间不能随意切换，必须遵循明确的转换规则。
乐观读失败后应先重试，再降级为悲观读
乐观读（tryOptimisticRead()）不加锁，只返回一个快照戳（stamp），后续靠 validate(stamp) 检查是否被写过。它本身不阻塞写操作，所以读取必须快——仅限基本类型或不可变对象的简单赋值。
- 若 validate() 返回 false，说明期间发生过写，但不意味着必须立刻加锁；可重试 1–2 次乐观读，避免过早牺牲无锁性能
- 重试仍失败，才调用 readLock() 获取悲观读锁，二次读取并用 unlockRead() 释放
- 不能在 readLock() 持有期间调用 tryOptimisticRead() —— stamp 类型不兼容，validate 恒为 true，失去意义
读锁可升级为写锁，但仅限由 readLock() 获取的 stamp
StampedLock 支持原子性锁升级：持有悲观读锁后，可用其 stamp 尝试转为写锁，避免先释放读锁再抢写锁引发的竞争窗口。
- 调用 tryConvertToWriteLock(stamp)，成功则 stamp 变为写锁戳，原读锁自动释放
- 失败时，stamp 仍有效且读锁未释放，必须显式 unlockRead(stamp) 后再调用 writeLock()
- tryOptimisticRead() 返回的 stamp 不能传给 tryConvertToWriteLock() —— 它只接受锁方法返回的有效锁戳
写锁可安全降级为读锁，但不可重入
写操作完成后若需对外提供只读视图，可将写锁 stamp 降级为读锁 stamp，避免释放再获取的开销，也防止中间被其他写入干扰。
- 调用 tryConvertToReadLock(stamp)，成功则 stamp 更新为读锁戳，可后续用 unlockRead() 释放
- StampedLock 不支持重入：同一线程重复调用 readLock() 或 writeLock() 会导致死锁
- 持有写锁时调用 asReadLock().lock() 会死锁，因 asReadLock 是独立 AQS 实现，与当前写锁上下文冲突
不能跨机制混用锁路径
StampedLock 内部存在两套同步机制：基于 stamp 的 CAS 版本控制（乐观读、读/写锁）和基于 AQS 的传统锁封装（asReadLock()）。二者 stamp 不互通、状态不感知。
- asReadLock() 返回的是标准 Lock 接口，其 lock() 和 unlock() 与 stamp 无关，不能和 unlockRead(stamp) 混用
- 在乐观读失败后直接调用 asReadLock().lock() 是错误做法：丢失 stamp 上下文，可能掩盖线程已持写锁的事实，引发死锁
- 所有 stamp 必须配对使用对应 unlock 方法：readLock() → unlockRead()，writeLock() → unlockWrite()
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
