ReentrantReadWriteLock底层原理与锁降级实战：读写锁缓存设计

做服务端开发的朋友，一定遇到过这种场景：某个配置项或者热点数据被大量线程并发读取，真正写入的线程没几个。你要是图省事，直接给这段代码加个synchronized或者ReentrantLock，功能上确实没毛病，但压测一跑就露馅了——明明全是只读操作，却全部在排队等锁，CPU占用上去了，QPS却上不去，怎么看怎么亏。

ReentrantReadWriteLock就是为这种“读多写少”的场景设计的。它把一把锁拆成两把：读锁和写锁，核心规则只有三条：读读共享、读写互斥、写写互斥。也就是说，多个线程可以同时持有读锁读数据，只有写的时候才需要完全独占。听起来简单，但里面牵扯到AQS状态拆分、锁降级、写锁饥饿这些进阶问题，每个都是面试官和线上事故的高频考点。

这篇文章我会从读写锁的设计动机讲起，拆解它在AQS里的底层实现，再带着你一步一步写出一个生产可用的读写锁缓存，顺便把锁降级这个最容易绕晕的机制讲透。最后整理我在实际项目中踩过的坑和排查思路。无论你是准备面试还是想在项目里真正用对读写锁，这篇都值得看完。

1. 为什么需要读写锁：读多写少场景的锁粒度演进

1.1 synchronized和ReentrantLock的局限性

很多同学在并发编程入门时，逻辑很简单：“多个线程访问共享变量，加锁就完事了”。synchronized和ReentrantLock本质都是互斥锁，也就是说，同一时刻只有一个线程能进入临界区，其他线程全部阻塞等待。这在“读多写少”的场景下问题非常大。

举个例子。我维护过一个配置中心客户端，配置项被几十个业务线程高频读取，只有后台一个定时任务每隔几分钟去刷新一次配置。如果用synchronized锁住整个读取逻辑，那么当一个线程在读取配置时，其他所有线程的读请求都会卡在锁外面。可读取本身是只读操作，并不会破坏数据的完整性，这些线程完全可以并行执行。但互斥锁并不知道你是读还是写，它只能一视同仁地互斥。

你可能会说：“读取加锁不是多余吗？读操作天然线程安全啊。”确实，如果共享数据只有读操作，不加锁也行。问题在于，你无法保证“只有读，没有写”。只要存在写操作，读线程就必须能感知到最新的写入结果，否则会读到旧数据。也就是说，我们需要的是一种“多人可以同时读，但写入必须独占”的锁机制，而不是简单的互斥。

1.2 读写锁的核心思想：三个互斥关系

ReentrantReadWriteLock的设计逻辑可以类比成图书馆。读者们各自拿书看，互不打扰，可以同时存在很多人；但如果管理员要往书架上补新书、调整摆放位置，这时候就得等所有读者合上书、离开当前区域，改完之后读者再进来。读者之间是并发的，读者和管理员之间是互斥的。

对应到锁上，就是三句话：

• 读-读不互斥：只要没有线程持有写锁，所有想获取读锁的线程都能同时拿到读锁，并行执行读逻辑。
• 读-写互斥：如果有线程持有读锁，写锁无法获取；反过来，如果有线程持有写锁，读锁也无法获取。
• 写-写互斥：写锁是独占锁，同一时刻只能有一个线程持有。

为什么读-读不互斥是安全的？因为读操作不改变共享数据的状态，多个线程同时读同一个变量，不会产生数据竞争。而读-写必须互斥，是因为如果写线程在修改数据的同时读线程来读取，读线程可能看到数据修改到一半的中间状态——比如一个HashMap正在扩容，另一个线程来读，轻则读到不完整的键值对，重则直接抛异常。

还要提醒一句：读写锁不是银弹。它的优势只在“读操作占比远大于写操作”时才能发挥出来。如果写操作频率很高，读锁和写锁频繁互斥切换，加上读写锁内部的状态判断比synchronized复杂得多，性能反而可能不如一个简简单单的互斥锁。

2. 源码级拆解：一个int state是怎么装下两把锁的

2.1 state高低16位的切分方案

ReentrantLock内部用AQS的state字段记录锁状态，state == 0表示无锁，大于0表示当前线程的重入次数。到了ReentrantReadWriteLock这里，一个state需要同时记录两把锁的状态：写锁的重入次数，以及所有读线程持有的读锁总数。怎么用一个int装下两组数据？源码给出的方案是按位切分。

