问题的回答。
问题历史。
ReentrantReadWriteLock 在 Java 5 中引入，极大地改善了并发性，允许多个并发读者。然而，它的设计明确禁止锁升级——即在保持读锁的情况下获取写锁——因为实现跟踪每个线程的读保持计数。当持有读锁的线程尝试获取写锁时，会导致自我死锁：写锁需要独占持有，这在保持任何读锁（包括线程自己的读锁）时无法授予。Java 8 中引入的 StampedLock 作为一种非重入的替代方案，通过乐观读戳来解决这一限制，这种戳在读阶段无需锁的拥有权，并结合原子验证和转换机制。
问题。
根本的隐患来源于锁获取语义中的不对称性。在 ReentrantReadWriteLock 中，升级要求在获取写锁之前释放读锁，这创建了一个脆弱的窗口，在此期间其他线程可能在释放和重新获取之间获取写锁或修改状态。这迫使开发人员实现复杂的双重检查锁定模式或重试循环，增加了代码复杂性和延迟。此外，如果开发人员错误地尝试直接升级（在持有读锁时调用 writeLock().lock()），该线程会进入一个无法恢复的死锁状态，等待自己释放读许可。
解决方案。
StampedLock 通过 tryOptimisticRead() 消除了这一隐患，该方法在不获取任何锁或增加读者计数的情况下返回一个长戳。线程执行其读操作，并随后调用 validate(stamp)；如果戳仍然有效（没有发生插入写入），则读取是无阻塞的。当线程检测到需要写入时，它会尝试 tryConvertToWriteLock(stamp)，该方法原子地验证戳并仅在乐观读开始后状态没有变化时获取写锁。由于线程在转移过程中从不持有冲突的读锁，这种方法防止了死锁，同时通过使升级依赖于状态一致性，避免了释放和重新获取策略的竞争窗口。
代码示例。
import java.util.concurrent.locks.StampedLock; public class AtomicUpgradeCache { private final StampedLock lock = new StampedLock(); private int value = 0; public void conditionalUpdate(int threshold, int newValue) { long stamp = lock.tryOptimisticRead(); int current = value; // 在操作之前验证 if (!lock.validate(stamp)) { stamp = lock.readLock(); try { current = value; } finally { lock.unlockRead(stamp); } } if (current < threshold) { // 尝试原子升级 stamp = lock.tryConvertToWriteLock(stamp); if (stamp == 0L) { // 转换失败，获取新的写锁 stamp = lock.writeLock(); } try { // 在独占锁下重新检查条件 if (value < threshold) { value = newValue; } } finally { lock.unlock(stamp); } } } }
生活中的情境
问题描述。
一个高频交易平台维持一个内存中的订单簿缓存，代表实时市场深度，需要来自数百个线程的每秒约 50,000 次读取，但仅在价格波动到达时偶尔更新。最初的实现使用 synchronized 块，导致在市场波动期间线程争夺监视器时出现灾难性的延迟峰值，读取延迟偶尔超过 500 毫秒。工程团队需要完全消除读侧争用，同时确保价格更新能够原子性地验证市场条件并在不在观察与变更之间死锁的情况下修改订单簿。
考虑的不同解决方案。
解决方案 1：使用释放和重新获取的 ReentrantReadWriteLock。
这种方法涉及获取读锁以检查市场条件，释放它，然后立即尝试如果需要更新则获取写锁。虽然这样可以防止死锁，但它引入了一个显著的竞争条件：在释放读锁和获取写锁之间，竞争线程可能会观察到相同的过时状态并启动冗余的数据库查询或交换 API 调用，导致成群效应和计算资源浪费。此外，在高交易量期间，不断在读取和写入模式之间切换增加了可衡量的开销。
解决方案 2：使用易变引用的不可变快照。
该解决方案完全放弃了锁，转而维护订单簿作为由易变字段引用的不可变数据结构。读者只需解除引用易变字段以获得一致的快照，而写者则创建全新的订单簿副本，并对引用执行原子比较和设置操作。这完全消除了读取争用，并提供了优秀的读取性能。然而，它产生了巨大的分配压力——每个小的价格更新都需要复制整个订单簿结构，触发频繁的年轻代垃圾收集暂停，这在价格波动条件下违反了应用程序的 10 毫秒延迟 SLA。
解决方案 3：使用乐观读取和条件转换的 StampedLock。
选择的解决方案利用 StampedLock 为热路径提供乐观读取访问：线程将使用 tryOptimisticRead() 乐观地读取订单簿状态，验证戳，只有在没有并发写入发生的情况下才会继续。对于少量的写操作，系统会尝试使用 tryConvertToWriteLock() 将乐观戳直接转换为写锁，从而原子地验证观察到的状态是否保持当前，并仅在有效时获取独占访问。如果转换失败，系统退回到显式写锁的获取和传统重试逻辑。该方法为读取提供了近乎零的开销（类似于原始易变访问），同时防止了在 ReentrantReadWriteLock 升级中固有的死锁风险。
选择了哪个解决方案（以及原因）。
团队选择了 解决方案 3，因为它在极高的读取吞吐量要求（乐观读取与线程数量线性扩展）与条件更新的原子安全要求之间独特地平衡。与 解决方案 1 不同，它通过戳验证机制消除了读取释放和写入获取之间的竞争窗口。与 解决方案 2 不同，它避免了内存分配压力，通过在转换的写锁保护下允许原地修改，而不是为每个小的价格调整要求完整的结构副本。原子验证和转换的能力确保价格更新仅在市场状态完全符合决策标准时发生，防止了早期原型所面临的一致性违规。
结果。
实施后，应用程序维持每秒 50,000 次并发读取，p99.9 的延迟低于 15 微秒，代表与之前同步方法相比的 30 倍改善。在模拟市场波动期间，每秒 1,000 次并发价格更新，系统保持零死锁事件，垃圾收集暂停保持在 2 毫秒以下。StampedLock 实现成功处理了六个月的生产交易，没有单一的与并发相关的事件或数据竞争，验证了在高频读取场景中使用乐观锁的架构决策。
候选人通常会忽略的内容
为什么 StampedLock 不支持重入性，以及如果线程尝试递归获取同一锁，会出现什么灾难性失败模式？
StampedLock 明确设计为一种非重入锁，以最小化内部状态跟踪并最大化吞吐量。与 ReentrantReadWriteLock 不同，后者维护拥有线程和保持计数的映射，StampedLock 仅跟踪任何线程是否持有访问，而不是哪个特定线程拥有它。因此，如果持有读锁的线程尝试在同一 StampedLock 实例上获取另一个读锁（或写锁），它立即死锁：获取调用阻塞，等待所有现有锁释放，但被阻塞的线程自身持有其中一个锁，形成无法解决的循环依赖。开发人员必须重构代码，将当前戳作为方法参数传递，而不是尝试嵌套锁获取，这往往需要显著的架构更改，以适应之前依赖于线程本地锁状态的内部 API。
StampedLock 的乐观读取模式的内存可见性语义与其悲观读取锁有何不同，以及为什么仅 validate() 不足以确保一致性，而缺乏适当的发生之前关系？**
通过 tryOptimisticRead() 进行的乐观读取本身并不提供发生之前的保证；它仅捕获一个版本戳，而不发出内存屏障或防止指令重排序。在乐观阶段观察到的数据可能反映过时的 CPU 缓存行或部分构造的对象，因为 JVM 内存模型将乐观读取视为没有同步语义的普通变量访问。只有当 validate(stamp) 返回 true 时，才能建立自乐观读取开始以来没有获取写锁的必需发生之前关系。然而，候选人往往忽视的是，validate() 仅保证锁状态，而不是数据结构的内部一致性：如果受保护的数据包含对可变对象的非易变引用，则乐观读取可能会观察到一个对象的引用，该对象的字段仍被另一个线程初始化（不安全发布）。因此，乐观读取要求受保护状态全部由易变引用或不可变对象组成，以确保安全发布，无论锁的内存语义如何。
StampedLock 与 虚拟线程（项目 Loom）之间的根本不兼容性是什么，这为什么需要在现代使用虚拟线程的高并发应用程序中避免 StampedLock？**
StampedLock 的实现依赖于 LockSupport.park 操作，当虚拟线程在持有锁时阻塞时会固定底层的 Platform Thread（载体线程）。当虚拟线程尝试获取有争用的 StampedLock（无论是读取还是写入）时，JVM 无法将虚拟线程从其载体中卸载，因为锁内部使用的原生同步原语尚未适应虚拟线程让步。这种固定违背了虚拟线程的核心可扩展性承诺，即将成千上万个虚拟线程复用到少数平台线程上。如果多个虚拟线程同时在 StampedLock 冲突时阻塞，它们会垄断整个载体线程池，冻结应用程序，即使理论上仍有数百万个虚拟线程可用。相比之下，ReentrantLock 和 Semaphore 已经进行了改装，以避免通过使用无阻塞算法或在虚拟线程调用时使用的专门让步机制来固定。因此，使用 VirtualThread 执行程序的现代应用程序必须用 ReentrantLock 或并发数据结构替换 StampedLock 以防止载体线程饥饿。