ReentrantReadWriteLock 不能直接替代 synchronized，因其需手动调用 lock() 和 unlock()，遗漏 unlock() 会导致死锁或饥饿；读锁不可升级为写锁，否则易引发死锁；必须用 try-finally 确保解锁；公平模式降低吞吐但防写饥饿。
ReentrantReadWriteLock 为什么不能直接替代 synchronized
因为 ReentrantReadWriteLock 不是语法糖，它不自动管理锁的获取与释放，必须显式调用 lock() 和 unlock()；而 synchronized 是 JVM 层保障的自动加解锁。一旦忘记在 finally 块中调用 unlock()，就会导致写线程永久阻塞或读线程饥饿。
读锁和写锁的获取规则与典型误用
读锁可被多个线程同时持有，但写锁是独占的；更重要的是：写锁可以降级为读锁（通过先获取写锁再获取读锁），但读锁**不能升级为写锁**——这是常见死锁源头。
- 错误写法：
readLock.lock(); writeLock.lock();→ 极大概率死锁，因为其他线程可能正持读锁，而写锁在等所有读锁释放 - 正确降级示例：
writeLock.lock(); try { // 修改数据 data = newValue; // 再获取读锁（此时仍持有写锁，安全） readLock.lock(); writeLock.unlock(); // 释放写锁，保留读锁 } catch (Exception e) { writeLock.unlock(); throw e; } - 读锁不排斥读锁，但会阻塞写锁；写锁则排斥一切读/写锁
如何避免 lock() / unlock() 配对遗漏
最稳妥的方式是把加锁逻辑封装进工具方法，强制走 try-finally 路径。不要依赖 try-with-resources（ReentrantReadWriteLock.ReadLock 和 WriteLock 并未实现 AutoCloseable）。
- 推荐模式：
readLock.lock(); try { return data; // 仅读操作 } finally { readLock.unlock(); } - 写操作同理：
writeLock.lock(); try { data = computeNewValue(); } finally { writeLock.unlock(); } - 注意：
lockInterruptibly()可响应中断，适合需要取消等待的场景；普通lock()会一直阻塞
公平性设置对性能和吞吐的影响
ReentrantReadWriteLock 默认是非公平的（构造函数传 false 或无参），意味着新来的读线程可能插队已等待的写线程，造成写饥饿。设为公平（true）能保证 FIFO，但显著降低吞吐量——尤其在高并发读场景下。
立即学习“Java免费学习笔记（深入）”；
- 非公平模式：适合读多写少、对写延迟不敏感的缓存类场景
- 公平模式：适合写操作有强时效要求（如配置热更新、状态同步），且写频次不低的情况
- 公平锁的代价不仅是调度开销，还在于每次
lock()都需检查队列头，影响 CPU cache line 利用率
