reentrantreadwritelock在读多写多场景下性能急剧下降，甚至劣于普通互斥锁；存在写饥饿、aqs队列膨胀、锁降级风险高、读操作始终阻塞等固有缺陷。
ReentrantReadWriteLock 在读多写多场景下会明显失衡，性能优势迅速瓦解，甚至比普通互斥锁更差。它不是为“写也频繁”的场景设计的，强行使用反而引入额外开销和潜在风险。
写饥饿问题突出
当写线程持续到来时，读锁的共享特性反而成了阻碍：新读线程不断插队获取读锁，导致写线程长期无法获得独占权限。
- 非公平模式下（默认），写线程可能无限期等待；
- 即使启用公平模式，写线程虽能按序排队，但每次唤醒前仍需等待所有已排队读线程完成——若读请求源源不断，写操作响应延迟仍不可控。
锁竞争加剧，AQS队列膨胀
读写锁内部依赖 AQS 管理两个逻辑队列（读等待队列、写等待队列），但实际共用同一同步队列。写多时：
- 写线程入队后，后续读线程若发现写锁被持有时，也会进入阻塞队列；
- 大量线程反复争抢、入队、唤醒，导致节点创建/回收频繁，内存占用上升，上下文切换开销增大。
锁降级带来的隐性成本
虽然支持“写→读”降级（先获写锁，再获读锁，最后释放写锁），但该操作要求：
- 必须在持有写锁期间获取读锁；
- 一旦释放写锁，中间存在极短窗口，其他写线程可能抢先介入，破坏业务一致性；
- 实际编码中需严格校验状态、加额外同步，逻辑复杂度陡增，易出错。
无乐观读机制，读操作始终阻塞
与 StampedLock 不同，ReentrantReadWriteLock 的每次读都需完整获取共享锁：
- 即使数据未被修改，也要走 AQS 共享模式 acquire 流程；
- 在高并发读+中等频率写的混合场景中，这种“保守同步”造成大量不必要的线程挂起与唤醒。
不复杂但容易忽略
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
