乐观读在读多写少时能省锁竞争，因其仅volatile读stamp而不入AQS队列；但需满足三前提：只读volatile/final字段、无多字段强一致性依赖、写操作极轻量，否则易因频繁降级导致吞吐反低于ReentrantReadWriteLock。
能翻倍，但前提是写操作真的极少、读数据结构简单、且验证失败路径不频繁触发。 否则乐观读反而因反复降级带来额外开销，吞吐可能比 ReentrantReadWriteLock 还低。
为什么乐观读在读多写少时能省掉锁竞争
传统 ReentrantReadWriteLock 的读锁要走 AQS 队列排队，哪怕只是读一个 int 字段，也要 CAS 更新 state、可能触发线程挂起唤醒。而 StampedLock.tryOptimisticRead() 只做一次 volatile 读（获取当前 stamp），完全不修改任何共享状态，也不阻塞任何人。
关键点在于：写线程调用 writeLock() 时，不会等所有乐观读“结束”——它只让后续的 tryOptimisticRead() 返回 0，并让已获取的 stamp 在 validate() 时大概率失败。这避免了读线程集体卡在写锁门口。
- 乐观读期间，写线程可以立即获取
writeLock()并执行 - 读线程不参与锁队列，无上下文切换开销
- 验证失败后才走悲观读路径，此时才真正参与锁竞争
必须满足的三个实操前提
乐观读不是万能加速器，以下三点任一不满足，就容易掉进性能陷阱：
-
tryOptimisticRead()后只能读final或volatile字段；普通字段可能因指令重排导致读到中间态（比如对象引用未完全构造好） - 读取过程不能有副作用或依赖多个字段强一致性——例如读
size和遍历array必须原子，否则即使validate()成功，size和实际元素数也可能不匹配 - 写操作不能太重；如果写锁平均持有时间 > 100μs，乐观读验证失败率会显著上升，fallback 频次高，吞吐优势迅速消失
典型安全用法：单字段快照 + 验证后立即使用
以缓存命中计数器为例，这是最稳妥的乐观读场景：
private final StampedLock lock = new StampedLock();
private volatile long hitCount; // 必须 volatile
public long getHitCount() {
long stamp = lock.tryOptimisticRead();
long current = hitCount;
if (lock.validate(stamp)) {
return current; // 无写干扰，直接返回
}
// 验证失败，升级为悲观读
stamp = lock.readLock();
try {
return hitCount;
} finally {
lock.unlockRead(stamp);
}
}
注意：hitCount 是 volatile，所以两次读（乐观路径和悲观路径）语义一致；整个方法不涉及计算、不依赖其他变量；写操作只是 hitCount++，极轻量。
如果换成读一个 Map 的 size() 再去 keySet().toArray()，那就踩坑了——size() 验证成功不代表 keySet 没被并发修改。
最容易被忽略的坑：stamp 泄漏与写锁饥饿
乐观读本身不占资源，但一旦降级为 readLock()，就必须配对 unlockRead(stamp)，漏掉就会导致读锁计数泄漏，最终写锁永远无法获取。
更隐蔽的是写锁饥饿：StampedLock 的写锁优先级高于读锁，但乐观读失败后降级的读锁，会和其他读线程一起排队等写锁释放。如果读请求持续密集，写线程可能长期卡在 writeLock() 调用里——这不是 bug，是设计使然。线上若出现写延迟突增，先查写锁获取耗时，再看乐观读 fallback 率。
