ReentrantReadWriteLock 比 synchronized 快因其读写分离：多读不互斥，仅读写/写写互斥；synchronized 一律串行。适用读多写少场景，写多时因状态开销反而更慢。
ReentrantReadWriteLock 为什么比 synchronized 快
因为它是「读写分离」的锁：多个线程同时读不互斥，只有写或读写之间才阻塞。而 synchronized 不管读写，一律串行——哪怕全是只读操作，也得排队。
适用场景很明确：数据结构被频繁读、极少修改（比如配置缓存、路由表、元数据映射）。一旦写操作变多，ReentrantReadWriteLock 反而可能更慢，因为内部状态维护开销比 synchronized 高。
- 读锁可重入，但必须和写锁分开获取；不能在持有写锁时再加读锁（会死锁）
- 默认是非公平策略，读锁和写锁都可能插队；如需严格 FIFO，构造时传
false：new ReentrantReadWriteLock(false) - 写锁降级是允许的（持有写锁时能直接获取读锁），但读锁升级为写锁会被阻塞——这是设计使然，不是 bug
怎么正确用 readLock() 和 writeLock()
核心就一条：锁必须成对出现，且 unlock() 必须放在 finally 块里。漏掉一次 unlock()，整把锁就卡死，后续所有线程都会 hang 住。
常见错误现象：Thread blocked waiting for lock 日志反复出现，CPU 却不高——八成是某处读锁没释放。
立即学习“Java免费学习笔记（深入）”；
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
- 读操作：先
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，整个结构变更用单独的写锁保护。
