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 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
立即学习“Java免费学习笔记（深入）”；
- 写操作占比超过 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