java复制static final int SHARED_SHIFT   = 16;
static final int SHARED_UNIT    = (1 << SHARED_SHIFT);
static final int MAX_COUNT      = (1 << SHARED_SHIFT) - 1;
static final int EXCLUSIVE_MASK = (1 << SHARED_SHIFT) - 1;

// 高16位：读锁持有总数
static int sharedCount(int c)    { return c >>> SHARED_SHIFT; }
// 低16位：写锁重入次数
static int exclusiveCount(int c) { return c & EXCLUSIVE_MASK; }

这段代码我建议你背下来。sharedCount(c)把state无符号右移16位，拿到高16位的值，也就是当前所有线程持有读锁的总数量；exclusiveCount(c)把state和0xFFFF做按位与，拿到低16位的值，也就是写锁被同一个线程重入的次数。

为什么用这种方案？因为读写锁的获取和释放本质上是一次更新state的原子操作——读锁获取时给高16位加1，写锁获取时给低16位加1。合在一起，用一次CAS就能完成对整把锁状态的更新，既保证原子性，又避免引入额外的状态字段。

注意MAX_COUNT的值是65535。这意味着读锁最多同时被65535个线程持有（或者一个线程重入65535次），写锁最多重入65535次。正常业务当然不会触顶，但如果你在代码里写出了无限递归加读锁，那这个上限就是最后的防线。真遇到这种bug，别指望锁能救你——它只会安静地让state溢出。

2.2 读锁与写锁的获取释放流程

写锁的获取走的是AQS的独占模式。tryAcquire里会先看高16位：如果state不为0且低16位也是0（说明有线程持有读锁），直接返回失败；如果写锁已经被别的线程持有，也返回失败；只有写锁空闲或者被当前线程重入时才能获取成功。这里的关键判断是“读锁存在时写锁必须等待”，保证数据一致性。

读锁的获取走的是共享模式。tryAcquireShared的逻辑稍微绕一点：

java复制protected final int tryAcquireShared(int unused) {
    Thread current = Thread.currentThread();
    int c = getState();
    // 写锁被占用，且占用者不是当前线程，读锁获取失败
    if (exclusiveCount(c) != 0 && getExclusiveOwnerThread() != current) {
        return -1;
    }
    int sharedCount = sharedCount(c);
    // 读者不需要阻塞，且读锁数量没到上限，CAS更新高16位
    if (!readerShouldBlock() && sharedCount < MAX_COUNT && compareAndSetState(c, c + SHARED_UNIT)) {
        // ...记录firstReader或HoldCounter
        return 1;
    }
    return fullTryAcquireShared(current);
}

注意这里有两个细节。

第一，当写锁被当前线程持有时，当前线程依然可以获取读锁。这就是后面要讲的锁降级的入口。第二，readerShouldBlock()这个方法在不同的公平策略下返回结果不同。非公平锁下，如果阻塞队列队首不是写锁请求者，读线程就可以直接CAS抢锁；公平锁下，只要队列里有更早的等待线程，读线程就必须排队。

读锁释放时，代码里有一个容易踩的坑：如果当前线程并没有持有读锁却调用unlock()，tryReleaseShared里会检查HoldCounter的计数，直接抛出IllegalMonitorStateException。这和synchronized的行为是一致的——锁必须由持锁线程释放。

2.3 可重入设计：HoldCounter和写锁重入计数

可重入是ReentrantReadWriteLock的一个重要特性，但读锁和写锁的可重入实现方式完全不同。

写锁简单，因为写锁是独占锁，它的重入次数直接记录在state的低16位里。同一个线程拿写锁一次，低16位加1，释放一次减1，减到0才真正释放写锁。这个逻辑和ReentrantLock完全一致。

读锁就麻烦了。读锁可以被多个线程同时持有，如果把所有线程的重入次数都累加到一个字段里，释放锁的时候根本分不清每个线程到底该减多少。源码的做法是用一个HoldCounter类记录每个线程自己的读锁重入次数：

java复制static final class HoldCounter {
    int count = 0;
    final long tid = getThreadId(Thread.currentThread());
}

