并发编程系列 - ReadWriteLock

实际工作中，为了优化性能，我们经常会使用缓存，例如缓存元数据、缓存基础数据等，这就是一种典型的读多写少应用场景。缓存之所以能提升性能，一个重要的条件就是缓存的数据一定是读多写少的，例如元数据和基础数据基本上不会发生变化（写少），但是使用它们的地方却很多（读多）。
针对读多写少这种并发场景，Java SDK并发包提供了读写锁——ReadWriteLock，非常容易使用，并且性能很好。在并发编程中，有时我们需要处理多个线程同时读取共享资源的情况，同时还要保证在有写操作时，对资源的访问是互斥的。这就是读写锁（ReadWriteLock）的应用场景。
什么是读写锁？

读写锁是一种锁机制，它允许多个线程可同时读取共享资源，但在写操作时需要互斥。读写锁将读操作与写操作分开，以提高并发性和性能。
ReadWriteLock的特点

• 多个线程可同时读取：在没有写操作的情况下，多个线程可以并发地读取共享资源，从而提升读取操作的性能。
  
• 写操作是互斥的：写操作会独占锁，确保在写操作进行时没有其他线程可以读取或写入共享资源。
  
• 读写操作之间互斥：在写操作进行时，其他线程不能读取或写入，以保证数据的一致性。
  

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

Java提供了java.util.concurrent.locks包中的ReentrantReadWriteLock类来实现读写锁。下面是一个简单的例子：

1. javaimport java.util.concurrent.locks.ReentrantReadWriteLock;
3. public class ReadWriteLockExample {
4.     private final ReentrantReadWriteLock lock = new ReentrantReadWriteLock();
5.     private int sharedData = 0;
7.     public int readData() {
8.         lock.readLock().lock();
9.         try {
10.             return sharedData;
11.         } finally {
12.             lock.readLock().unlock();
13.         }
14.     }
16.     public void writeData(int newData) {
17.         lock.writeLock().lock();
18.         try {
19.             sharedData = newData;
20.         } finally {
21.             lock.writeLock().unlock();
22.         }
23.     }
24. }

复制代码

在上面的例子中，我们创建了一个ReentrantReadWriteLock实例作为读写锁。使用readLock()方法获取读锁，writeLock()方法获取写锁。
在读取共享资源时，我们需要先获取读锁，然后执行读操作，最后释放读锁。在写入共享资源时，我们需要先获取写锁，然后执行写操作，最后释放写锁。
要注意的是，在使用读写锁时，应该根据实际需求合理地使用读锁和写锁，以便提升并发性和性能。
读写锁的优势与适用场景

• 读多写少：当有大量读取操作，而写操作较少的情况下，读写锁可以提高系统的并发性和性能。
  
• 数据一致性要求较低：如果对共享资源的一致性要求不高，即使在读写操作之间出现一定的延迟或不一致，也不会对系统产生严重影响。
  
• 提升并发性和性能：读写锁通过允许多个线程同时读取共享资源，以及在写操作时互斥地访问资源，可以提高系统的并发性和性能。
  

快速实现一个缓存

下面我们就实践起来，用ReadWriteLock快速实现一个通用的缓存工具类。
在下面的代码中，我们声明了一个Cache类，其中类型参数K代表缓存里key的类型，V代表缓存里value的类型。缓存的数据保存在Cache类内部的HashMap里面，HashMap不是线程安全的，这里我们使用读写锁ReadWriteLock 来保证其线程安全。ReadWriteLock 是一个接口，它的实现类是ReentrantReadWriteLock，通过名字你应该就能判断出来，它是支持可重入的。下面我们通过rwl创建了一把读锁和一把写锁。
Cache这个工具类，我们提供了两个方法，一个是读缓存方法get()，另一个是写缓存方法put()。读缓存需要用到读锁，读锁的使用和前面我们介绍的Lock的使用是相同的，都是try{}finally{}这个编程范式。写缓存则需要用到写锁，写锁的使用和读锁是类似的。这样看来，读写锁的使用还是非常简单的。

1. class Cache<K,V> {
2.   final Map<K, V> m =
3.     new HashMap<>();
4.   final ReadWriteLock rwl =
5.     new ReentrantReadWriteLock();
6.   // 读锁
7.   final Lock r = rwl.readLock();
8.   // 写锁
9.   final Lock w = rwl.writeLock();
10.   // 读缓存
11.   V get(K key) {
12.     r.lock();
13.     try { return m.get(key); }
14.     finally { r.unlock(); }
15.   }
16.   // 写缓存
17.   V put(K key, V value) {
18.     w.lock();
19.     try { return m.put(key, v); }
20.     finally { w.unlock(); }
21.   }
22. }

复制代码

