读写锁是针对“读多写少”场景设计的协作机制，通过分离读锁（可共享）和写锁（独占）提升并发性能，适用于本地缓存、配置热加载等典型场景。
读写锁不是一种“升级版的锁”，而是针对特定访问模式设计的协作机制：它把对共享资源的操作明确区分为“读”和“写”，并按需分配不同性质的锁——读锁可共享，写锁必独占。
读写锁的核心特性
Java 中的 ReadWriteLock 是一个接口，最常用实现是 ReentrantReadWriteLock。它内部维护两个独立但关联的锁：
- 读锁（
readLock()）：可被多个线程同时持有，彼此不互斥；适合只读场景 - 写锁（
writeLock()）：同一时刻仅允许一个线程持有，且会阻塞所有正在申请读锁或写锁的线程 - 读锁与写锁互斥：只要有线程持有了写锁，任何读锁请求都会等待；反之，只要存在活跃读锁，写锁请求也必须等待
- 支持锁降级：写锁可降级为读锁（先写后读时有用），但读锁不能升级为写锁（避免死锁）
- 默认非公平：读写请求不严格按到达顺序调度，吞吐量更高；也可显式启用公平模式
为什么不能直接用 synchronized 或 ReentrantLock？
因为它们都是互斥锁——不管你是读还是写，进来就得排队。在真实业务中，比如配置中心、热点缓存、统计报表数据等场景，读操作可能占 95% 以上，而写操作极少发生。如果每次读都要抢一把独占锁，大量线程会在无意义地空等，白白浪费 CPU 和响应时间。
读写锁正是为这类“读多写少”场景而生：让读操作并发跑起来，只在真正需要修改时才上排他锁。
立即学习“Java免费学习笔记（深入）”；
典型适用场景举例
以下几类问题，用读写锁能明显提升并发吞吐量：
- 本地缓存管理：如 Guava Cache 或自研 Map 缓存，get() 频繁调用，put() 很少更新
- 运行时配置热加载：配置项被大量服务线程读取，仅由管理员或定时任务触发更新
- 只读视图 + 偶尔刷新的数据结构：比如实时排行榜、用户权限快照、聚合指标看板
- 分段读取的大数组或列表：多个线程各自读不同索引，偶有后台线程重置整个结构
使用时要注意的坑
读写锁不是银弹，用错反而拖慢系统：
- 读操作本身不能太耗时，否则会长期霸占读锁，导致写线程饥饿（尤其在高并发读+低频写时）
- 不要在持有读锁期间去尝试获取写锁（会死锁），也不要在读锁内做写操作
- 锁必须成对出现，建议统一用 try-finally 保证 unlock，避免锁泄漏
- 若读写都非常轻量（比如只是几个字段赋值/取值），用 synchronized 可能更轻量，不必引入读写锁的额外状态开销
基本上就这些。用得好，它是并发性能的加速器；用得随意，就成了隐蔽的瓶颈源。