每个线程第一次获取读锁时，会创建一个HoldCounter放到ThreadLocal里，之后每次重入读锁，count加1，释放时count减1，减到0就移除。而state高16位记录的是“所有线程的读锁持有量之和”，每个线程释放时都会把高16位减1。这两个计数各自独立，配合起来才实现了“读锁可重入 + 总数量准确”的效果。

源码里还有firstReader和cachedHoldCounter两个缓存优化，作用分别是记录第一个获取读锁的线程、缓存最后一个获取读锁的线程的HoldCounter，避免频繁操作ThreadLocal带来的性能损耗。这个优化对读多写少场景非常重要，因为读锁的获取释放是极高频操作。

3. 完整实操：手写一个生产可用的读写锁缓存

3.1 第一版：最基础的get/put实现

先来一个最简单的读写锁缓存。用HashMap存数据，用ReentrantReadWriteLock控制并发访问，不用关心缓存淘汰和过期，核心是演示读写锁的用法。

java复制public class ReadWriteCache<K, V> {

    private final Map<K, V> cache = new HashMap<>();
    private final ReentrantReadWriteLock rwl = new ReentrantReadWriteLock();
    private final Lock readLock = rwl.readLock();
    private final Lock writeLock = rwl.writeLock();

    public V get(K key) {
        readLock.lock();
        try {
            return cache.get(key);
        } finally {
            readLock.unlock();
        }
    }

    public void put(K key, V value) {
        writeLock.lock();
        try {
            cache.put(key, value);
        } finally {
            writeLock.unlock();
        }
    }
}

是不是很简单？get方法拿读锁，所有读线程可以并行执行；put方法拿写锁，同一时刻只有一个线程能写入。这个版本已经能解决“读多写少”场景下synchronized过度互斥的问题了。

但要注意一个关键点：finally里的unlock()千万别省略。我在Code Review里见过不少同学在lock()之后直接try-catch返回，忘了在finally释放锁。一旦代码里某个分支抛异常，锁就一直不被释放，其他线程全部卡死。这种问题线上定位特别费劲，因为线程dump看起来全是WAITING状态，根子却是锁泄漏。

3.2 第二版：缓存穿透场景下的锁降级

上面这个最简版本有一个性能隐患：如果缓存里没有数据，get直接返回null，调用方需要再查数据库。在缓存刚启动或者大量缓存失效的高峰期，几十个线程同时发现缓存为空，同时去查数据库，缓存被瞬间打穿。

解决方案是：缓存未命中时，让线程尝试获取写锁去加载数据。但这里有一个非常重要的设计细节——必须使用锁降级，否则会出现重复加载甚至数据错乱。看代码：

java复制public V get(K key) {
    readLock.lock();
    try {
        V value = cache.get(key);
        if (value == null) {
            // 缓存未命中，释放读锁，准备获取写锁
            readLock.unlock();
            writeLock.lock();
            try {
                // 双重检查：可能其他线程已经加载过了
                value = cache.get(key);
                if (value == null) {
                    value = loadFromDB(key);
                    cache.put(key, value);
                }
                // 锁降级：在持有写锁时获取读锁
                readLock.lock();
            } finally {
                writeLock.unlock();
            }
        }
        return value;
    } finally {
        readLock.unlock();
    }
}

private V loadFromDB(K key) {
    // 模拟从数据库加载，这里加入耗时，方便观察并发行为
    try {
        Thread.sleep(50);
    } catch (InterruptedException e) {
        Thread.currentThread().interrupt();
    }
    return (V) ("value-" + key);
}

这段代码的流程是：先拿读锁检查缓存，没命中就释放读锁，拿写锁重新检查一次缓存（double check），还是空就从数据库加载并写入，然后在释放写锁之前先获取读锁，最后再释放写锁。

为什么一定要先获取读锁再释放写锁？因为在释放写锁和再次获取读锁之间，可能会有一个新的写线程抢到写锁，把数据改掉。如果不做降级，当前线程返回给调用方的value就不是最新值。而做了锁降级之后，当前线程在返回数据时仍然持有读锁，这就保证了它返回的数据一定是自己刚写入的那个版本，不会被其他写线程覆盖掉。一句话总结：锁降级是为了保证当前线程后续操作期间，数据不会被其他写线程修改。

loadFromDB这个方法我故意加了50毫秒的模拟耗时，用来说明为什么双重检查是必要的。如果没有双重检查，两个线程同时发现缓存为空，都会去查数据库，缓存穿透的问题依然存在。加上双重检查后，第二个线程在拿到写锁后会先看缓存，发现有值了就直接跳过加载。

