锁的排他性使得多个线程无法以线程安全的方式在同一时刻对共享变量进行读取，这在读多写少的并发场景下不利于提高系统的并发性。为此，Java SDK 并发包提供了读写锁——ReadWriteLock，读写锁是一种改进型的排他锁，在同一时刻允许多个读线程访问，但在写线程访问时，所有读线程和其他写线程均被阻塞。

获得条件 排他性 作用
读锁 相应的写锁未被任何线程持有 对读线程是共享的，对写线程是排他的 允许多个读线程可以同时读取共享变量，并保障读线程读取共享变量期间没有其他任何线程能够更新共享资源。
写锁 该写锁未被其他任何线程持有，并且相应的读锁未被其他任何线程持有 对写线程和读线程都是排他的 使得写线程能够以独占的方式访问共享变量，且写线程对共享变量的更新对读线程是可见的。

此外有一点需要注意，那就是只有写锁支持条件变量，读锁是不支持条件变量的，读锁调用 newCondition() 会抛出 UnsupportedOperationException 异常。

代码示例

  1. public class ReadWriteLockDemo {
  3.     private static ReadWriteLock readWriteLock = new ReentrantReadWriteLock();
  4.     private static Lock readLock = readWriteLock.readLock();
  5.     private static Lock writeLock = readWriteLock.writeLock();
  7.     // 模拟读任务
  8.     public void handRead(Lock lock) {
  9.         readLock.lock();
  10.         try {
  11.             Thread.sleep(1000);
  12.             System.out.println("reading...");
  13.         } catch (InterruptedException e) {
  14.             //
  15.         } finally {
  16.             readLock.unlock();
  17.         }
  18.     }
  19.     // 模拟写任务
  20.     public void handWrite(Lock lock, int index) {
  21.         writeLock.lock();
  22.         try {
  23.             Thread.sleep(1000);
  24.             System.out.println("writing...");
  25.         } catch (InterruptedException e) {
  26.             //
  27.         } finally {
  28.             writeLock.unlock();
  29.         }
  30.     }
  32.     public static void main(String[] args) {
  33.         final ReadWriteLockDemo demo = new ReadWriteLockDemo();
  34.         Runnable read = () -> demo.handRead(readLock);
  35.         Runnable write = () -> demo.handWrite(writeLock, new Random().nextInt()); 
  36.         // 模拟18个读线程，2个写线程
  37.         for (int i = 0; i < 18; i++) {
  38.             new Thread(read).start();
  39.         }
  40.         for (int i = 18; i < 20; i++) {
  41.             new Thread(write).start();
  42.         }
  43.     }
  44. }

实现原理

  1. public class ReentrantReadWriteLock implements ReadWriteLock, java.io.Serializable {
  2.     // 读锁由内部类ReadLock实现
  3.     private final ReentrantReadWriteLock.ReadLock readerLock;
  4.     // 写锁由内部类WriteLock实现
  5.     private final ReentrantReadWriteLock.WriteLock writerLock;
  6.     ......
  7. }

在 ReentrantReadWriteLock 里面，ReadLock 和 WriteLock 都继承了 Lock 接口，内部执行具体操作的主体都是 Sync 内部类，Sync 继承了 AQS 并重写了获取、释放锁的逻辑。只是在获取锁时，ReadLock 采用共享模式来获取锁，而 WriteLock 采用独占模式来获取锁。

  1. public static class ReadLock implements Lock, java.io.Serializable {
  2.     private final Sync sync;
  4.     protected ReadLock(ReentrantReadWriteLock lock) {
  5.         sync = lock.sync;
  6.     }
  7.     // 共享模式
  8.     public void lock() {
  9.         sync.acquireShared(1);
  10.     }
  11. }
  13. public static class WriteLock implements Lock, java.io.Serializable {
  14.     private final Sync sync;
  16.     protected WriteLock(ReentrantReadWriteLock lock) {
  17.         sync = lock.sync;
  18.     }
  19.     // 独占模式
  20.     public void lock() {
  21.         sync.acquire(1);
  22.     }
  23. }

1. state

