StampedLock 的乐观读仅适用于极短路径的轻量字段访问，滥用忙等循环会导致 CPU 100%；一旦涉及方法调用、集合操作或写入频繁，validate 失败率高，fallback 开销反而更大，应降级为 readLock()。
StampedLock 的乐观读本身不压榨 CPU，滥用 tryOptimisticRead() + 忙等循环才会让 CPU 100% —— 这不是“压榨吞吐”，而是把线程卡在无意义自旋里。
乐观读不是无条件高速通道，它只对极短路径内存访问有效
它的设计目标很窄：同一 JVM 内、无 IO、无同步块、字段访问路径极短（比如读一个 volatile int 或 final 字段）。一旦涉及方法调用、对象遍历、集合 size 计算、甚至一次 System.nanoTime() 调用，乐观读的验证失败率就会上升，fallback 到悲观读的开销反而比直接上读锁更大。
- 正确场景示例：读取一个
volatile long timestamp或final String version - 错误场景示例：调用
map.get(key)后再 validate —— HashMap 查找本身就有分支和哈希计算，期间完全可能被写线程修改结构 - validate() 只做一次 volatile 读比较，耗时纳秒级；但前面的“读操作”如果本身要微秒级，那乐观读就失去意义
validate 失败后不能 while 循环重试
常见误写是：while (!lock.validate(stamp)) { stamp = lock.tryOptimisticRead(); value = this.x; }。这会导致 CPU 忙等，且大概率永远等不到成功 —— 因为写操作可能持续发生，或 stamp 已过期无法恢复。
- validate 返回 false 后，必须立即降级为
readLock()，而不是重试乐观读 - 乐观读只适合“读取动作本身极快 + 写入频率极低”的组合；若写入稍频繁，fallback 成为常态，吞吐反而低于
ReentrantReadWriteLock - 没有“重试次数阈值”这种安全兜底机制；StampedLock 不提供类似
tryLock(timeout)的乐观读超时支持
写锁优先机制会加剧读线程 fallback，不是所有“读多写少”都适用
StampedLock 的写锁会主动使所有未 validate 的乐观读 stamp 失效，且不排队、不通知。这意味着：哪怕写操作只耗时几十纳秒，只要它发生，正在执行乐观读的线程几乎必然 validate 失败。
- 适用于写操作极少（例如配置热更新，每分钟最多一次）、且写后立刻需要强一致读的场景
- 不适用于写操作虽少但集中爆发（如批量导入后刷新缓存），此时大量读线程同时 fallback，AQS 队列拥堵，吞吐断崖下跌
- 对比
ReentrantReadWriteLock，StampedLock 的写饥饿更隐蔽：它不阻塞乐观读线程，但让它们反复失败、重进队列，实际加重了锁竞争
真正能压榨 CPU 吞吐的，是把乐观读用在“读操作原子、路径确定、字段轻量”的关键元数据上，比如路由表版本号、连接池健康标记、本地计数器快照；一旦读逻辑涉及任何不确定跳转或外部依赖，就该放弃乐观读，老实用悲观读或更粗粒度的分段锁。