3.3 并发压测验证：性能提升和适用边界

为了验证读写锁的性能效果，我写了一个轻量级的压测demo。用CountDownLatch控制线程同时出发，模拟8个线程并发读同一个缓存key，统计总耗时。

java复制public static void main(String[] args) throws InterruptedException {
    int threadCount = 8;
    int loopCount = 100000;
    ReadWriteCache<String, String> cache = new ReadWriteCache<>();
    cache.put("key", "init");

    ExecutorService pool = Executors.newFixedThreadPool(threadCount);
    CountDownLatch start = new CountDownLatch(1);
    CountDownLatch end = new CountDownLatch(threadCount);

    for (int i = 0; i < threadCount; i++) {
        pool.execute(() -> {
            try {
                start.await();
                for (int j = 0; j < loopCount; j++) {
                    cache.get("key");
                }
            } catch (InterruptedException e) {
                Thread.currentThread().interrupt();
            } finally {
                end.countDown();
            }
        });
    }

    long begin = System.currentTimeMillis();
    start.countDown();
    end.await();
    System.out.println("耗时: " + (System.currentTimeMillis() - begin) + "ms");
    pool.shutdown();
}

我换过三种实现跑的对比：

结论很明确：在纯读场景下，读写锁比synchronized有数量级上的提升，和不加锁的性能差距已经很小了。但如果把场景改成50%读、50%写，读写锁因为频繁在读写模式间切换，性能反而可能不如synchronized。所以选型前先统计业务流量里的读写比例，别盲目上读写锁。

4. 常见问题与排查技巧实录

4.1 写锁饥饿：非公平锁下的大坑

非公平锁下，读写锁存在一个经典问题——写锁饥饿。因为读锁是共享锁，只要有一个读线程持有读锁，其他读线程就能源源不断地获取读锁。如果读操作非常频繁，写锁会在AQS阻塞队列里长时间等待，甚至可能等到超时或被饿死。

场景还原：一个调用量很高的缓存服务，读请求QPS有几万，后台一个刷新线程需要定期更新缓存。如果使用默认的非公平策略，刷新线程去获取写锁时，队列前面可能总是一堆读锁请求，它就一直等不到锁。线上表现就是缓存的更新延迟越来越长，数据过期时间到了也不刷新。

解决办法有两个。第一，构造时传入true使用公平锁：

java复制ReentrantReadWriteLock rwl = new ReentrantReadWriteLock(true);

公平锁下，锁的获取严格按照AQS队列的先后顺序，新来的读线程看到队列里有写锁请求时，会自动排队等待，给写锁留出执行机会。代价是部分吞吐量，因为线程不再能插队抢锁。

第二，如果你的业务能接受“写锁获取失败就放弃本次更新”，可以用tryLock带超时：

java复制if (writeLock.tryLock(100, TimeUnit.MILLISECONDS)) {
    try {
        // 更新缓存
    } finally {
        writeLock.unlock();
    }
}

我个人在实际项目中更倾向于用公平锁。虽然损失了一部分读并发，但换来的是确定性的锁获取顺序，线上出问题的概率小很多。吞吐量如果不够，优先扩容而不是跟锁的非公平性较劲。

4.2 锁升级为什么是死锁

面试高频题来了：读写锁支持锁升级吗？也就是说，一个线程持有读锁，能不能直接获取写锁？答案是不支持，而且这种写法会直接死锁。

原因很简单：写锁的获取条件是“等待所有读锁释放”。如果当前线程持有读锁，再去获取写锁，它必须先等自己持有的读锁释放，但读锁的释放又需要等写锁获取成功之后才能继续执行。这就是典型的“自己等自己”——线程永远等不到自己释放锁。

用代码演示更直观：

java复制readLock.lock();
try {
    // 这段代码会死锁
    writeLock.lock();
    try {
        // 更新数据
    } finally {
        writeLock.unlock();
    }
} finally {
    readLock.unlock();
}

正确的姿势是先释放读锁，再获取写锁，像上面缓存demo的那样。这也是为什么我在3.2里强调“缓存未命中时要先释放读锁再拿写锁”，很多新手在写这段逻辑时会下意识地在读锁保护范围内直接调writeLock.lock()，然后线上就死锁了。

