读写锁通过读共享、写独占解决读多写少场景的串行瓶颈，核心是遵守读读不互斥、读写互斥、写写互斥规则，锁内仅做轻量操作并用try-finally确保解锁，非公平模式更优。

读写锁通过让读操作并行、写操作独占，直接解决“读多写少”场景下普通锁的串行瓶颈，从而提升并发度。关键不在加锁本身，而在如何用对规则、避开典型误用。

读锁共享，写锁互斥是并发提升的底层逻辑

普通锁（如 synchronized 或 ReentrantLock）对所有线程一视同仁，读和写都排队——100 个读请求只能一个接一个执行。而 ReentrantReadWriteLock 拆成两把锁：

• 读锁可重入且共享：只要没线程在写，任意数量的读线程能同时进入临界区
• 写锁排他且独占：获取时必须等所有当前读锁释放；持有期间会阻塞新读、新写请求
• 三条互斥规则必须清楚：读读不互斥、读写互斥、写写互斥

锁内只做真正轻量的读/写，否则并发优势归零

锁的作用不是“包住整个方法”，而是精准保护共享状态的访问。耗时操作留在锁外，才能避免拖慢其他线程：

deep-java-review

Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...

下载

• ✅ 读锁内适合：查 HashMap、取 volatile 字段、判断布尔标志
• ❌ 读锁内禁止：远程调用、DB 查询、JSON 序列化、大对象拷贝
• ✅ 写锁内适合：更新 Map、设置字段、校验后写入
• ❌ 写锁内避免：同步发消息、调外部 HTTP、复杂计算（应提前算好再写）

必须用 try-finally 保证解锁，且不能读锁升级写锁

忘记释放锁或错误升级，会导致线程永久阻塞，比不用锁还危险：

• 所有 lock() 后必须配对 unlock()，且放在 finally 块中
• 读锁持有期间调 writeLock().lock() 会死锁——JVM 不支持升级
• 唯一允许的转换是锁降级：先持写锁 → 再获取读锁 → 最后释放写锁，仍保有读锁
• 若读中发现需写，应先释放读锁，再申请写锁（即“双重检查锁定”的变体）

非公平模式更适配大多数生产场景

默认构造的 ReentrantReadWriteLock() 是非公平的，这不是缺陷，而是权衡后的优化：

• 新来的读线程可能插队，略微延长写线程等待，但整体吞吐高 15%～30%
• 公平模式唤醒开销大，且无法缓解“大量读锁长期未释放”导致的写饥饿
• 仅当监控到写锁平均等待超 50ms，才考虑启用公平模式（new ReentrantReadWriteLock(true)）

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南