Java并发编程中的锁优化与读写锁_技术教程

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 比读写锁更轻量且无锁。

写操作占比超过 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 块中，否则极易泄漏锁。