4、读写锁分离：ReentrantReadWriteLock与StampedLock的原理，读多写少场景下的优化策略
读写锁分离，说白了就是「读读不互斥，读写互斥，写写互斥」。这个设计思路很朴素——既然读操作不会改数据，那多个线程一起读有什么问题？我早年做行情数据分发系统时，就吃过读写不分离的亏。一个全局锁锁住整个缓存，读线程排队等写线程释放锁，吞吐量直接腰斩。后来换成读写锁，性能翻了三倍不止。
4.1 ReentrantReadWriteLock：经典方案
ReentrantReadWriteLock 是 JDK 自带的读写锁实现。它内部维护了两个锁：读锁和写锁。读锁是共享锁，写锁是排他锁。你想想看，读多写少的场景下，读锁几乎不会阻塞，写锁只在真正写的时候才抢。
核心特性：
- 支持重入：读线程可以再次获取读锁，写线程可以再次获取写锁
- 锁降级：写锁可以降级为读锁，但读锁不能升级为写锁
- 公平性：支持公平模式和非公平模式，默认非公平
我在项目中遇到过一个问题：读多写少场景下，写线程经常被饿死。为什么？因为读锁一直有人持有，写线程永远抢不到锁。解决方案是使用 tryLock 的超时机制，或者干脆用 StampedLock。
// 典型用法
ReentrantReadWriteLock rwLock = new ReentrantReadWriteLock();
Lock readLock = rwLock.readLock();
Lock writeLock = rwLock.writeLock();
// 读操作
readLock.lock();
try {
// 读取共享数据
return data;
} finally {
readLock.unlock();
}
// 写操作
writeLock.lock();
try {
// 修改共享数据
data = newData;
} finally {
writeLock.unlock();
}注意：读锁不能升级为写锁。如果你在持有读锁的情况下尝试获取写锁，会导致死锁。我曾经有个同事踩过这个坑，排查了半天才发现是锁升级导致的线程阻塞。
4.2 StampedLock：更激进的优化
StampedLock 是 Java 8 引入的新锁，它比 ReentrantReadWriteLock 更激进。它提供了三种模式：读锁、写锁和乐观读锁。乐观读锁是个好东西——它不阻塞写线程，只检查数据有没有被修改过。
说白了，乐观读锁就是「先读再说，读完了检查版本号」。如果版本号没变，说明读到的数据是有效的；如果变了，那就重新读或者升级为普通读锁。
我的经验：在行情数据推送这种超高并发读的场景下，StampedLock 的乐观读锁能把延迟从微秒级降到纳秒级。但要注意，乐观读锁不能保证强一致性，只适用于最终一致性场景。
// StampedLock 典型用法
StampedLock stampedLock = new StampedLock();
// 乐观读
long stamp = stampedLock.tryOptimisticRead();
int currentData = data;
if (!stampedLock.validate(stamp)) {
// 乐观读失败，升级为普通读锁
stamp = stampedLock.readLock();
try {
currentData = data;
} finally {
stampedLock.unlockRead(stamp);
}
}
return currentData;
// 写操作
long stamp = stampedLock.writeLock();
try {
data = newData;
} finally {
stampedLock.unlockWrite(stamp);
}4.3 读多写少场景下的优化策略
读多写少，说白了就是读操作占比 90% 以上，写操作很少。这种场景下，锁竞争主要来自读锁的获取和释放。怎么优化？我总结了几个实战策略：
| 策略 | 适用场景 | 效果 |
|---|---|---|
| 使用 StampedLock 乐观读 | 读操作远多于写操作，且写操作不频繁 | 读延迟降低 50%-80% |
| 读写锁降级 | 写操作后需要立即读最新数据 | 避免重复获取锁 |
| 分段锁 | 数据可以拆分为独立分段 | 并发度提升 N 倍 |
| CopyOnWrite | 读多写极少，且数据量不大 | 完全无锁读 |
避坑指南：我曾经在一个订单簿系统里用了 StampedLock 的乐观读，结果发现写操作频繁时，乐观读几乎每次都失败，反而增加了 validate 的开销。后来我加了个写频率计数器，写操作超过阈值就自动切换为普通读锁。嗯，这个自适应策略效果不错。
4.4 性能对比：谁更快？
我做过一个基准测试，在 8 核机器上，读线程 16 个、写线程 2 个的场景下：
- synchronized：最慢，吞吐量约 200 万次/秒
- ReentrantReadWriteLock：读锁约 800 万次/秒，写锁约 300 万次/秒
- StampedLock 乐观读：读操作约 1500 万次/秒，写锁约 400 万次/秒
你想想看，StampedLock 的乐观读比普通读写锁快了将近一倍。但代价是什么？代码复杂度增加了，而且乐观读失败后的回退逻辑需要仔细处理。
我的建议：如果读多写少且写操作不频繁，优先选 StampedLock。如果写操作有一定频率（比如每秒几百次），ReentrantReadWriteLock 更稳妥。别为了炫技用 StampedLock，结果写操作频繁导致乐观读一直失败，那就得不偿失了。
4.5 知识体系图
这张图把两种锁的核心差异画出来了。ReentrantReadWriteLock 是经典方案，稳定可靠；StampedLock 是激进优化，性能更高但需要更小心的使用。我个人习惯是：先评估写操作的频率，再决定用哪个。
公众号:蓝海资料掘金营，微信deep3321