readwritelock 仅适用于读多写少场景，否则性能反降且易死锁；必须严格分离读写操作，禁止锁升级，慎用嵌套与混合锁，合理控制粒度并监控写锁争用。
ReadWriteLock 在处理复杂资源竞争时并不万能，它的适用性高度依赖于访问模式是否符合“读多写少”这一前提。一旦场景偏离这个核心假设，它反而可能引入额外开销甚至死锁风险。
读写行为必须清晰分离
ReadWriteLock 要求你明确区分哪些操作是纯读、哪些是写。如果一个方法既读又写（比如先查缓存再更新），就必须拆解为两段：先用读锁判断，释放后换写锁执行修改——不能在持有读锁期间尝试升级为写锁，这是被禁止的，会直接导致死锁。
- 错误做法：在 readLock() 持有时调用 writeLock().lock()
- 正确做法：先释放 readLock()，再获取 writeLock()；若需“先写后读”，可利用锁降级（writeLock → readLock），但仅限同一线程且顺序严格
- 典型陷阱：对 List 或 Map 做遍历+条件修改时，表面像读，实则隐含写语义，必须统一用写锁保护
写操作频繁时性能反不如普通锁
当写请求占比超过 15%～20%，ReadWriteLock 的调度开销（如维护读锁计数、检查写锁状态）开始抵消并发读带来的收益。尤其在高争用下，大量线程排队等写锁释放，而读锁又因写锁存在被持续阻塞，吞吐量可能低于 ReentrantLock。
- 监控指标建议：关注 writeLock().tryLock() 的失败率和平均等待时间
- 替代方案：写密集场景可考虑分段锁（如 ConcurrentHashMap）、CAS 无锁结构，或按业务维度拆分资源降低冲突
- 注意非公平模式下，写线程可能长期被新进读线程“插队”，造成写饥饿；此时可启用公平模式，但会牺牲整体吞吐
嵌套与组合使用需格外谨慎
ReadWriteLock 不支持跨锁协作。例如，一个方法持有了 A 资源的读锁，又试图获取 B 资源的写锁，若另一线程正持有 B 的读锁并等待 A 的写锁，就极易形成环形等待。
- 避免锁顺序不一致：所有线程必须按固定顺序申请读/写锁（如先 A 后 B）
- 不要混合使用 ReadWriteLock 和 synchronized/ReentrantLock 保护同一资源，语义不兼容易出错
- 若需条件等待（如“等某个值变为 true 再读”），ReadWriteLock 自带的 Condition 不如 ReentrantLock 灵活，通常需配合额外同步机制
资源粒度影响实际效果
锁的粒度太粗（如整个配置对象一把读写锁），写操作仍会成为瓶颈；太细（如为每个字段配独立锁），又失去读共享优势，还增加管理成本。理想粒度应匹配真实并发访问路径。
- 示例：缓存系统中，按 key 分片加锁比全局一把锁更高效；但若 key 访问极不均衡，热点 key 仍会成为瓶颈
- 调试技巧：用 JFR 或 Arthas 观察 lock contention，确认是否真由读写锁本身引发，还是底层数据结构（如 HashMap resize）导致
- 简单场景下，synchronized 往往更轻量——JVM 对其做了大量优化（锁消除、粗化），而 ReadWriteLock 是纯 Java 实现，调用链更长
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