读写锁也是基于 AQS 实现的，它的自定义同步器 Sync 需要在同步状态 state 字段上分别维护多个读线程和一个写线程的状态，该状态的设计成为实现读写锁的关键。在读写锁的实现中，很好地使用了高低位，来实现一个整型控制两种状态的功能。

  1. static final int SHARED_SHIFT   = 16;
  2. static final int SHARED_UNIT    = (1 << SHARED_SHIFT);
  3. static final int MAX_COUNT      = (1 << SHARED_SHIFT) - 1;
  4. static final int EXCLUSIVE_MASK = (1 << SHARED_SHIFT) - 1;
  6. /** Returns the number of shared holds represented in count  */
  7. static int sharedCount(int c)    { return c >>> SHARED_SHIFT; }
  8. /** Returns the number of exclusive holds represented in count  */
  9. static int exclusiveCount(int c) { return c & EXCLUSIVE_MASK; }

  • sharedCount：获取读锁数量，就是将同步状态无符号右移 16 位，即取同步状态的高 16 位。

  • exclusiveCount：获取写锁数量，先看下 EXCLUSIVE_MASK 这个静态变量，它是对 1 进行左移 16 位然后减 1 最后与同步状态取与，所以也就是获取同步状态的低 16 位来表示写锁的获取次数。

通过对这个 state 变量按位切割切分成了两部分，高 16 位表示读（读锁个数），低 16 位表示写（写锁个数）。也因此读锁、写锁的获取数量也有个最大值，即 216-1。
ReadWriteLock - 图1
当获取读锁时，每次加锁需要修改 state 变量值的高 16 位值加一；同样，当获取写锁时，每次加锁需要修改 state 变量值的低 16 位值加一，虽然写锁是独占锁，但支持可重入，所以也会有数量限制。

2. WriteLock

WriteLock 是一个支持可重入的排它锁。当一个线程尝试获取写锁时，会先判断同步状态 state 是否为 0。如果 state 等于 0，说明暂时没有其它线程获取锁；如果 state 不等于 0，则说明有其它线程获取了锁。

此时再判断同步状态 state 的低 16 位（w）是否为 0，如果 w 为 0，则说明其它线程获取了读锁，此时进入同步队列进行阻塞等待；如果 w 不为 0，则说明其它线程获取了写锁，此时要判断获取了写锁的线程是不是当前线程，若不是就进入同步队列进行阻塞等待；若是，就应该判断当前线程获取写锁是否超过了最大次数，若超过则抛异常，反之更新同步状态。
1bba37b281d83cdf0c51095f473001d1.webp
独占模式加锁：

  1. protected final boolean tryAcquire(int acquires) {
  2.     Thread current = Thread.currentThread();
  3.     // 取到当前锁的个数
  4.     int c = getState();
  5.     // 取写锁的个数
  6.     int w = exclusiveCount(c);
  7.     // 如果已经有线程持有了锁
  8.     if (c != 0) {
  9.         // 如果写线程数为0（即此时存在读锁）或者当前线程不是已经获取写锁的线程
  10.         if (w == 0 || current != getExclusiveOwnerThread())
  11.             return false;
  12.         // 如果写锁的数量大于最大数（65535），就抛出一个Error
  13.         if (w + exclusiveCount(acquires) > MAX_COUNT) throw new Error("Maximum lock count exceeded");
  14.         setState(c + acquires);
  15.         return true;
  16.     }
  17.     // 公平锁和非公平锁逻辑由writerShouldBlock方法来判断
  18.     if (writerShouldBlock() || !compareAndSetState(c, c + acquires)) return false;
  19.     // 获取同步状态成功，设置当前线程为锁的拥有者
  20.     setExclusiveOwnerThread(current);
  21.     return true;
  22. }

在第 10 行，tryAcquire() 除了重入条件（当前线程为获取了写锁的线程）外，还额外增加了一个读锁是否存在的判断逻辑。如果存在读锁，则写锁不能被获取，因为要确保写锁的操作对读锁可见。因此，只有等待其他读线程都释放了读锁，写锁才能被当前线程获取，而写锁一旦被获取，则其他读写线程的后续访问均被阻塞。

独占模式释放锁：

  1. protected final boolean tryRelease(int releases) {
  2.     // 如果不是持有写锁的线程，则直接抛出异常
  3.     if (!isHeldExclusively())
  4.         throw new IllegalMonitorStateException();
  5.     // 释放写状态
  6.     int nextc = getState() - releases;
  7.     boolean free = exclusiveCount(nextc) == 0;
  8.     // 判断写锁数量是否为0，为0则修改持有写锁的线程为null，即释放写锁成功
  9.     if (free)
  10.         setExclusiveOwnerThread(null);
  11.     setState(nextc);
  12.     return free;
  13. }

3. ReadLock

