StampedLock不能替代ReentrantReadWriteLock，因其不可重入、不支持Condition、不兼容Lock接口；适合读多写少且读操作极快的场景，乐观读需validate后读取字段，stamp不可跨线程传递。
StampedLock 为什么不能直接替代 ReentrantReadWriteLock
StampedLock 不是可重入锁，也不支持条件变量（Condition），更不兼容 Lock 接口——它连 lock() 方法都没有。这意味着你没法用 synchronized 那种直觉写法，也不能和 await()/signal() 配合。它的核心设计目标是「消除写饥饿 + 减少读写冲突开销」，而不是提供通用锁语义。
常见误用是拿 tryOptimisticRead() 当普通读锁用：一旦校验失败就反复重试，反而比 readLock().lock() 更耗 CPU。真正适合的场景是「读多、写少、读操作本身极快」，比如配置快照、状态位检查。
乐观读模式下怎么安全地读取多个字段
乐观读（tryOptimisticRead()）只保证「单次读取时未被写入干扰」，但无法原子性地保护多个字段。如果读取 fieldA 和 fieldB 中间发生写操作，两者可能来自不同版本，导致逻辑错误。
- 必须在
validate(stamp)成功后，再读取所有相关字段（不能提前读） - 若字段间有约束（如
size和array长度需匹配），建议改用悲观读锁：readLock() - 避免在乐观读分支里调用外部方法或做 I/O，否则校验窗口过大，失败概率飙升
long stamp = sl.tryOptimisticRead();
int x = a; // ❌ 提前读，stamp 尚未校验
int y = b;
if (!sl.validate(stamp)) {
stamp = sl.readLock(); // ✅ 升级为悲观读
try {
x = a;
y = b;
} finally {
sl.unlockRead(stamp);
}
} else {
// ✅ 所有读必须放在 validate() 之后
x = a;
y = b;
}
写锁升级时为什么不能直接用 tryConvertToWriteLock
tryConvertToWriteLock(long stamp) 只在 stamp 是当前线程持有的读锁（且未被其他线程写入）时才可能成功。但它不是原子升级：如果 stamp 已过期，或中间有其他写操作，它直接返回 0 —— 你得自己处理降级重试逻辑，极易写出死循环或活锁。
立即学习“Java免费学习笔记（深入）”；
更稳妥的做法是：先释放读锁，再用 writeLock() 获取全新写锁。虽然多一次 CAS，但语义清晰、可预测。
-
tryConvertToWriteLock仅适用于「读完立刻写、且写操作极轻量」的场景 - 一旦失败，必须用
unlockRead(stamp)显式释放原读锁，否则造成锁泄漏 - 不要在循环里无休止调用它；超时或重试次数应设上限（比如 3 次）
StampedLock 的 stamp 值为什么不能跨线程传递
stamp 是一个带版本号的长整型，内部包含锁状态和线程标识信息，仅对获取它的线程有效。把它传给别的线程并调用 validate() 或 unlockXxx()，结果未定义——多数情况下直接返回 false 或抛 IllegalMonitorStateException。
这意味着你不能用它实现“读线程预占 + 写线程接管”这类模式。需要跨线程协调时，老实用 ReentrantReadWriteLock 或 Phaser 等显式同步工具。
另外，stamp == 0 表示乐观读失败或锁不可用，不是“空值”，别拿它做判空逻辑。
