ReentrantReadWriteLock源码解析

一 概述

ReentrantReadWriteLock从字面意思上就是可重入的读写锁。读写锁的特点就简单来说就是读读之间不互斥，读写或写写之间是互斥的。今天就通过它来解开读写锁的秘密。由于这个类名称太长，后面都简称它为RRWLock。

二 案例

在解读RRWLock时，先简单看下源码中提供的一个使用场景案例（代码如下），这是一个缓存的实例，因为缓存的特点就是读大于写的，这也符合RRWLock的特性。

class CachedData {
// 实际的缓存数据
Object data;
// 缓存有效标识
volatile boolean cacheValid;
// 读写锁
final ReentrantReadWriteLock rwl = new ReentrantReadWriteLock();

// 处理缓存数据
void processCachedData() {
    // 先加上读锁
    rwl.readLock().lock();
    // 如果缓存无效，即不存在时，执行加载缓存操作
    if (!cacheValid) {
        // 写缓存要获取写锁，但是获取写锁之前要释放读锁
        rwl.readLock().unlock();
        rwl.writeLock().lock();
        try {
            // Recheck state because another thread might have
            // acquired write lock and changed state before we did.
            // 再获取到写锁后再次判断缓存是否已被其他线程加载了(因此在lock()可能会出现自旋或阻塞等待的情况，期间其他线程可能会进行加载缓存的操作))
            if (!cacheValid) {
                // 加载缓存
                data = ...;
                // 更新缓存有效标识
                cacheValid = true;
            }
            // Downgrade by acquiring read lock before releasing write lock
            // 在释放写锁前先获取到读锁
            rwl.readLock().lock();
        } finally {
            // 释放写锁，此时仍持有读锁
            rwl.writeLock().unlock(); // Unlock write, still hold read
        }
    }

    try {
        // 使用缓存数据
        use(data);
    } finally {
        // 使用完后释放读锁
        rwl.readLock().unlock();
    }
}

}

复制代码简单总结下这个缓存案例的加锁流程：

首先获取到读锁，然后检查缓存是否有效，若有效则直接使用后释放读锁并结束；
如果获取到读锁后检查缓存为无效，则需要重新加载缓存数据，此时需要获取写锁，但是在获取写锁前必须释放读锁；
获取到写锁后再次检查缓存是否有效，避免因在获取写锁自旋或阻塞等待期间，其他线程加载了缓存的问题；
重新加载缓存并更新缓存标识为有效；
在释放写锁前先获取到读锁，避免先释放写锁，写锁立刻被其他线程获取并更新了缓存，之后再获取读锁读取的数据变成脏数据的问题；
使用缓存数据，并在用完后是否读锁；

这里先抛出2个问题，在文末有答案分析：

为什么获取写锁前要先释放读锁？
为什么释放写锁前要先获取读锁？

...内部具体源码解析 参考文末---原文链接

九 问题解答

在开篇讲完读写锁的案例后提出了两个问题，源码解析后再来回答下这个问题。
解答问题之前，先简单介绍下读写锁的一些概念：

锁升级：由读锁升级为写锁（即持有读锁的线程直接获取写锁）

锁降级：由写锁降级为读锁（即持有写锁的线程直接获取读锁）

第一个问题：为什么获取写锁前要先释放读锁？
从源码来解答就是获取写锁前会先检查锁状态是否含有读锁，并且它没有区分该读锁持有者是否为自己，如果发现存在读锁则会加入AQS队列自旋或阻塞等待。如下所示：
Thread current = Thread.currentThread();
int c = getState();
int w = exclusiveCount(c);
if (c != 0) {
// (Note: if c != 0 and w == 0 then shared count != 0)
if (w == 0 || current != getExclusiveOwnerThread())
return false;
……
}
复制代码其实这里讨论的就是锁升级的问题，从源码也可以看出，RRWLock是不支持锁升级的。因此，如果没有释放读锁而直接去获取写锁，会导致写锁阻塞。案例中如果当前线程持有读锁不释放直接获取写锁会发现死锁等待的问题。
第二个问题：为什么释放写锁前要先获取读锁？
这其实就是锁降级问题，首先说明的是，RRWLock是支持锁降级的。从获取读锁的过程中就可以看出：
Thread current = Thread.currentThread();
int c = getState();
// 如果独占锁不为空，并且持有独占锁的非当前线程才会直接失败返回
if (exclusiveCount(c) != 0 && getExclusiveOwnerThread() != current)
return -1;
复制代码在这个场景中，如果不是采用锁降级的方式，而是直接先释放写锁再去获取读锁的话，会存在这样的问题：当修改完数据并释放写锁后，读锁参与竞争锁，但是另一个写锁请求先获取到了，那么当前的读锁线程就得等待，另一个写锁线程修改完数据后释放锁，当前读锁获取到的数据已经是被修改之后了，而不是当时修改的，此时产生了脏读的问题，因此此处使用锁降级的方案能避免此问题。
通过上述两个问题，可以知道：RRWLock支持锁降级，不支持锁升级

十 总结

行文至此，RRWLock的原理也基本都讲完了，最后也简单总结下它的特点：

内部含有两把锁，读锁和写锁，允许共享读锁，但是写锁是独占锁，即同一时刻只允许一个线程进行写操作，读则允许多线程读。
内部锁的实现是通过AQS来实现的，存在读锁或写锁时，写请求加入AQS队列阻塞等待。而读请求只在存在写锁下才加入AQS队列阻塞等待。
支持锁重入，读锁使用ThreadLocal的子类为每个线程存放锁的重入次数，写锁直接使用锁状态的低位来记录锁重入次数。
RRWLock使用于读请求多但写操作少的场景中。

原文学习地址:https://juejin.im/post/5d4cdb0ae51d4561e0516ab4