ReadWriteLock 的高性能在于写锁不拖累读操作：无写锁时读可并发执行，写锁仅在必要时抢占且快速完成，释放后读线程批量唤醒；其底层依赖 AQS 状态编码、写优先队列及锁降级机制，并需轻量写操作、及时释放、慎用公平模式。
ReadWriteLock 本身不直接“实现”写锁的高性能，而是通过设计机制降低写操作对整体并发的拖累。它的高性能体现在：写锁虽独占，但不会无谓阻塞读操作；同时，写锁获取策略、状态管理与锁降级等机制，共同缓解了传统排他锁在读多写少场景下的性能瓶颈。
写锁的独占性是必要代价，关键在减少等待和干扰
写锁必须互斥——这是数据一致性的底线。ReadWriteLock 的高性能不是靠让写变快，而是让写“不拖累读”。它确保：
- 没有写锁时，读操作完全不受影响，可并发执行，吞吐量接近无锁水平；
- 写锁只在真正需要修改数据时才抢占，且一旦获得，能快速完成（前提是业务逻辑轻量）；
- 写锁释放后，所有等待的读线程可立即批量唤醒，避免逐个竞争。
ReentrantReadWriteLock 的底层优化支撑写锁效率
其高性能写锁依赖 AQS 的精巧状态编码与队列管理：
- 用一个 int（32位）拆分为高16位（读锁计数）和低16位（写锁重入计数），状态变更原子高效；
- 写锁获取采用“独占模式”，AQS 队列中写线程优先于新读线程（尤其在公平模式下），防止写饥饿；
- 支持锁降级：线程可先持写锁修改数据，再不释放地获取读锁，最后释放写锁——避免中间窗口的数据不一致，也省去二次加锁开销。
避免写锁成为性能瓶颈的实际建议
写锁本身很快，慢往往来自使用不当：
立即学习“Java免费学习笔记（深入）”；
- 写操作务必轻量：不要在 writeLock 持有期间做 I/O、远程调用或长循环，否则所有读线程被卡住；
- 及时释放，绝不遗漏：必须用 try-finally 包裹 unlock()，否则写锁长期占用会彻底阻塞系统；
- 慎用公平模式：公平锁虽保障写线程不饿死，但上下文切换开销大；非公平模式（默认）通常吞吐更高；
- 考虑替代方案：若写操作频繁或需乐观更新，StampedLock 的乐观读 + 写锁 或 CAS 类型结构（如 LongAdder）可能更合适。
写锁的高性能，本质是“精准阻塞”与“最小化临界区”的结合。ReadWriteLock 不消除写锁的独占性，而是让这种独占变得可控、可预期、不泛滥。
