Java 中如何对比 ReentrantLock 与 StampedLock 的性能特性

ReentrantLock 和 StampedLock 虽然都叫“锁”，但根本不是同一类选手——前者是通用的独占锁，适合写操作频繁或者读写逻辑强耦合的场景；后者是专为读多写少、能容忍短暂不一致的情况设计的读写增强型锁，性能更高，但功能和安全边界也更受限。直接拿来比其实容易搞混，关键得看读写比例、冲突频率和你对一致性的要求。

### 适用场景根本不同 拿场景来说，ReentrantLock 是通用互斥锁，适合写操作频繁或者读写逻辑强耦合的场景，比如计数器自增加判断这种需要原子性保证的操作；StampedLock 则面向高并发下以读为主、写极少且能容忍短暂不一致的场景，典型的像实时监控面板的数据刷新、配置快照的读取。 - **ReentrantLock**：单线程串行化一切访问，读和写都排队，吞吐受限，但语义简单，强一致。 - **StampedLock**：提供三种模式——写锁（独占）、悲观读锁（共享但阻塞写）、乐观读（无锁加版本校验）。本质上是“用版本验证换并发度”。 ### 核心性能指标表现差异 数据是最直观的。在 16 核、读写比 8:2 的典型测试中： - ReentrantLock 的吞吐大约在 8000～10000 ops/sec（所有操作串行）。 - StampedLock 的乐观读在低冲突下能达到 25000 ops/sec，悲观读约 18000，写锁性能和 ReentrantLock 接近。 - 延迟方面，乐观读的毫秒级响应几乎为零，而 ReentrantLock 在高争用下平均等待时间会明显上升。 有个要点得注意：StampedLock 的高吞吐依赖“写极少 + 读期间大概率没有写干扰”。一旦写操作变频繁，乐观读的 validate 失败率就会升高，频繁降级到悲观读，反而增加了额外开销。 ### 功能与安全边界对比 性能不是唯一维度，可靠性和编码成本同样关键。来看几个核心差异： - **重入性**：ReentrantLock 支持同一线程重复 lock()；StampedLock 的写锁支持重入，但读锁（包括乐观读）完全不支持——重复调用会出错。 - **中断与超时**：ReentrantLock 支持 lockInterruptibly() 和 tryLock(timeout)；StampedLock 所有阻塞方法（readLock/writeLock）都不可中断。 - **锁降级**：ReentrantReadWriteLock 支持写锁降级为读锁（保证可见性）；StampedLock 不支持任何降级，写锁释放后必须重新获取读锁。 - **异常安全**：ReentrantLock 可以在 finally 中调用 unlock() 来保障释放；StampedLock 必须严格配对 stamp，如果 validate 失败后没有正确 unlockRead，很容易造成资源泄漏。 ### 选型建议：先问业务，再选锁 别为了“新”而用 StampedLock。真实项目里，判断标准很简单： - **选 ReentrantLock**：需要递归调用、需要响应中断、写操作占比超过 20%、逻辑简单直白。 - **选 StampedLock**：热点只读数据（比如仪表盘状态）、JDK 8 以上、能接受少量 validate 失败并降级、团队熟悉乐观读校验的写法。 - **慎用 StampedLock**：涉及复合判断的场景，比如“余额大于 100 才扣款”，乐观读无法保证两次读之间的一致性，必须用悲观读或写锁兜底。