readwritelock通过读写锁分离提升读多写少场景吞吐量：读锁共享、写锁独占，遵循读读不互斥、读写互斥、写写互斥；锁内仅执行轻量读操作，必须try-finally释放，写操作需保证一致性且避免升级读锁，非公平模式更推荐。
ReadWriteLock 通过把读和写操作的锁分开，让多个读线程能同时执行，而写操作仍保持独占，从而在读多写少场景下显著提升吞吐量。关键不是“加了锁就快”，而是用对方式、避开常见坑。
读写分离是性能提升的根本
普通锁（如 synchronized 或 ReentrantLock）不管读写，一律串行排队；ReadWriteLock 则按操作类型区别对待：
- 读锁是共享的：只要没线程在写，10 个、100 个读请求可几乎同时进入临界区
- 写锁是独占的：写时禁止新读、禁止其他写，但已拿到读锁的线程不受影响，继续执行完
- 读读不互斥、读写互斥、写写互斥——这三条规则决定了并发行为边界
正确用法：锁内只做真正“读状态”的事
读锁里拖太久，写线程就会一直等，反而拖慢整体响应。核心原则是：锁的作用范围越小越好。
- ✅ 正确：查缓存、取 Map 值、读 volatile 字段等轻量级操作放在锁内
- ❌ 错误：远程调用、数据库查询、大对象序列化、耗时计算等必须移出读锁
- 务必用
try-finally保证unlock()执行，否则锁泄漏会卡死后续所有线程
写操作要兼顾安全与及时性
写锁本身不慢，慢的是获取时机——它必须等所有当前读锁释放后才能拿到。
- 更新前确保数据一致性（比如先校验再写，或配合版本号）
- 写完可考虑降级为读锁（先获取读锁，再释放写锁），避免重复查刚写入的数据
- 不要尝试读锁升级为写锁：JVM 不支持，会永久阻塞
- 如果写操作占比超过 20%，锁协调开销可能反超收益，此时应回退到
ReentrantLock
非公平模式通常更合适
new ReentrantReadWriteLock() 默认就是非公平模式，适合绝大多数生产环境：
- 新来的读线程可能插队，略微延长写线程等待时间，但整体吞吐高 15%～30%
- 公平模式唤醒逻辑重、上下文切换多，还无法缓解“大量读锁未释放”导致的写饥饿
- 除非监控发现写锁平均等待超 50ms，否则无需启用公平模式
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
