stampedlock的悲观读锁会导致写线程饥饿，而乐观读通过无阻塞的stamp机制实现写线程插队权，并借助validate校验与按需升级为悲观读，显著缓解饥饿问题。
悲观读锁的阻塞特性与写线程饥饿风险
StampedLock 的悲观读锁（readLock()）语义上接近 ReentrantReadWriteLock 的读锁：多个线程可同时持有，但一旦有线程持有了写锁，所有后续尝试获取悲观读锁的线程都会被阻塞等待。这种设计在高并发读场景下容易造成写线程“长期饥饿”——尤其当读请求持续密集涌入时，写线程可能一直无法抢到锁机会，因为每次刚要竞争，又来一批新读线程抢占了读锁入口。
乐观读如何绕过阻塞、释放写线程窗口
乐观读（tryOptimisticRead()）不加锁、不排队、不阻塞任何线程。它仅返回一个 stamp（long 类型的版本戳），代表当前锁状态的快照。此时即使有其他线程正在执行 writeLock()，也不会被拒绝或挂起；写操作可以立即开始，无需等待所有悲观读完成。
这意味着：写线程不再需要“挤进读-写互斥队列”，而是在任意时刻都拥有一次“插队权”。只要它能成功获取写锁（即 stamp 有效且无冲突），就能立刻执行——这从根本上缓解了写线程因读流量洪峰导致的饥饿问题。
Stamp 的双重作用：轻量校验 + 精准升级
乐观读本身不保证数据一致性，它的价值依赖于 stamp 的校验机制：
- stamp 是状态快照，不是锁凭证：它记录的是调用 tryOptimisticRead() 时锁的版本号（如写计数器值），而非持有权。
- validate(stamp) 判断是否被写干扰：若期间发生过写操作，stamp 就失效，validate() 返回 false。
- 失效后可精准升级为悲观读：只在真正需要时才阻塞获取 readLock()，避免了“默认全量阻塞”的开销。
这个机制让大部分读操作以零成本完成，仅极小比例因写冲突而回退；写线程因此获得高频、低延迟的执行机会，不会被淹没在悲观读队列中。
对比ReadWriteLock：写线程不再“等读全退场”
在 ReentrantReadWriteLock 中，写线程必须等到所有已获取读锁的线程全部释放后才能入场；而 StampedLock 的乐观读不占用锁资源，也不计入“活跃读计数”，因此写线程只需避开当前正在执行的悲观读和正在进行的写即可——等待窗口大幅缩短。
例如：100 个线程连续调用 tryOptimisticRead() 并快速完成，它们都不阻塞写线程；只有第 101 个线程因校验失败而调用 readLock() 时，写线程才需短暂等待这一次。这种“按需阻塞”是 Stamp 变量驱动的细粒度协调逻辑。
