ReadWriteLock：读多写少场景利器

什么是读写锁

读写锁，并不是 Java 语言特有的，而是一个广为使用的通用技术，所有的读写锁都遵守以
下三条基本原则：

• 允许多个线程同时读共享变量；
• 只允许一个线程写共享变量；
• 如果一个写线程正在执行写操作，此时禁止读线程读共享变量。

读写锁与互斥锁的一个重要区别就是读写锁允许多个线程同时读共享变量，而互斥锁是不允
许的，这是读写锁在读多写少场景下性能优于互斥锁的关键。但读写锁的写操作是互斥的，
当一个线程在写共享变量的时候，是不允许其他线程执行写操作和读操作。

快速实现一个缓存

在下面的代码中，我们声明了一个 Cache<K, V> 类，其中类型参数 K 代表缓存里 key 的
类型，V 代表缓存里 value 的类型。缓存的数据保存在 Cache 类内部的 HashMap 里面，
HashMap 不是线程安全的，这里我们使用读写锁 ReadWriteLock 来保证其线程安全。
ReadWriteLock 是一个接口，它的实现类是 ReentrantReadWriteLock，通过名字你应该
就能判断出来，它是支持可重入的。下面我们通过 rwl 创建了一把读锁和一把写锁。

class Cache<K,V> {
   final Map<K, V> m = new HashMap<>();
   final ReadWriteLock rwl = new ReentrantReadWriteLock();
   // 读锁
   final Lock r = rwl.readLock();
   // 写锁
   final Lock w = rwl.writeLock();
   // 读缓存
   V get(K key) {
     r.lock();
     try { return m.get(key); }
     finally { r.unlock(); }
   }
   // 写缓存
   V put(String key, Data v) {
     w.lock();
     try { return m.put(key, v); }
     finally { w.unlock(); }
   }
}

如果你曾经使用过缓存的话，你应该知道使用缓存首先要解决缓存数据的初始化问题。缓存
数据的初始化，可以采用一次性加载的方式，也可以使用按需加载的方式。
如果源头数据的数据量不大，就可以采用一次性加载的方式，这种方式最简单（可参考下
图），只需在应用启动的时候把源头数据查询出来，依次调用类似上面示例代码中的 put()
方法就可以了。

如果源头数据量非常大，那么就需要按需加载了，按需加载也叫懒加载，指的是只有当应用
查询缓存，并且数据不在缓存里的时候，才触发加载源头相关数据进缓存的操作。下面你可
以结合文中示意图看看如何利用 ReadWriteLock 来实现缓存的按需加载。

缓存按需加载的实现

如果缓存中没有缓存目标对象，那么就需要从数据库中加载，然后写入缓存，写缓存需要用到写锁，所以在代码中的⑤处，我们调用了 w.lock() 来获取写锁。另外，还需要注意的是，在获取写锁之后，我们并没有直接去查询数据库，而是在代码⑥⑦处，重新验证了一次缓存中是否存在，再次验证如果还是不存在，我们才去查询数据库并更新本地缓存。这是为什么呢？

class Cache<K,V> {
   final Map<K, V> m = new HashMap<>();
   final ReadWriteLock rwl = new ReentrantReadWriteLock();
   final Lock r = rwl.readLock();
   final Lock w = rwl.writeLock();
   V get(K key) {
     V v = null;
     // 读缓存
     r.lock(); ①
     try {
       v = m.get(key); ②
     } finally{
     r.unlock(); ③
   }
   // 缓存中存在，返回
   if(v != null) { ④
      return v;
   }
   // 缓存中不存在，查询数据库
   w.lock(); ⑤
   try {
     // 再次验证
     // 其他线程可能已经查询过数据库
     v = m.get(key); ⑥
     if(v == null){ ⑦
     // 查询数据库
       v= 省略代码无数
       m.put(key, v);
     }
   } finally{
   w.unlock();
  }
  return v;
 }
}

原因是在高并发的场景下，有可能会有多线程竞争写锁。假设缓存是空的，没有缓存任何东
西，如果此时有三个线程 T1、T2 和 T3 同时调用 get() 方法，并且参数 key 也是相同的。
那么它们会同时执行到代码⑤处，但此时只有一个线程能够获得写锁，假设是线程 T1，线
程 T1 获取写锁之后查询数据库并更新缓存，最终释放写锁。此时线程 T2 和 T3 会再有一
个线程能够获取写锁，假设是 T2，如果不采用再次验证的方式，此时 T2 会再次查询数据
库。T2 释放写锁之后，T3 也会再次查询一次数据库。而实际上线程 T1 已经把缓存的值设
置好了，T2、T3 完全没有必要再次查询数据库。所以，再次验证的方式，能够避免高并发
场景下重复查询数据的问题。

读写锁的升级与降级

上面按需加载的示例代码中，在①处获取读锁，在③处释放读锁，那是否可以在②处的下面
增加验证缓存并更新缓存的逻辑呢？

  // 读缓存
  r.lock(); ①
  try {
    v = m.get(key); ②
    if (v == null) {
      w.lock();
      try {
      // 再次验证并更新缓存
      // 省略详细代码
      } finally{
      w.unlock();
    }
   }
  } finally{
  r.unlock(); ③
}

可惜 ReadWriteLock 并不支持这种升级。在上面的代码示例中，读锁还没有释放，此时获取写锁，会导致写锁永久等待，最终导致相关线程都被阻塞，永远也没有机会被唤醒。锁的升级是不允许的，这个你一定要注意。不过，虽然锁的升级是不允许的，但是锁的降级却是允许的。

class CachedData {
    Object data;
    volatile boolean cacheValid;
    final ReadWriteLock rwl = new ReentrantReadWriteLock();
    // 读锁
    final Lock r = rwl.readLock();
    // 写锁
    final Lock w = rwl.writeLock();
    void processCachedData() {
    // 获取读锁
    r.lock();
    if (!cacheValid) {
    // 释放读锁，因为不允许读锁的升级
      r.unlock();
      // 获取写锁
      w.lock();
      try {
      // 再次检查状态
        if (!cacheValid) {
          data = ...
          cacheValid = true;
        }
        // 释放写锁前，降级为读锁
        // 降级是可以的
      r.lock(); ①
     } finally {
     // 释放写锁
       w.unlock();
     }
    }
    // 此处仍然持有读锁
    try {use(data);}
    finally {r.unlock();}
   }
}

总结：
觉得有用的客官可以点赞、关注下！感谢支持🙏谢谢!