ReadWriteLock 比 synchronized 更适合读多写少场景，因其允许多个线程并发读、写操作独占，显著提升吞吐量；但需注意读锁不保证数据最新性、不可升级为写锁、写频繁或临界区短时反而更差。
ReadWriteLock 为什么比 synchronized 更适合读多写少场景
因为 ReadWriteLock 允许多个线程同时读，但写操作独占；而 synchronized 不管读写都强制串行。在读操作远多于写操作时，用 ReentrantReadWriteLock 能显著提升吞吐量。
常见错误是误以为“加了读锁就绝对线程安全”——其实读锁只保证读期间不被写干扰，不保证读到的数据是最新的（除非配合 volatile 或其他同步机制）。
- 读锁可重入，但多个线程获取读锁不会阻塞彼此
- 写锁是排他锁，一旦有线程持有写锁，所有读/写请求都会阻塞
- 写锁可降级为读锁（调用
writeLock().unlock()后再readLock().lock()），但读锁不能升级为写锁（会死锁） -
ReentrantReadWriteLock默认是非公平模式，可通过构造参数启用公平策略：new ReentrantReadWriteLock(true)，但公平性会降低吞吐量
什么时候不该用 ReentrantReadWriteLock
当写操作频繁、或读操作本身很轻量（比如只读一个字段）、或临界区极短时，ReentrantReadWriteLock 的锁状态维护开销反而可能超过 synchronized。
典型反例：缓存计数器的 get/set。如果只是 return count; 和 count++;，用 AtomicInteger 比读写锁更轻量且无锁。
立即学习“Java免费学习笔记（深入）”；
PHP网络编程技术详解由浅入深，全面、系统地介绍了PHP开发技术，并提供了大量实例，供读者实战演练。另外，笔者专门为本书录制了相应的配套教学视频，以帮助读者更好地学习本书内容。这些视频和书中的实例源代码一起收录于配书光盘中。本书共分4篇。第1篇是PHP准备篇，介绍了PHP的优势、开发环境及安装；第2篇是PHP基础篇，介绍了PHP中的常量与变量、运算符与表达式、流程控制以及函数；第3篇是进阶篇，介绍
- 写操作占比超过 10%～20%，需实测对比吞吐量
- 读操作中包含复杂逻辑（如遍历集合、IO、锁内调用外部方法），容易让读锁持有时间过长，导致写饥饿
- 使用
StampedLock替代更合适：它支持乐观读（tryOptimisticRead），在无写竞争时几乎零开销
StampedLock 的乐观读怎么避免 ABA 问题
StampedLock 的乐观读不加锁，靠版本戳（stamp）校验是否被写过。但它本身不解决 ABA，而是把校验责任交给使用者——你必须在读取后显式调用 validate(stamp)，并根据返回值决定是否重试。
long stamp = sl.tryOptimisticRead();
int current = x;
if (!sl.validate(stamp)) {
// 发生了写操作，降级为悲观读
stamp = sl.readLock();
try {
current = x;
} finally {
sl.unlockRead(stamp);
}
}
- 乐观读只适用于读取简单、无副作用的变量；不能用于读取对象引用后再调用其方法（可能已失效）
- 多次读取多个字段时，必须用同一个 stamp 校验，否则中间可能被写入干扰
- stamp 为 0 表示当前处于写模式，此时
validate(0)总是返回 false
锁粗化与锁消除在读写锁场景下基本无效
JIT 编译器的锁消除（lock elision）和锁粗化（lock coarsening）主要针对 synchronized 块，对 ReentrantReadWriteLock 和 StampedLock 不起作用——它们是普通 Java 对象，锁逻辑在用户代码里，编译器无法静态分析。
这意味着：你写的每一对 readLock().lock() / readLock().unlock() 都真实执行，不会被优化掉。所以务必确保 unlock 在 finally 块中，否则极易泄漏锁。
- 忘记在 finally 中 unlock 是最常见 bug，会导致后续所有读写永久阻塞
- 不要在锁内做耗时操作（如日志、网络调用），尤其读锁——它会拖慢所有写线程
- 用
try-with-resources包装锁不适用，因为Lock接口未实现AutoCloseable
