乐观读能减少写线程阻塞，因为tryOptimisticRead不加锁、不参与竞争，仅读取版本戳，validate校验是否被写；读多写少时多数读跳过锁开销，写线程可随时获取writeLock，避免写饥饿。
乐观读锁为什么能减少写线程阻塞
因为 tryOptimisticRead 不加锁，也不参与锁竞争，它只读取一个版本戳（stamp），后续靠 validate 校验是否被写过。当读多写少时，绝大多数读操作能跳过锁开销，同时写线程仍可随时获取 writeLock —— 这就打破了 ReentrantReadWriteLock 中“一有读锁、写就必须等”的死局，避免写饥饿。
常见错误现象：直接用 tryOptimisticRead 读完就返回，不校验 validate，导致读到脏数据；或在校验失败后没 fallback 到悲观读，而是硬 retry，造成逻辑错乱或无限循环。
- 乐观读仅适用于「读取+简单判断」类场景，比如检查某个状态是否为 true、读取一个数值做比较
- 不能用于需要强一致性的复合操作（如先读 x 再读 y，再算 x+y）
- 校验失败后应立即转为
readLock+validate或直接writeLock，而不是自旋重试
怎么正确使用 tryOptimisticRead + validate 流程
核心是两段式：先无锁读，再校验；失败则降级。这不是“自动重试机制”，而是一次性决策路径。
示例场景：判断账户余额是否足够扣款
long stamp = sl.tryOptimisticRead();
double currentBalance = balance; // 无同步读取
if (!sl.validate(stamp)) {
// 乐观读失效，降级为悲观读
stamp = sl.readLock();
try {
currentBalance = balance;
} finally {
sl.unlockRead(stamp);
}
}
return currentBalance >= amount;
注意点：
-
tryOptimisticRead返回 0 表示当前有写锁活跃，可直接跳过乐观路径 -
validate必须在读取共享变量「之后、使用之前」立刻调用，中间不能插入其他可能修改状态的操作 - 悲观读锁拿到的
stamp必须配对unlockRead，否则资源泄漏
为什么不能把乐观读当成“轻量版读锁”滥用
乐观读不是性能银弹。它绕过了内存屏障和锁队列，代价是放弃一致性保证。JVM 不保证该读操作对其他线程可见，也不保证指令重排序被禁止 —— 所以它只适合「最终一致性可接受」的读场景。
典型误用：
- 在乐观读路径中调用外部方法（如
log.info()），导致校验前实际已发生不可逆副作用 - 读取多个字段后统一校验，但字段间存在隐含约束（如
version和data需配套），validate只能保证 stamp 未变，无法保证字段组合逻辑有效 - 在循环中反复
tryOptimisticRead+validate，相当于手动实现 CAS 自旋，反而比直接readLock更耗 CPU
性能影响：乐观读本身几乎零开销，但频繁 validate 失败会触发更多悲观读，吞吐反而下降；实测中 validate 失效率超过 5% 就该重新评估是否适合该场景。
StampedLock 的 stamp 必须显式管理
writeLock 和 readLock 返回的 stamp 是解锁唯一凭证，且 StampedLock 不可重入 —— 同一线程重复 writeLock 会导致死锁，这点和 ReentrantReadWriteLock 完全不同。
容易踩的坑：
- 忘记保存
stamp，或保存成局部变量后在异步回调里使用，导致unlockWrite(0)或unlockRead(0)—— 实际无效果，锁永远不释放 - 用同一个
stamp多次调用unlockWrite，会抛IllegalMonitorStateException - 在 try-finally 外提前 return，跳过 unlock，造成锁泄漏（尤其在嵌套判断中）
建议始终把 stamp 声明为 final 局部变量，并严格配对 try-finally；不要跨方法传递 stamp，更不要存入对象字段。
