ReentrantReadWriteLock默认非公平，读线程可插队致写线程饿死；公平模式按FIFO排队但吞吐降15%~30%；不支持锁降级，需用volatile或StampedLock替代；读锁重入未配对unlock会导致写锁永久阻塞；公平模式下批量唤醒读线程仍可能引发写线程“假饥饿”。
ReentrantReadWriteLock 默认是非公平的，读线程可能饿死写线程
默认构造的 ReentrantReadWriteLock 是非公平模式，读锁会持续抢占——哪怕写线程已在队列中等待，新来的读线程仍可能插队获取锁。结果就是写操作迟迟得不到执行，尤其在高并发读场景下，写线程“饿死”是真实发生的。
这不是 bug，是设计使然：非公平模式吞吐更高，但牺牲了写线程的响应性。
- 用
new ReentrantReadWriteLock(true)显式启用公平模式，让线程按 FIFO 顺序排队 - 公平模式下，一旦有线程在等待（无论读或写），后续请求必须排队，不再允许插队
- 注意：公平模式会降低整体吞吐，实测 QPS 可能下降 15%~30%，尤其在读多写少且读操作极轻量时
- 别只看文档说“公平更合理”，先压测对比：加锁开销 + 队列调度延迟是否可接受
读写降级根本不存在，writeLock().unlock() 后不能直接 readLock().lock()
很多人误以为写锁释放后能“自动降级”为读锁，这是对锁语义的根本误解。ReentrantReadWriteLock 不支持降级，写锁释放后当前线程对读锁无任何特权——它得像其他线程一样去竞争读锁。
典型错误现象：IllegalMonitorStateException 或死锁，尤其在嵌套调用、回调或异步场景中。
立即学习“Java免费学习笔记（深入）”；
- 降级需求本质是“我刚改完数据，现在要安全地读它，且不被其他写线程打断”——这需要靠业务逻辑保证，不是锁机制能兜底的
- 可行做法：写操作完成后，用 volatile 字段标记版本号或更新时间戳，读操作检查该标记再决定是否重读；或者用
StampedLock的乐观读 + 验证机制 - 强行在同一线程里先 unlock 写锁再 lock 读锁，等于开放窗口期：中间可能有别的写线程插进来改数据
读锁重入次数过多会导致写锁永久阻塞
读锁可重入，但每次 readLock().lock() 都会增加内部计数器；而写锁获取的前提是：读锁计数为 0 且写锁无人持有。如果某个线程疯狂重入读锁（比如递归读取、循环未释放），又没配对 unlock，写线程就永远卡在 writeLock().lock() 上。
这种问题在线程池复用、异步回调链路中特别隐蔽——你根本看不到是谁 hold 住了读锁。
- 务必检查所有
readLock().lock()是否都有对应readLock().unlock()，推荐用 try-finally 或 try-with-resources（配合自定义 Closeable 包装） - 避免在循环内无条件调用
readLock().lock()；如需多次读，一次 lock 足够，重入即可 - JVM 线程 dump 中留意
java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock的持有栈，结合 jstack -l 查看锁计数
公平模式下仍可能因读锁批量唤醒导致写线程“假饥饿”
即使开了公平模式，JDK 的实现里，当写锁释放时，会**一次性唤醒所有等待的读线程**（而非逐个唤醒），这些读线程拿到 CPU 后立刻抢锁，结果又把刚排到队首的写线程挤到后面——看起来像“写了半天还是轮不到”。这不是公平失效，而是唤醒策略导致的副作用。
这个行为在 JDK 8~21 均存在，官方暂无修改计划。
- 如果你的写操作耗时较长（>10ms），建议拆细：比如把大写操作拆成多个小写+校验步骤，中间穿插短暂 yield 或 sleep(1)
- 监控
getQueueLength()和hasQueuedThreads()，在写锁获取前做简单退避（如Thread.onSpinWait()或短时 park） - 极端场景考虑换
StampedLock：它不区分读/写线程排队，用戳记验证替代阻塞，更适合写不频繁但要求低延迟的场景
