ReadWriteLock 是接口，不能直接 new，必须使用其实现类 ReentrantReadWriteLock；读写锁需正确配对加解锁，禁止锁升级，适用读多写少场景。
ReadWriteLock 为什么不能直接 new？
Java 里 ReadWriteLock 是接口，不是具体实现——你写 new ReadWriteLock() 会编译报错。真正能用的是它的标准实现类 ReentrantReadWriteLock，它支持重入、可选公平性，也是 JDK 自带且最常被选中的方案。
常见错误现象：NoClassDefFoundError 或直接编译失败，往往是因为只 import 了接口却没实例化对的类。
- 必须用
new ReentrantReadWriteLock()（默认非公平）或new ReentrantReadWriteLock(true)（公平模式） - 公平模式会降低吞吐量，但能避免写线程饥饿；高并发读场景下，通常用默认非公平就够了
- 别在每次方法调用里 new 一个新锁——它是有状态的，应作为成员变量复用
readLock() 和 writeLock() 怎么配对加解锁？
读锁和写锁是两个独立的 Lock 对象，各自管理自己的 lock() / unlock()，但共享同一套锁状态。用错配对会导致死锁或数据不一致。
典型误用：用 readLock().lock() 加锁，却调用 writeLock().unlock() —— 这不会释放任何锁，还可能掩盖问题。
立即学习“Java免费学习笔记（深入）”；
- 读操作必须配对：先
readLock().lock()，再readLock().unlock() - 写操作同理：
writeLock().lock()→writeLock().unlock() - 推荐用 try-finally（或 try-with-resources 封装），否则异常时 unlock 漏掉，锁就永远卡住
- 示例：
readLock.lock(); try { return data.get(key); } finally { readLock.unlock(); }
什么时候读锁反而比 synchronized 还慢？
读写锁不是银弹。当读操作极短（比如只读一个 volatile 字段）、或读写比例严重失衡（如 99% 写 + 1% 读），ReentrantReadWriteLock 的额外状态维护开销（CAS 更新 state、队列管理、线程唤醒）反而拖慢性能。
容易踩的坑：盲目替换所有 synchronized 为读写锁，结果压测 QPS 下降。
- 适合场景：读多写少（比如 >80% 读）、读操作耗时明显（如查 Map、拼接字符串、简单计算）
- 不适合场景：临界区只有 1–2 行代码；或写操作频繁且不可预测（如高频计数器）
- 注意：
ReentrantReadWriteLock的读锁不排斥其他读锁，但会阻塞写锁；写锁则排斥一切（读+写）——这点和数据库的读写锁语义一致 - 可通过 JMH 做微基准测试，对比
synchronizedvsreadLock在真实业务逻辑下的平均延迟
升级写锁时为什么不能直接 lock(writeLock)？
从读锁“升级”到写锁（即先持读锁，再想拿写锁）是非法操作，ReentrantReadWriteLock 明确禁止——会死锁。因为写锁要等所有读锁释放，而你正拿着读锁不放。
常见错误现象：线程卡在 writeLock.lock()，jstack 显示 BLOCKED，且持有该线程的 readLock 状态未释放。
- 正确做法只有两种：
① 先释放读锁，再获取写锁（但中间存在竞态窗口）
② 直接用写锁保护整个读-改-写流程（如果业务允许） - 若必须“读后再决定是否写”，建议用乐观策略：先读，判断需更新后，释放读锁 → 获取写锁 → 再读一次（防中途被改）→ 更新
- 不要试图用
tryLock()绕过——失败后仍得处理重试或降级逻辑，复杂度陡增