如果你曾经使用过缓存的话，你应该知道 使用缓存首先要解决缓存数据的初始化问题。缓存数据的初始化，可以采用一次性加载的方式，也可以使用按需加载的方式。
如果源头数据的数据量不大，就可以采用一次性加载的方式，这种方式最简单（可参考下图），只需在应用启动的时候把源头数据查询出来，依次调用类似上面示例代码中的put()方法就可以了。
缓存一次性加载示意图
如果源头数据量非常大，那么就需要按需加载了，按需加载也叫懒加载，指的是只有当应用查询缓存，并且数据不在缓存里的时候，才触发加载源头相关数据进缓存的操作。下面你可以结合文中示意图看看如何利用ReadWriteLock 来实现缓存的按需加载。
缓存按需加载示意图
实现缓存的按需加载

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

1. class Cache<K,V> {
2.   final Map<K, V> m =
3.     new HashMap<>();
4.   final ReadWriteLock rwl =
5.     new ReentrantReadWriteLock();
6.   final Lock r = rwl.readLock();
7.   final Lock w = rwl.writeLock();
9.   V get(K key) {
10.     V v = null;
11.     //读缓存
12.     r.lock();         ①
13.     try {
14.       v = m.get(key); ②
15.     } finally{
16.       r.unlock();     ③
17.     }
18.     //缓存中存在，返回
19.     if(v != null) {   ④
20.       return v;
21.     }
22.     //缓存中不存在，查询数据库
23.     w.lock();         ⑤
24.     try {
25.       //再次验证
26.       //其他线程可能已经查询过数据库
27.       v = m.get(key); ⑥
28.       if(v == null){  ⑦
29.         //查询数据库
30.         v=省略代码无数
31.         m.put(key, v);
32.       }
33.     } finally{
34.       w.unlock();
35.     }
36.     return v;
37.   }
38. }

复制代码

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

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

1. //读缓存
2. r.lock();         ①
3. try {
4.   v = m.get(key); ②
5.   if (v == null) {
6.     w.lock();
7.     try {
8.       //再次验证并更新缓存
9.       //省略详细代码
10.     } finally{
11.       w.unlock();
12.     }
13.   }
14. } finally{
15.   r.unlock();     ③
16. }

复制代码

这样看上去好像是没有问题的，先是获取读锁，然后再升级为写锁，对此还有个专业的名字，叫 锁的升级。可惜ReadWriteLock并不支持这种升级。在上面的代码示例中，读锁还没有释放，此时获取写锁，会导致写锁永久等待，最终导致相关线程都被阻塞，永远也没有机会被唤醒。锁的升级是不允许的，这个你一定要注意。
不过，虽然锁的升级是不允许的，但是锁的降级却是允许的。以下代码来源自ReentrantReadWriteLock的官方示例，略做了改动。你会发现在代码①处，获取读锁的时候线程还是持有写锁的，这种锁的降级是支持的。

1. class CachedData {
2.   Object data;
3.   volatile boolean cacheValid;
4.   final ReadWriteLock rwl =
5.     new ReentrantReadWriteLock();
6.   // 读锁
7.   final Lock r = rwl.readLock();
8.   //写锁
9.   final Lock w = rwl.writeLock();
11.   void processCachedData() {
12.     // 获取读锁
13.     r.lock();
14.     if (!cacheValid) {
15.       // 释放读锁，因为不允许读锁的升级
16.       r.unlock();
17.       // 获取写锁
18.       w.lock();
19.       try {
20.         // 再次检查状态
21.         if (!cacheValid) {
22.           data = ...
23.           cacheValid = true;
24.         }
25.         // 释放写锁前，降级为读锁
26.         // 降级是可以的
27.         r.lock(); ①
28.       } finally {
29.         // 释放写锁
30.         w.unlock();
31.       }
32.     }
33.     // 此处仍然持有读锁
34.     try {use(data);}
35.     finally {r.unlock();}
36.   }
37. }

复制代码

总结

读写锁与ReentrantLock类似，还支持公平模式和非公平模式。读锁和写锁都实现了java.util.concurrent.locks.Lock接口，因此除了支持lock()方法外，还支持tryLock()、lockInterruptibly()等方法。但是需要注意的是，只有写锁支持条件变量，而读锁不支持条件变量，因此读锁调用newCondition()会抛出UnsupportedOperationException异常。
今天我们使用了ReadWriteLock实现了一个简单的缓存。尽管该缓存解决了初始化问题，但未解决缓存数据与源数据的同步问题，即确保缓存数据与源数据的一致性。解决数据同步问题最简单的方法之一是使用超时机制。超时机制意味着缓存中加载的数据并不长期有效，而是有一定时效性。当缓存数据超过时效时间后，数据在缓存中失效。对于访问失效的缓存数据，会触发重新从源数据加载到缓存中。
当然，也可以在源数据发生变化时快速通知缓存，但这取决于具体的场景。例如，在MySQL作为数据源时，可以通过实时解析binlog来检测数据是否发生变化，一旦变化就将最新数据推送给缓存。另外，还有一些方案采用了数据库和缓存双写的策略。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！