读写锁原理及并发优化方法

本文深入剖析了ReentrantReadWriteLock的读写分离机制及其相较于synchronized的性能优势与适用边界，强调其在读多写少场景（如配置缓存、路由表）中的高效性，同时警示写操作频繁时因状态开销反而劣于synchronized；文章系统讲解了锁的正确使用规范（必须try-finally配对释放、禁用try-with-resources）、典型陷阱（读锁未释放导致线程挂起、读锁升级死锁、写饥饿问题），并对比介绍了更轻量但限制更多的StampedLock——尤其适合极轻量乐观读场景，最后指出复杂混合负载下分层加锁的设计智慧，为高并发系统中的锁选型与优化提供了兼具原理深度和工程实操性的关键指南。

ReentrantReadWriteLock 为什么比 synchronized 快

因为它是「读写分离」的锁：多个线程同时读不互斥，只有写或读写之间才阻塞。而 synchronized 不管读写，一律串行——哪怕全是只读操作，也得排队。

适用场景很明确：数据结构被频繁读、极少修改（比如配置缓存、路由表、元数据映射）。一旦写操作变多，ReentrantReadWriteLock 反而可能更慢，因为内部状态维护开销比 synchronized 高。

• 读锁可重入，但必须和写锁分开获取；不能在持有写锁时再加读锁（会死锁）
• 默认是非公平策略，读锁和写锁都可能插队；如需严格 FIFO，构造时传 false：new ReentrantReadWriteLock(false)
• 写锁降级是允许的（持有写锁时能直接获取读锁），但读锁升级为写锁会被阻塞——这是设计使然，不是 bug

怎么正确用 readLock() 和 writeLock()

核心就一条：锁必须成对出现，且 unlock() 必须放在 finally 块里。漏掉一次 unlock()，整把锁就卡死，后续所有线程都会 hang 住。

常见错误现象：Thread blocked waiting for lock 日志反复出现，CPU 却不高——八成是某处读锁没释放。

• 读操作：先 readLock.lock()，用完立刻 readLock.unlock()；别在锁内做耗时 IO 或远程调用
• 写操作：必须用 writeLock.lock()，且写完立即 writeLock.unlock()；不要试图在写锁里嵌套读锁
• 推荐写法：用 try-finally，而不是 try-with-resources（Lock 不实现 AutoCloseable）

ReadLock readLock = rwLock.readLock();
readLock.lock();
try {
    return data.get(key); // 纯内存访问
} finally {
    readLock.unlock(); // 这一行不能少，也不能写错对象
}

ReentrantReadWriteLock 的“饥饿”问题怎么破

当读线程太多、写线程一直抢不到锁时，就会发生写饥饿。尤其在非公平模式下，新来的读线程不断插队，老写线程永远排不上。

这不是 bug，是设计取舍：优先保障读吞吐。但如果你的业务要求“写不能等太久”，就得干预。

• 改用公平模式：new ReentrantReadWriteLock(true)，代价是整体吞吐略降
• 给写操作加超时：writeLock.tryLock(1, TimeUnit.SECONDS)，失败则退避重试或走降级逻辑
• 避免在读锁内调用可能触发写操作的方法（比如懒加载 + 双重检查，容易误踩坑）

替代方案：StampedLock 比 ReadWriteLock 更快吗

是的，StampedLock 在多数只读场景下更快，因为它用乐观读（tryOptimisticRead）绕过锁机制，失败才退化为悲观读锁。

但它不支持重入、不支持条件变量、也不兼容 Lock 接口——意味着你没法用 newCondition()，也不能和现有基于 Lock 的工具类混用。

• 乐观读适合「读多、写少、且读逻辑极轻」的场景，比如读一个 long 计数器
• 一旦检测到写发生（stamp 变了），就要重新读+校验，代码逻辑比 ReentrantReadWriteLock 复杂一截
• 注意：StampedLock 的悲观读锁（readLock()）和写锁（writeLock()）仍是可重入的，但乐观读完全不加锁

真正难处理的是混合场景：既有高频只读，又有偶尔批量更新。这时候往往得拆成两层——热字段用 StampedLock，整个结构变更用单独的写锁保护。

本篇关于《读写锁原理及并发优化方法》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于文章的相关知识，请关注golang学习网公众号！