ReadWriteLock的读锁仅在存在写锁、写锁排队（公平模式）或锁降级未释放写锁时被阻塞；读锁不可升级为写锁，否则死锁；应通过轻量读操作、写合并、绕过锁及监控优化并发性能。
ReadWriteLock 的读锁本身不阻塞其他读锁，但会在特定条件下被阻塞——关键不是“读锁是否阻塞”，而是“读锁何时拿不到”。真正影响读操作并发性的，是写锁的存在和获取时机。
读锁被阻塞的三种典型场景
读锁看似“共享”，但它的获取并非无条件。以下情况会导致线程在调用 readLock.lock() 时被挂起（阻塞）：
- 有线程正持有写锁：这是最常见原因。只要写锁被占用（哪怕只有一毫秒），所有新请求读锁的线程都会排队等待写锁释放。
-
有写锁正在排队等待（且策略为公平锁）：在公平模式下（
new ReentrantReadWriteLock(true)），如果已有写线程在队列中等待，后续读线程即使先发起请求，也会让位于等待中的写线程，从而被阻塞。 - 锁降级后未及时释放写锁：比如某线程先获取写锁、再获取读锁、最后只释放写锁——此时它仍持读锁，但若其他线程在此期间尝试获取写锁，该写锁请求会阻塞后续所有读锁申请（因为写锁请求优先级高于新读请求）。
读锁不阻塞读锁，但可能“饿死”写锁
读锁的高并发性是一把双刃剑。当大量读线程持续涌入，而写操作又相对频繁时，写线程可能长期得不到执行机会——即发生“写饥饿”。这不是读锁主动阻塞写锁，而是写锁在竞争中始终排在队尾。
- 非公平模式（默认）下，新读线程可能不断插队，加剧写饥饿；
- 公平模式虽能缓解，但会牺牲整体吞吐量，读操作响应延迟上升；
- 实践中，若写操作有强时效性（如实时更新配置），需配合超时机制或独立写线程池隔离。
避免误用：读锁不能升级为写锁
一个常见误区是试图在持有读锁时直接获取写锁（即“锁升级”）。这会导致死锁风险，JDK 明确禁止：
Java注释规范Skills
下载
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
立即学习“Java免费学习笔记（深入）”；
- 线程 A 持有读锁 → 尝试 lock writeLock → 阻塞（因自己占着读锁，写锁要求无任何读锁）；
- 此时其他线程也无法获取写锁或新读锁（写锁排队会阻塞后续读）；
- 结果：A 卡住，整个读写链路停滞。
正确做法是：先 unlock() 读锁 → 再 lock() 写锁 → 完成写入 → 如需继续读，可重新获取读锁（即“锁降级”是唯一安全路径）。
实用建议：如何减少读锁阻塞感知
阻塞本身无法完全消除，但可通过设计降低其影响：
- 读操作尽量轻量：避免在 readLock 临界区内做耗时操作（如远程调用、复杂计算），缩短持锁时间；
- 写操作预判与合并：对高频小更新，考虑批量写入或使用 CAS + volatile 替代锁；
- 区分读场景：对一致性要求不高的读取（如监控指标），可绕过读锁，直接读 volatile 字段；
-
监控锁状态：利用
rwl.getReadLockCount()和rwl.isWriteLocked()做运行时诊断，定位长时写锁或读锁堆积点。
不复杂但容易忽略：读锁的“不阻塞”是有前提的，理解这个前提比记住语法更重要。
