StampedLock悲观锁与乐观读：邮戳变量如何优化写线程饥饿问题

在并发编程中，读写锁的设计需要精妙的平衡。传统读写锁如ReentrantReadWriteLock虽解决了读写互斥问题，但在读操作密集时，写线程可能面临“饥饿”，长时间无法执行。这类似于一条繁忙的单行道，持续不断的人流（读线程）使得急需通过的车辆（写线程）只能等待。

StampedLock引入的“乐观读”机制，正是针对这一痛点。它通过一个称为“邮戳”（Stamp）的版本变量，在不牺牲数据安全的前提下，为写线程开辟了一条“快速通道”。

悲观读锁的阻塞特性与写线程饥饿风险

StampedLock的悲观读锁行为与ReentrantReadWriteLock的读锁类似：允许多线程同时持有，但写锁是排他的。问题在于，一旦有线程获取了悲观读锁，后续尝试获取写锁的线程都会被阻塞在队列中。

设想一个场景：热点数据被频繁读取，读请求如潮水般涌来。每个读线程都成功获得了悲观读锁，而写线程每次即将轮到时，总被新到的读线程“插队”抢占入口。这种设计在高并发读场景下，极易导致写线程陷入长期饥饿。

乐观读如何绕过阻塞、释放写线程窗口

乐观读的巧妙之处在于思路的转变。调用tryOptimisticRead()时，它并不加锁或排队，而是直接返回一个代表当前锁状态快照的stamp（一个long型版本戳）。

这个操作本身零成本，且不会阻塞任何其他线程。这意味着，即使有成百上千个线程正在进行乐观读，写线程调用writeLock()时也不会被拒绝或挂起。写操作几乎可以随时尝试开始，无需像以往那样等待所有读操作“清场”。

可以说，乐观读机制赋予了写线程一种“插队权”。它不再需要挤入严格的读-写互斥队列中苦苦等待，只要时机合适（即锁状态允许），就能立即获得执行权。这从根源上缓解了写线程因读流量洪峰而导致的饥饿问题。

Stamp 的双重作用：轻量校验与精准升级

当然，乐观读并非“读而不锁”。其安全性完全依赖于stamp这个核心变量的校验机制。理解stamp的两个关键角色至关重要：

• 它是“快照”，而非“门票”：stamp仅记录了调用tryOptimisticRead()那一刻锁的版本号（如内部的写计数器值），本身不代表线程持有锁。线程持有它，仅获得一个“观察许可”。
• 校验（validate）是安全的关键：乐观读操作完成后，线程必须调用validate(stamp)进行校验。若在读取数据期间有任何其他线程成功执行了写操作，则该stamp会失效，validate()返回false。此时，读取的数据可能不一致。
• 按需升级，避免无谓阻塞：一旦校验失败，线程可以“精准地”将此次读操作升级为传统的悲观读锁（调用readLock()）。这种“用时再锁”的策略，避免了传统模式下所有读操作“默认全量阻塞”的开销。

这套组合拳的精妙之处在于，它让绝大多数读操作以近乎零成本的方式完成，仅极少数真正遭遇写冲突的读操作才需要回退并阻塞。反过来，写线程因此获得了更多、更及时的执行机会，不再被淹没在悲观读的阻塞队列中。

对比ReadWriteLock：写线程不再“等读全退场”

为更清晰地看到优化效果，可与ReentrantReadWriteLock进行直接对比。

在ReentrantReadWriteLock的规则下，写线程入场有一个硬性条件：必须等待所有已获取读锁的线程全部释放之后才行。这好比会议室的门，只要里面还有人在开会（读），外面等待做报告（写）的人就不能进入。

而StampedLock的乐观读彻底改变了规则。因为乐观读根本不持有锁，也不被计入“活跃读者”名单。所以，写线程只需避开两件事：当前正在执行的悲观读操作和正在进行的写操作。其等待窗口被大幅缩短。

举例来说：假设有100个线程连续进行乐观读，它们都快速完成了validate并成功返回。对写线程而言，这100个操作如同不存在，它随时可以竞争锁。只有当第101个线程的乐观读校验失败，并升级去获取悲观读锁时，写线程才需要短暂等待这“一个”读操作。这种由stamp变量驱动的、“按需阻塞”的细粒度协调逻辑，正是解决写饥饿问题的核心所在。