ReentrantReadWriteLock通过读写分离提升并发度：读-读不互斥，读-写/写-写互斥；支持锁降级、重入、公平性与中断响应。
ReentrantReadWriteLock 不靠“锁住一切”来保安全，而是用读写分离的逻辑，在保障数据一致性的同时，把并发度拉上来。它不阻止读，只在真正需要排他修改时才出手——这才是对线程安全性更精细、更务实的保障。
读-读不互斥，但绝非放任自流
多个线程同时读取共享资源是被允许的，前提是：没有写操作正在发生，或当前读线程自己刚持有过写锁（锁降级场景）。这种“共享”不是无条件的，底层通过 AQS 的共享模式控制，所有读线程共享同一把逻辑读锁，状态由 state 高 16 位统一计数。只要写锁未被占用（或仅被本线程持有），读操作就能并行进入，既提速又不失安全。
- 读锁获取时会检查写锁持有者是否为当前线程——这是锁降级的前提
- 一旦有线程持写锁，后续所有读请求都会被阻塞，直到写锁释放
- 读锁可重入，同一线程可多次 acquire，计数累加；unlock 次数必须匹配
写锁独占，且自带重入与线程归属校验
写锁是典型的独占式锁，同一时刻最多一个线程能持有。但它不是简单地“谁抢到谁写”，而是严格绑定线程身份：只有当前持有写锁的线程才能再次 lock，其他线程哪怕尝试一次也会排队等待。state 的低 16 位记录重入次数，最大支持 65535 次，避免整型溢出导致异常行为。
- 获取写锁前，会原子判断 state 是否为 0（无任何锁）或仅被当前线程持有（重入）
- 若存在读锁（高 16 位 > 0）且持有者不是当前线程，写锁获取失败
- 写锁释放时，仅当重入计数归零才真正清空写状态，唤醒等待队列
锁降级机制堵住“写后读”的数据一致性漏洞
这是 ReentrantReadWriteLock 对线程安全性最精妙的一层加固。它允许线程在持有写锁期间，再获取读锁，然后释放写锁——从而无缝过渡到只读状态。这个设计专门防范“写完立刻读，中间却被别的写线程插队修改”的经典竞态窗口。
立即学习“Java免费学习笔记（深入）”；
- 降级必须按顺序：writeLock.lock() → readLock.lock() → writeLock.unlock()
- 跳过 readLock.lock() 直接 unlock 写锁，就可能读到其他线程刚写入的新值
- 降级后，该线程仍受读锁保护，其他写线程无法介入，读操作看到的是自己写入后的一致快照
公平性与可中断性增强可控性
构造时可选 fair = true，使等待线程按 FIFO 顺序获取锁，避免饥饿；所有 lock() 方法都支持响应中断（interrupt），配合 tryLock(timeout) 可主动放弃争抢，防止死等。这些不是锦上添花，而是在线程协作复杂、响应要求高的系统中，确保安全边界不因调度或异常而失控的关键能力。
- 非公平模式吞吐更高，适合读多写少且写冲突不频繁的场景
- 公平模式虽略慢，但在长任务写操作+高并发读下，能更好保障响应确定性
- lockInterruptibly() 让线程能在被阻塞时被外部中断，避免无限挂起
