StampedLock 不支持悲观读转乐观读，因二者stamp类型不同且语义互斥；正确做法是乐观读失败后降级为悲观读，适用于读多写少、读逻辑极快的高性能场景。
StampedLock 不支持“悲观读转乐观读”这种操作。它设计上就是用乐观读（tryOptimisticRead）配合验证（validate）来替代传统悲观读锁，二者是互斥的使用路径，不能中途切换。
为什么不能“悲观读转乐观读”
StampedLock 的三种模式（写锁、悲观读锁、乐观读）对应不同的同步语义和底层实现：
-
悲观读锁（
readLock()）会阻塞其他写操作，获取的是一个带版本号的“锁戳”，需显式unlockRead()； -
乐观读（
tryOptimisticRead()）不加锁、不阻塞、不改变同步状态，只返回当前版本戳，后续靠validate()检查是否被写过； - 两者获取的 stamp 类型不同：悲观读锁返回的是“可释放的读锁戳”，乐观读返回的是“只读快照戳”，不能混用，调用
validate()在悲观读锁持有期间永远返回true（因为写被阻塞了），失去乐观读的意义。
正确用法：乐观读失败后降级为悲观读
这是 StampedLock 推荐的典型模式——先尝试无锁读，若发现数据可能被修改（validate 失败），再退回到安全但有开销的悲观读：
long stamp = sl.tryOptimisticRead();
int current = x;
if (!sl.validate(stamp)) {
// 乐观读失败，说明期间发生过写操作
stamp = sl.readLock(); // 获取悲观读锁
try {
current = x;
} finally {
sl.unlockRead(stamp);
}
}
// 使用 current（确保一致性）
注意事项与常见误区
-
乐观读不阻塞写操作：所以必须在读取共享变量后立即
validate()，且读取过程应尽量轻量（避免 IO、复杂计算或调用可能触发写的方法）； -
不能在悲观读锁内调用
tryOptimisticRead：这不会报错但无意义，stamp 无法用于后续validate，且违反设计意图； -
写操作必须用
writeLock：只有写锁能更新内部版本戳，否则乐观读的validate始终通过，导致脏读； - 乐观读适用于读多写少 + 读逻辑极快：比如读取几个基本类型字段；若读取过程长或涉及对象图遍历，直接用悲观读更稳妥。
对比 ReentrantReadWriteLock 的适用场景
StampedLock 不是它的升级替代品，而是面向更窄的高性能场景：
立即学习“Java免费学习笔记（深入）”；
- 需要极低读延迟且能容忍重试 → 选
tryOptimisticRead+ 降级； - 读操作较重、或需保证一次成功 → 用
readLock； - 需要重入、条件变量、公平性控制 → 还得用
ReentrantReadWriteLock（StampedLock 不支持重入和条件队列）。