ReadLock 是一个支持可重入的共享锁，它能够被多个线程同时获取，在没有其他写线程访问（写状态为 0）时读锁总是会被成功地获取。如果当前线程已经获取了读锁，则增加读状态。如果当前线程在获取读锁时，写锁已被其他线程获取了，则进入等待状态。
52e77acc6999efbdf4113daaa5918d46.webp
共享模式加锁：

  1. protected final int tryAcquireShared(int unused) { 
  2.     Thread current = Thread.currentThread();
  3.     int c = getState();
  4.     // 如果其他线程持有了写锁，则直接返回-1，获取同步状态失败
  5.     if (exclusiveCount(c) != 0 &&
  6.         getExclusiveOwnerThread() != current)
  7.         return -1;
  8.     // 获取state变量的高16位值(即读锁数量)
  9.     int r = sharedCount(c);
  10.     // 调用readerShouldBlock来判断是否公平与非公平，且不要超过可获取读锁数量的最大值
  11.     if (!readerShouldBlock() &&
  12.         r < MAX_COUNT &&
  13.         compareAndSetState(c, c + SHARED_UNIT)) {
  14.         if (r == 0) {
  15.             // 读锁数量为0，第一次加读锁，设置firstReader为当前线程
  16.             firstReader = current;
  17.             firstReaderHoldCount = 1;
  18.         } else if (firstReader == current) {
  19.             // 读锁重入，如果当前线程是第一个持有该读锁的线程，计数器+1
  20.             firstReaderHoldCount++;
  21.         } else {
  22.             HoldCounter rh = cachedHoldCounter;
  23.             if (rh == null || rh.tid != getThreadId(current))
  24.                 cachedHoldCounter = rh = readHolds.get();
  25.             else if (rh.count == 0)
  26.                 readHolds.set(rh);
  27.             rh.count++;
  28.         }
  29.         return 1;
  30.     }
  31.     // 获取同步状态失败，则无限循环重试
  32.     return fullTryAcquireShared(current);
  33. }

公平锁 FairSync 的 readerShouldBlock 调用了 AQS 的 hasQueuedPredecessors 方法来判断，跟可重入锁一样，先判断 AQS 同步队列中是否存在排在该线程之前的的节点，保证先入队的先执行。而非公平锁 NonfairSync 的 readerShouldBlock 实现是：如果 AQS 同步队列中第一个是等待写锁的线程则返回 true，当前获取读锁的线程先阻塞，优先让等待队列的线程去获取写锁。

共享模式释放锁：

  1. protected final boolean tryReleaseShared(int unused) {
  2.     Thread current = Thread.currentThread();
  3.     ......
  4.     for (;;) {
  5.         int c = getState();
  6.         int nextc = c - SHARED_UNIT;
  7.         if (compareAndSetState(c, nextc))
  8.             return nextc == 0;
  9.     }
  10. }

由于当前是共享模式，所以该方法会存在多线程并发执行的情况，因此采用 for 循环加 CAS 的方式修改 state 变量的高 16 位值，当 state 的高 16 位为 0 的时候，释放成功返回 true。

锁的降级

锁降级是指把持住（当前拥有的）写锁，再获取到读锁，随后释放（先前拥有的）写锁的过程。代码示例如下所示（取自 JDK 文档）：

  1. class CachedData {    
  2.     Object data;
  3.     volatile boolean cacheValid;
  4.     final ReadWriteLock rwl = new ReentrantReadWriteLock();
  5.     // 读锁  
  6.     final Lock r = rwl.readLock();
  7.     //写锁
  8.     final Lock w = rwl.writeLock();
  10.     void processCachedData() {
  11.         // 获取读锁
  12.         r.lock();
  13.         // 如果数据过期了，则重新获取数据
  14.         if (!cacheValid) {
  15.             // 先释放读锁再获取写锁，因为不允许读锁的升级
  16.             r.unlock();
  17.             w.lock();
  18.             try {
  19.                 // 再次检查状态  
  20.                 if (!cacheValid) {
  21.                     data = ...
  22.                     cacheValid = true;
  23.                 }
  24.                 // 释放写锁前，降级为读锁(同一个线程内可以获取到)
  25.                 r.lock();
  26.             } finally {
  27.                 // 释放写锁
  28.                 w.unlock(); 
  29.             }
  30.         }
  31.         // 此处仍然持有读锁，去使用数据
  32.         try {
  33.             use(data);
  34.         } finally {
  35.             r.unlock();
  36.         }
  37.     }
  38. }

为什么需要锁降级？

主要是为了保证数据的可见性，如果当前线程不获取读锁而是直接释放写锁，假设在释放写锁的瞬间，另一个线程成功获取了写锁并修改了数据，那么当前线程就无法感知后续的数据更新了。如果当前线程遵循锁降级的步骤，那么其他线程无法获取写锁，直到当前线程释放读锁后，其他线程才能获取写锁进行数据更新。

注意：ReadWriteLock 不支持锁的升级。如果在持有读锁时去获取写锁，会导致获取写锁永久等待，最终导致相关线程都被阻塞，永远也没有机会被唤醒。