读写锁之ReadWriteLock

你可能有这样一个疑问，Java SDK 并发包里为什么还有很多其他的工具类呢？原因很简单：分场景优化性能，提升易用性。

针对读多写少这种并发场景，Java SDK 并发包提供了读写锁——ReadWriteLock

读写锁，并不是 Java 语言特有的，而是一个广为使用的通用技术，所有的读写锁都遵守以下三条，尤其注意第三条，之后我们讲跟其他锁的对比会用到。

基本原则：

1. 允许多个线程同时读共享变量；

2.只允许一个线程写共享变量；

3. 如果一个写线程正在执行写操作，此时禁止读线程读共享变量（读锁 写锁是互斥的，不能同时存在）

 

互斥锁：

 

互斥锁	互斥锁	升降级
ReadWriteLock	读操作允许多个线程同时读共享变量 写操作是互斥的，当一个 线程在写共享变量的时候，是不允许其他线程执行写操作和读操作。	不允许升级，允许降级。 读锁不支持条件变量newCondition()

 

 

一：用 ReadWriteLock 快速实现一个通用的缓存工具类

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

面的这段代码实现了按需加载的功能，这里我们假设缓存的源头是数据库。先从缓存中获取数据，若缓存中没有，就从数据库中加载，然后写入缓存。

经验之谈：在获取写锁之后，并不直接查数据库，而是再次验证缓存是否存在，为什么呢？

class MyCache<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){ ⑦
                  //假设A1线程获取读锁，并更新了数据库，释放了读锁
                  // 接下来A2线程得到读锁，获取读锁，并更新了数据库，释放了读锁
                  // A3线程也是如此操作，
                  // 获取到读锁再次验证是否存在，就能避免后续线程多次操作数据库
                  // 查询数据库 代码省略
                  //....................
                  m.put(key, v);
                  }
              } finally{
              w.unlock();
              }
          return v;
          }
 }

二：锁的升级，在获取读锁后，发现是空的，（没有释放读锁），继续获得写锁，执行后续操作。实际上这种操作是不允许的，因为读锁和写锁互斥。

读锁还没有释放，此时获取写锁，会导致写锁永久等待，最终导致相关线程都被阻塞，永远也没有机会被唤醒。锁的升级是不允许的，这个你一定要注意。 

 

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

三：锁的降级

不过，虽然锁的升级是不允许的，但是锁的降级却是允许的。以下代码来源自ReentrantReadWriteLock 的官方示例，伪代码如下

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();}
    }
}

 

 

总结：

读写锁类似于 ReentrantLock，也支持公平模式和非公平模式。读锁和写锁都实现了java.util.concurrent.locks.Lock 接口，所以除了支持 lock() 方法外，tryLock()、lockInterruptibly() 等方法也都是支持的。但是有一点需要注意，那就是只有写锁支持条件变量，读锁是不支持条件变量的，读锁调用 newCondition() 会抛出 UnsupportedOperationException异常

 

文中部分代码引用：王宝令  ReadWriteLock：如何快速实现一个完备的缓存