读写分离并发冲突本质是锁策略错配，需在“读多写少+读操作耗时毫秒级”场景才适用reentrantreadwritelock；必须复用锁实例、严格配对加解锁、禁止锁升级、避免依赖瞬时状态判断。
读写分离场景下，并发读写冲突异常的本质不是“锁没加”，而是锁策略错配——用独占锁保护高频读操作，导致大量线程无谓阻塞。ReentrantReadWriteLock 不是万能解药，但只要用对方式，就能从根源上消除这类异常。
明确读写锁适用边界
它只在“读多写少”且读操作耗时明显（毫秒级及以上）时才真正有效。比如缓存查询、配置读取、报表数据加载。若读操作只是取一个 volatile 字段或简单布尔判断，加读锁反而因 CAS 状态更新、队列管理等开销拖慢性能。
- 典型适用：缓存 get()、配置中心 fetchConfig()、只读视图渲染
- 不适用：原子变量读取、极短路径的 if 判断、写占比超 20% 的场景
正确初始化与复用锁实例
ReadWriteLock 是接口，必须用 ReentrantReadWriteLock 实例化；且必须作为类成员变量复用，绝不能在方法内 new。每次新建都会丢失锁状态，等于没锁。
- ✅ 正确：private final ReadWriteLock rwLock = new ReentrantReadWriteLock();
- ❌ 错误：new ReadWriteLock()（编译失败）、new ReentrantReadWriteLock() 写在方法里
- 公平性按需选：默认非公平即可；仅当写线程长期饥饿（如持续写入压力）才启用 new ReentrantReadWriteLock(true)
读写锁严格配对，禁止混用
readLock() 和 writeLock() 返回两个独立 Lock 对象，各自维护自己的加解锁逻辑。用 readLock 加锁却调 writeLock 解锁，或反过来，既不释放锁，也不报错，极易引发死锁或数据不一致。
- 读操作：必须 readLock.lock() → try → finally 中 readLock.unlock()
- 写操作：必须 writeLock.lock() → try → finally 中 writeLock.unlock()
- 锁降级允许（写后立即读）：先 writeLock.lock()，再 readLock.lock()，最后 writeLock.unlock()，此时仍持有读锁
- 绝对禁止锁升级：已持读锁时再尝试获取写锁，会死锁
避免常见状态误判陷阱
读写锁内部通过一个 int 的高低 16 位分别计数读/写线程数。但外部不可直接依赖 getReadingReaders() 等方法做业务逻辑分支——这些值是瞬时快照，无法保证原子性。
- 不要写：if (rwLock.getReadingReaders() == 0) { doWrite(); } —— 条件判断和实际写入之间可能已有新读者进入
- 正确做法：直接 writeLock.lock()，由锁机制天然保证写时无读者
- 写优先模式（默认）下，新读者会在有等待写者时被阻塞，这是设计特性，不是 bug
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