锁降级则相反，是安全的方向：持有写锁时获取读锁，再释放写锁。因为读锁的获取条件比写锁宽松，写锁持有者本来就有权限读取数据，降级只是降低锁的强度，不会产生死锁。记住一个口诀：升级死锁，降级安全。

4.3 读锁保护下修改数据：隐蔽的数据错乱

还有一种隐蔽的错误写法：线程持有了读锁，然后在读锁保护的代码块里，顺手修改了共享的集合或变量。表面上看，读锁保证了“不会和写锁并发”，但读锁和读锁之间是不互斥的——两个线程同时持有读锁，同时修改同一个HashMap，数据一定会错乱。

我在一个老项目里排查过这种问题。业务方在“读”接口里做了一点点统计操作，往一个全局List里add了一条记录。因为调用量高，读锁让多个线程并行进入，结果这个List频繁出现数据错乱，偶发ConcurrentModificationException。最后定位到问题，把统计逻辑改成幂等写入独立队列，所有共享集合的修改统一放到写锁保护下，问题才消除。

这里要强调的是：ReentrantReadWriteLock的语义是“读的时候不能写，写的时候不能读”，但它不会替你把“读”和“写”的操作分开。你必须从代码层面保证，凡是修改共享数据的代码，必须持有写锁；凡是读共享数据的代码，至少持有读锁。如果读锁下面藏了写操作，锁本身是拦不住你的。

4.4 与StampedLock对比：读写锁不是终点

JDK 8引入了StampedLock，提供了三种模式：写锁、悲观读锁、乐观读。乐观读不实际加锁，只是记录一个版本号（stamp），读取完成后用validate校验版本号有没有变化，如果有变化再升级为悲观读锁重读。

java复制long stamp = lock.tryOptimisticRead();
V value = cache.get(key);
if (!lock.validate(stamp)) {
    stamp = lock.readLock();
    try {
        value = cache.get(key);
    } finally {
        lock.unlockRead(stamp);
    }
}

StampedLock在读多写极少的场景下性能比ReentrantReadWriteLock更好，因为乐观读完全不加锁，连CAS都省了。但它的缺点也很明显：不可重入、API复杂、容易误用、不支持条件变量。而且StampedLock的悲观读锁之间是互斥的，这跟读写锁完全不同。

我做过一个简单的对比表格，方便你选型：

说实话，大部分业务场景用ReentrantReadWriteLock就够了。StampedLock虽然性能上限更高，但非重入和对API理解要求极高的特性，让它成了并发bug的温床。真要上StampedLock，建议先在压测环境充分验证，并且做好代码Review的强度准备。

5. 我的几点实战经验

最后分享几个我在实际项目里积累的经验，算是对这个主题的补充。

写锁饥饿这个问题，我在一个配置中心项目里真实遇到过。当时用的是默认非公平锁，读QPS很高，后台刷新线程每天总有几次获取不到写锁，导致配置更新延迟。后来切到公平锁，更新延迟基本稳定在几十毫秒以内。如果你对“某个写线程必须在一定时间内拿到写锁”有要求，公平锁是成本最低的解决方案。

锁降级的场景，我建议只在“缓存未命中需要回源加载”这种有明确数据流转逻辑的地方使用，别在一开始写代码时就天马行空地加。降级本身会让代码的可读性下降，超过两层的嵌套锁很容易把后续维护的人绕晕。我见过一个项目，为了“优化”在get方法里增加了锁降级，结果后来改动的人不理解逻辑，多加了几个分支，直接把死锁问题引了进来。

还有一个细节：读锁释放一定要放在finally里，写锁也一样。Java的锁不像try-with-resources那样能自动释放，漏一个unlock()就是线上事故。每次Code Review重点检查lock()之后有没有配套的finally-unlock，这个习惯能帮你挡掉不少问题。

ReentrantReadWriteLock这个东西，本质上是用“更复杂的锁状态管理”换“更高的并发度”。它适合读多写少、业务逻辑清晰的场景，但并不适合所有并发问题。如果你的数据几乎不写，可以考虑CopyOnWriteArrayList或者不可变对象加volatile引用，连读写锁都不需要；如果写操作很频繁，老老实实回到互斥锁反而更稳。选锁，本质上是选一种和业务特征匹配的并发策略。