Java并发 - ReentrantReadWriteLock

港控/mmm° 2022-09-03 12:18 61阅读 0赞

参考：

*  <<Java并发编程的艺术>>
 *  JDK1.8源码

## 一、读写锁简介 ##

读写锁`java.util.concurrent.locks.ReadWriteLock`是个接口，接口里定义了两个方法`Lock readLock()`和`Lock writeLock()`分别用于获取读锁和写锁。

读写锁（参考ReadWriteLock接口上的注释）：

*  一对锁：读锁用于读操作，写锁用于写操作
    
     *  读锁：多个读线程可以同时获取到读锁进行读操作，写线程此时获取写锁时会被阻塞
     *  写锁：对于写锁，只有一个写线程能够获取到，其他写线程获取写锁会被阻塞，因为写锁是排他的
 *  内存语义：读写锁的实现必须保证写锁的内存语义也要和读锁关联，即获取到读锁的线程能看到之前释放写锁的线程所做的所有更新
 *  并发访问：与互斥锁相比，读写锁允许更高级别的并发访问共享数据。虽然只有一个写线程可以修改共享数据，但是允许多个读线程同时读取数据（言下之意就是对于并发访问数据使用互斥锁实现就low了…）。 不过这也是理论上的，对于单核处理器而言并发性并没有多大提升，需要多核处理器才能体现出来，并且也要看具体的业务场景
 *  应用场景：最终需要进行性能测试判断读写锁是否适合这个业务场景
    
     *  读多写少：这个场景比较适合，如果写多读少的话，大部分时间仍然被锁住，并发性没有多大提升
     *  读操作时间长：假如读操作时间太短的话，可能也会对并发性有影响，因为读写锁的实现相比于互斥锁更复杂点。
 *  读锁、写锁的选用：有以下几种情况需要考虑清楚
    
     *  情况一：当读线程和写线程都在等待时，写锁被释放，那么是能获取到读锁还是写锁呢？
        
         *  写锁偏向：这种方式比较常见，因为写频率低且时间短
         *  读锁偏向：不常见，这样的话可能导致长时间都无法写入新数据
         *  公平锁、有序：这两种方式也比较常见，即“先来后到”
     *  情况二：现在有线程持有了读锁，还有个读线程和写线程在等待，那么是能获取到读锁还是写锁？
        
         *  读锁偏向：读线程获取到读锁，较长时间导致无法写入新数据
         *  写锁偏向：可能会降低并发性
     *  情况三：确定锁是否可重入？
        
         *  持有写锁的线程是否可以重新获取写锁，是否可以在持有写锁的同时获取读锁
         *  读锁本身是否可重入
     *  情况四：锁降级、锁升级？
        
         *  是否可以将写锁降级为读锁，其他写线程是否可以干预
         *  读锁是否可以升级为写锁，优先级是否高于其他等待的读线程、写线程

所以实现一个读写锁要考虑好上面所有的情况，使其适合你的应用。

## 二、ReentrantReadWriteLock ##

### 2.1 简介 ###

Java并发包里提供的读写锁实现就是：`java.util.concurrent.locks.ReentrantReadWriteLock`，语义和`ReentrantLock`类似。

ReentrantReadWriteLock对于第一节最后提出的问题都给出了具体实现：（参考类上的注释）

*  获取锁次序：没有实现读锁偏向、写锁偏向，而是支持公平、非公平方式获取锁
    
     *  非公平锁：**默认** 获取锁的方式，获取读锁、写锁顺序不确定，和读锁、写锁的重入性有很大关系。这种方式可能会导致读线程、写线程长时间无法获取到锁，但是通常比公平锁吞吐量要高
     *  公平锁：
        
         *  基本按照线程先进先出的方式获取锁，例如锁被释放时，等待时间最长的一个写线程将会获取到写锁（一个），或者等待时间最长的一组读线程获取到读锁（多个）
         *  假如当前有线程持有了写锁，或者有一个线程已经在等待，此时有一个读线程获取读锁时将会被阻塞（该线程不是持有写锁的线程，***是的话，那么就能获取到读锁，下面会说到***）
         *  假如有线程获取了读锁，那么有一个线程获取写锁的话就会被阻塞，不管是否是同一线程
 *  重入性
    
     *  和ReentrantLock类似，读线程获取锁之后，该线程能够再次获取读锁，但是不能获取到写锁；写线程在获取写锁之后，该线程也能再次获取写锁，同时也能获取到读锁
 *  锁降级
    
     *  支持写锁降级为读锁，一个线程获取到写锁后，其他线程都不能获取到锁，但是持有写锁的线程可以获取到读锁，之后该线程释放了写锁，这个过程就叫锁降级（次序：获取写锁->获取读锁->释放写锁）
 *  锁获取中断
    
     *  读锁和写锁都支持在获取锁时中断（例如：线程获取锁时会先判断是否被中断过，中断过则抛出异常，不再获取锁，但是`synchronized`就不支持了）
 *  Condition支持
    
     *  写锁支持Condition，和ReentrantLock.newCondition 提供的 Condition 实现一样；Condition只能与写锁一起使用
     *  读锁不支持 Condition，readLock().newCondition() 会抛出 UnsupportedOperationException
 *  锁状态、序列化
    
     *  内置了一些方法用于监视系统状态，例如当前是否有线程持有锁、读锁/写锁状态，这些方法不是用于同步控制（同步控制仍然借助AQS以及内部定义的内部类Sync实现）
     *  序列化与锁的行为方式相同，反序列化的锁处于解锁状态，和其序列化时的状态无关，也就是会丢失

### 2.2 实现原理 ###

看下ReentrantReadWriteLock类图：实线表示继承，虚线表示实现接口，+表示内部类  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L215dHRfMTA1NjY_size_16_color_FFFFFF_t_70]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L215dHRfMTA1NjY_size_16_color_FFFFFF_t_70 1]  
（1）同步实现

`ReentrantReadWriteLock`内部仍然是借助AQS（java.util.concurrent.locks.AbstractQueuedSynchronizer：队列同步器，不了解的小伙伴搜搜，JUC下的ReentrantLock、CountDownLatch等都是借助AQS实现）来实现的，具体实现就是静态内部类`Sync`：

*  Sync：同步器的实现方式，一个抽象类，继承了AQS，主要完成尝试获取锁、释放锁的逻辑，主要包括以下几个方法（这几个方法在AQS中是抽象方法，需要子类实现具体的逻辑）：
    
     *  tryAcquire()：尝试获取写锁
     *  tryRelease()：尝试释放写锁
     *  tryAcquireShared()：尝试获取读锁
     *  tryReleaseShared()：尝试释放读锁
 *  FairSync：公平锁实现方式
    
     *  writerShouldBlock()：获取写锁是否阻塞，这两个方法逻辑一模一样：若AQS的队列为空或队列的第一个等待的是当前线程，那么就可以去争抢锁，遵循FIFO，公平就提现在这个地方
     *  readerShouldBlock()：获取读锁是否阻塞
 *  NonfairSync：非公平锁实现方式
    
     *  writerShouldBlock()：直接返回false，表示去争抢锁
     *  readerShouldBlock()：若AQS的队列为空或队列中第一个等待的是读线程，那么就去争抢锁

（2）读写状态

读写状态是通过AQS的state字段来实现的，我们知道ReetrantLock中state用来标识同一线程重入次数，而读写锁就需要通过state来维护多个读线程和一个写线程的状态。

读写锁中通过将state切成两部分来使用（state是int类型，32位）：高16位表示读、低16位标识写，所以最大重入次数为2^16-1=65535

（3）读锁、写锁

静态内部类：ReadLock、WriteLock，实现了Lock接口，获取锁、释放锁的入口在这两个类似，具体实现是通过读写锁的静态内部类Sync实现。

WriteLock：

*  lock()：加锁（互斥锁/排他锁），不管线程是否被中断过
 *  lockInterruptibly()：加锁（互斥锁/排他锁），假如线程中断过，抛出中断异常
 *  unlock()：解锁
 *  newCondition()：条件，只有写锁支持

ReadLock：

*  lock()：加锁（共享锁），不管线程是否被中断过
 *  lockInterruptibly()：加锁（共享锁），假如线程中断过，抛出中断异常
 *  unlock()：解锁
 *  newCondition()：读锁不支持，会直接抛出异常

### 2.3 写锁的获取与释放 ###

#### 2.3.1 写锁的获取 ####

获取写锁执行链路：

*  WriteLock\#lock() -> AQS\#acquire() -> tryAcquire()
 *  tryAcquire()是个抽象方法，由子类`ReentrantReadWriteLock.Sync#tryAcquire()`实现，所以我们分析下这个方法

`tryAcquire()`实现原理：

*  1.读状态不为0 或者 写状态不为0且获取写锁的不是当前线程，则当前线程进入等待状态
 *  2.写状态超过最大值65535，则获取锁失败，抛出异常
 *  3.其他情况，表明当前读锁/写锁状态空闲 或者 获取写锁的是当前线程，则设置写状态，同时设置写锁的拥有者

若获取写锁失败，`tryAcquire()`方法返回false，那么就会执行`AQS#addWaiter()`和`AQS#acquireQueued()`，实际上就是交给AQS执行，和ReetrantLock执行逻辑一致了。这里说下大概的逻辑：

*  1.为当前线程构造一个队列中的节点，且是独占模式，此时等待状态为0
 *  2.将当前线程（节点）放入队列尾部，假如队列还没初始化，那么就会初始化一个空的节点作为头结点（head）
 *  3.在当前线程阻塞前，执行以下操作：这段逻辑是自旋
    
     *  3.1再进行一次获取锁的尝试`tryAcquire()`：条件就是当前节点的前驱是头结点
        
         *  成功的话就获取到了锁（表示之前的线程释放了锁），再将当前线程设置为头结点，前驱节点的next设置为null，结束自旋
     *  3.2 尝试失败或者前驱不是头结点，那么就会设置前驱节点的等待状态(`Node.waitStatus`)
        
         *  如果已经为SIGNAL：-1，那么执行3.3
         *  如果是CANCELLED：1，那么就会从队列尾部从后往前找到一个正常状态的节点作为当前节点的前驱，找到后进行下一次循环，也就是执行3.1
         *  如果是其他状态如：初始的0、PROPAGATE：-3，那么就将等待状态设置为SIGNAL：-1，再次执行3.1
     *  3.3 将当前线程阻塞

// ReentrantReadWriteLock.WriteLock#lock()
    public void lock() { 
    	// 调用AQS#acquire()方法
        sync.acquire(1);
    }
    
    // AQS#acquire()
    public final void acquire(int arg) { 
    	// tryAcquire()是个抽象方法，由子类实现
        if (!tryAcquire(arg) && acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
            selfInterrupt();
    }
    
    // ReentrantReadWriteLock.Sync#tryAcquire()
    protected final boolean tryAcquire(int acquires) { 
        Thread current = Thread.currentThread();
        int c = getState();
        // 获取state低16位，即写状态
        int w = exclusiveCount(c);
        if (c != 0) { 
            // 这个判断条件有2个含义：
            // 1. c != 0 且 w == 0：表示读状态不为0，写状态为0，即有线程获取了读锁，没有线程获取写锁，此时获取写锁失败
            // 2. 表示获取写锁的不是当前线程，获取写锁失败
            if (w == 0 || current != getExclusiveOwnerThread())
                return false;
            // 到这一步就说明：当前线程获取了写锁，现在是重入
            // 校验一下写状态是否超过了最大值65535，是的话抛出错误 
            if (w + exclusiveCount(acquires) > MAX_COUNT)
                throw new Error("Maximum lock count exceeded");
            // 重入获取到了锁，设置state为state+1
            setState(c + acquires);
            return true;
        }
        // 这一步说明：读锁、写锁都没有被获取
        // 1.判断是否需要阻塞：公平锁和非公平锁判断条件不一样
        // - 公平锁：队列为空或者获取锁的是当前线程，那么不需要阻塞，否则阻塞（公平性也就体现在这里，遵循FIFO）
        // - 非公平锁：不需要阻塞
        // 举例： 这里出现阻塞情况：例如线程A、B、C获取写锁，都到这一步，可能的情况：
        // 线程A先一步获取到了写锁，线程B获取写锁失败，进入队列等待，线程C就会发现队列已经有等待的线程且不是自己，那么也获取写锁失败
    
    	// 2.不阻塞，那么就会CAS设置state为state+1，有可能失败，表示有其他线程竞争
    	// 举例：例如上面的例子，线程A获取了写锁并设置state+1，那么线程B执行这一步就会失败
        if (writerShouldBlock() || !compareAndSetState(c, c + acquires))
            return false;
        // 设置当前线程获取了写锁 
        setExclusiveOwnerThread(current);
        return true;
    }
    
    // ReentrantReadWriteLock.FairSync#writerShouldBlock()
    final boolean writerShouldBlock() { 
    	// 该方法是调用AQS#hasQueuedPredecessors()
    	// 判断队列是否为空或者头结点是否是当前线程：队列为空或者等待的线程就是当前线程，那么返回false，否则返回true
    	return hasQueuedPredecessors();
    }
    
    // ReentrantReadWriteLock.NonfairSync#writerShouldBlock()
    final boolean writerShouldBlock() { 
        return false;
    }

#### 2.3.2 写锁的释放 ####

释放写锁执行链路：

*  WriteLock\#unlock() -> AQS\#release() -> tryRelease()
 *  tryRelease()是个抽象方法，由子类`ReentrantReadWriteLock.Sync#tryRelease()`实现，所以我们分析下这个方法

`tryRelease()`实现原理：

*  主要完成的就是将 写状态-1，假如为0表示释放了写锁，同时清除写锁的拥有者
 *  假如`tryRelease()`返回了true，剩下的步骤由AQS实现：有等待的线程，则进行唤醒

// ReentrantReadWriteLock.WriteLock#unlock()
    public void unlock() { 
        sync.release(1);
    }
    
    // AQS#release()
    public final boolean release(int arg) { 
    	// tryRelease()是个抽象方法，由子类实现
        if (tryRelease(arg)) { 
            Node h = head;
            if (h != null && h.waitStatus != 0)
                unparkSuccessor(h);
            return true;
        }
        return false;
    }
    
    // ReentrantReadWriteLock.Sync#tryRelease()
    protected final boolean tryRelease(int releases) { 
    	// 必须是持有写锁的线程释放写锁，否则抛出异常
        if (!isHeldExclusively())
            throw new IllegalMonitorStateException();
        // 写状态-1（等于state-1，因为是写状态是低16位表示的） 
        int nextc = getState() - releases;
        // 写状态为0，表示已经释放了锁
        boolean free = exclusiveCount(nextc) == 0;
        if (free)
        	// 清除写锁的拥有者
            setExclusiveOwnerThread(null);
        // 设置state 
        setState(nextc);
        return free;
    }

### 2.4 读锁的获取与释放 ###

#### 2.4.1 读锁的获取 ####

获取读锁执行链路：

*  ReadLock\#lock() -> AQS\#acquireShared() -> tryAcquireShared()
 *  tryAcquireShared()是个抽象方法，由子类`ReentrantReadWriteLock.Sync#tryAcquireShared()`实现，所以我们分析下这个方法

`tryAcquireShared()`实现原理：

*  1.有线程获取了写锁且不是当前线程，那么获取读锁失败
 *  2.若读状态超过了最大值65535，那么抛出错误
 *  3.获取读锁，公平锁和非公平锁判断条件不太一样：
    
     *  3.1 非公平锁：
        
         *  如果队列为空或者队列中第一个等待的是读线程，那么就通过CAS方式设置读状态+1，设置成功表示获取了读锁，否则说明有线程竞争，那么进行重试
         *  如果队列中第一个等待的是写线程，那么会重试一次，若在此期间等待的写线程获取了写锁且释放了，重试的这一次才可能会获取到读锁，否则就是获取读锁失败
     *  3.2 公平锁
        
         *  如果队列为空或者队列中第一个等待的是当前线程，那么就通过CAS方式设置读状态+1，设置成功表示获取了读锁，否则说明有线程竞争，那么进行重试
         *  如果队列中有等待的线程，那么就会进行重试，遵循FIFO
 *  4.获取读锁成功，设置第一次读线程和重入次数、最后一次读线程重入次数、各个线程重入次数（ThreadLocal方式实现）

获取读锁失败，`tryAcquireShared()`返回-1，那么就会执行`AQS#doAcquireShared()`方法，实际上就是交给AQS执行。这里说下大概的逻辑：

*  1.为当前线程构造一个队列中的节点，且是共享模式，此时等待状态为0
 *  2.将当前线程（节点）放入队列尾部，假如队列还没初始化，那么就会初始化一个空的节点作为头结点（head）
 *  3.在当前线程阻塞前，执行以下操作：这段逻辑也是自旋（和独占锁逻辑类似，区别在于再一次尝试获取锁成功或者被唤醒后处理逻辑不太一样）
    
     *  3.1再进行一次获取锁的尝试`tryAcquireShared()`：条件就是当前节点的前驱是头结点，成功的话就获取到了锁（例如：写锁释放了，假如是公平锁：可能是其他读线程也都获取到了锁）
        
         *  获取共享锁成功后，那么将当前节点设置为头结点，假如后继结点是共享模式，那么再调用`AQS#doReleaseShared()`唤醒后继等待的线程
     *  3.2 尝试失败或者前驱不是头结点，那么就会设置前驱节点的等待状态(`Node.waitStatus`)
        
         *  如果已经为SIGNAL：-1，那么执行3.3
         *  如果是CANCELLED：1，那么就会从队列尾部从后往前找到一个正常状态的节点作为当前节点的前驱，找到后进行下一次循环，也就是执行3.1
         *  如果是其他状态如：初始的0、PROPAGATE：-3，那么就将等待状态设置为SIGNAL：-1，再次执行3.1
     *  3.3 将当前线程阻塞

// ReentrantReadWriteLock.ReadLock#lock()
    public void lock() { 
        sync.acquireShared(1);
    }
    
    // AQS#acquireShared()
    public final void acquireShared(int arg) { 
    	// tryAcquireShared()是个抽象方法，由子类实现
        if (tryAcquireShared(arg) < 0)
            doAcquireShared(arg);
    }
    
    // ReentrantReadWriteLock.Sync#tryAcquireShared()
    protected final int tryAcquireShared(int unused) { 
        Thread current = Thread.currentThread();
        int c = getState();
        // 写状态不为0 并且 获取写锁的不是当前线程：获取读锁失败（只有获取写锁的线程才可能获取读锁）
        if (exclusiveCount(c) != 0 && getExclusiveOwnerThread() != current)
            return -1;
            
        // 读状态（state的高16位） 
        int r = sharedCount(c);
        
        // 不阻塞 且 读状态小于最大值（65535） 且 CAS设置读状态+1成功，那么进入if分支
        // 1.判断是否需要阻塞，公平锁和非公平锁判断条件不一样
        // - 公平锁：队列为空或者获取锁的是当前线程，那么不需要阻塞，否则阻塞（公平性也就体现在这里，遵循FIFO）
        // - 非公平锁：队列为空或者队列中第一个是读线程，那么不需要阻塞，否则阻塞（也就是队列第一个是写线程）
        if (!readerShouldBlock() && r < MAX_COUNT && compareAndSetState(c, c + SHARED_UNIT)) { 
        	// 读状态为0，那么记录首次读的线程，首次读线程的重入次数设置为1
            if (r == 0) { 
                firstReader = current;
                firstReaderHoldCount = 1;
            } 
            // 当前是首次读的线程，表示重入，重入次数+1
            else if (firstReader == current) { 
                firstReaderHoldCount++;
            } 
    		// 其他线程获取了读锁
    		else { 
    			// 最后一个获取读锁的线程的HoldCounter计数器
                HoldCounter rh = cachedHoldCounter;
                // 没有（第一个读线程不参与） 或者 不是当前线程：初始化HoldCounter计数器
                if (rh == null || rh.tid != getThreadId(current))
                    cachedHoldCounter = rh = readHolds.get();
                else if (rh.count == 0)
                    readHolds.set(rh);
                // 重入次数+1 
                rh.count++;
            }
            return 1;
        }
        // 到这一步表示：需要阻塞 或 读状态到了最大值 或 cas设置state失败（有线程竞争）
        // 
        return fullTryAcquireShared(current);
    }
    
    // FairSync#readerShouldBlock()
    final boolean readerShouldBlock() { 
    	// 和判断写锁是否需要阻塞逻辑一致
        return hasQueuedPredecessors();
    }
    
    // NonfairSync#readerShouldBlock()
    final boolean readerShouldBlock() { 
    	// 队列为空或者等待的第一个不是写线程，那么表示不需要阻塞，返回false，否则返回true
        return apparentlyFirstQueuedIsExclusive();
    }
    
     // ReentrantReadWriteLock.Sync#fullTryAcquireShared()
     // 该方法代码与 tryAcquireShared() 中的代码部分冗余，总体上简单点：基本上就是再重试一次获取读锁，除非是因为竞争原因导致的设置state失败，那么会进行自旋重试
    final int fullTryAcquireShared(Thread current) { 
        HoldCounter rh = null;
        for (;;) { 
            int c = getState();
            // 写状态不为0，表示有线程获取了写锁
            if (exclusiveCount(c) != 0) { 
            	// 获取写锁的线程不是当前线程：直接返回
            	// 注意：这里没有写else分支，也就是获取写锁是当前线程，那么就获取到了读锁，但是并没有这么实现
            	// 注意：官方注释里解释是：在这里阻塞会引起死锁（目前没仔细考虑这啥原因。。。）
                if (getExclusiveOwnerThread() != current)
                    return -1;
            } 
    		// 判断是否需要阻塞，和上面逻辑一样区分：公平锁、非公平锁
    		// 假如tryAcquireShared()中是因为需要阻塞才到该方法里，那么除非队列中第一个等待的线程执行了，否则这里也让然是阻塞
    		else if (readerShouldBlock()) { 
                // Make sure we're not acquiring read lock reentrantly
                if (firstReader == current) { 
                    // assert firstReaderHoldCount > 0;
                } else { 
                    if (rh == null) { 
                        rh = cachedHoldCounter;
                        if (rh == null || rh.tid != getThreadId(current)) { 
                            rh = readHolds.get();
                            if (rh.count == 0)
                                readHolds.remove();
                        }
                    }
                    if (rh.count == 0)
                        return -1;
                }
            }
            // 读状态到达了最大值，抛出错误
            if (sharedCount(c) == MAX_COUNT)
                throw new Error("Maximum lock count exceeded");
            // CAS方式设置读状态+1
            if (compareAndSetState(c, c + SHARED_UNIT)) { 
            	// 设置首次读线程以及重入次数为1
                if (sharedCount(c) == 0) { 
                    firstReader = current;
                    firstReaderHoldCount = 1;
                } else if (firstReader == current) { 
                	// 首次读线程重入次数+1
                    firstReaderHoldCount++;
                } else { 
                	// 其他线程获取到了读锁
                	// 设置最后一次读线程重入次数+1，没有则初始化（ThreadLocal方式实现）
                    if (rh == null)
                        rh = cachedHoldCounter;
                    if (rh == null || rh.tid != getThreadId(current))
                        rh = readHolds.get();
                    else if (rh.count == 0)
                        readHolds.set(rh);
                    rh.count++;
                    cachedHoldCounter = rh;
                }
                // 返回获取到了读锁
                return 1;
            }
        }
    }

#### 2.4.2 读锁的释放 ####

释放读锁执行链路：

*  ReadLock\#unlock() -> AQS\#releaseShared() -> tryReleaseShared()
 *  tryReleaseShared()是个抽象方法，由子类`ReentrantReadWriteLock.Sync#tryReleaseShared()`实现，所以我们分析下这个方法

释放读锁流程：这部分逻辑由`ReentrantReadWriteLock.Sync#tryReleaseShared()`实现：

*  主要完成的就是 将CAS方式将读状态-1，失败则进行自旋；同时将首次读线程的计数-1或首次读线程清空、非首次读线程的计数器-1或清空
 *  `tryReleaseShared()`是否应该返回true，这里有两种情况：
    
     *  情况一：多个线程获取了读锁，那么肯定无写锁，只有state==0才表示释放了读锁，返回true
     *  情况二：一个线程获取了写锁，然后又获取了读锁，此时先释放了读锁，那么读状态为0但是写状态不为0，所以释放了读锁但是写锁还在，所以不应该返回读锁释放了，也就是返回true；应该等待写锁释放，让其唤醒后续等待的线程
 *  剩下的步骤由AQS实现：有等待的线程，则进行唤醒

// ReentrantReadWriteLock.ReadLock#unlock()
    public void unlock() { 
        sync.releaseShared(1);
    }
    
    // AQS#releaseShared()
    public final boolean releaseShared(int arg) { 
    	// 尝试释放共享锁，抽象方法，由子类实现
        if (tryReleaseShared(arg)) { 
            doReleaseShared();
            return true;
        }
        return false;
    }
    
    // ReentrantReadWriteLock.Sync#tryReleaseShared()
    protected final boolean tryReleaseShared(int unused) { 
        Thread current = Thread.currentThread();
        // 当前线程是首次读的线程
        if (firstReader == current) { 
            // 首次读重入次数为1，清空记录的首次读线程，否则重入次数-1
            if (firstReaderHoldCount == 1)
                firstReader = null;
            else
                firstReaderHoldCount--;
        } else { 
        	// 非首次读线程
        	// 获取最后一次读线程的计数器，如果记录的最后一次不是当前线程，那么则从ThreadLocal中获取计数器
            HoldCounter rh = cachedHoldCounter;
            if (rh == null || rh.tid != getThreadId(current))
                rh = readHolds.get();
            // 最后一次读线程的重入次数 
            int count = rh.count;
            if (count <= 1) { 
            	// 移除当前线程的计数器
                readHolds.remove();
                // 重入次数<=0，抛出异常
                // 因为一个线程获取读锁时候通过ThreadLocal维护一个计数器，获取成功计数+1，所以在释放的时候，就不可能出现为0的情况
                if (count <= 0)
                    throw unmatchedUnlockException();
            }
            // 重入次数-1
            --rh.count;
        }
        // 自旋操作
        for (;;) { 
        	// 获取state
            int c = getState();
            // 读状态-1
            int nextc = c - SHARED_UNIT;
            // CAS设置新的state值，失败则重试
            if (compareAndSetState(c, nextc))
                // 读状态、写状态都为0，返回true：表示没有任何线程持有读锁、写锁
                // 这里可能有2种情况：
                // 情况一：多个线程获取了读锁，那么肯定无写锁，只有state==0才表示释放了读锁，返回true
                // 情况二：一个线程获取了写锁，然后又获取了读锁，此时先释放了读锁，那么读状态为0但是写状态不为0，所以释放了读锁但是写锁还在，所以不应该返回读锁释放了，也就是返回true；应该等待写锁释放，让其唤醒后续等待的线程
                return nextc == 0;
        }
    }

### 2.5 示例 ###

#### 2.5.1 示例一：实现线程安全的HashMap ####

我们知道HashMap是线程不安全的，要想实现线程安全那么建议使用ConcurrentHashMap、HashTable，除此我们也可以通过读写锁实现：

*  put()：加写锁，其他读/写线程都不能进行读取/更新
 *  get()：加读锁，这样多个读线程都能进行读操作

/** * 基于ReentrantReadWriteLock实现的线程安全HashMap（示例来源于ReentrantReadWriteLock类上的注释） */
    public class RWDictionary { 
    	// data
    	private final Map<String, Object> map = new HashMap<>();
    	// 默认非公平锁
        private final ReentrantReadWriteLock readWriteLock = new ReentrantReadWriteLock();
        // 读锁
        private final Lock readLock = readWriteLock.readLock();
        // 写锁
        private final Lock writeLock = readWriteLock.writeLock();
    
        public Object get(String key) { 
            readLock.lock();
            try { 
                return map.get(key);
            } finally { 
                readLock.unlock();
            }
        }
    
        public Object[] allKeys() { 
            readLock.lock();
            try { 
                return map.keySet().toArray();
            } finally { 
                readLock.unlock();
            }
        }
    
        public Object put(String key, Object value) { 
            writeLock.lock();
            try { 
                return map.put(key, value);
            } finally { 
                writeLock.unlock();
            }
        }
    
        public void clear() { 
            writeLock.lock();
            try { 
                map.clear();
            } finally { 
                writeLock.unlock();
            }
        }
    }

#### 2.5.2 示例二：锁降级 ####

锁降级：线程在持有写锁时 -> 获取了读锁 -> 释放写锁，这个过程就叫做锁降级。

问题：锁降级中是否有必要获取读锁呢？  
答案：有必要，主要是为了保证可见性。如果当前线程不获取读锁而是直接释放了写锁，此时线程A获取到了写锁并对数据进行了更新，那么当前线程是不知道数据是否更新了，就可能读到脏数据了；但是当前线程获取了读锁，随后再释放写锁，那么线程A就无法获取到写锁，只能阻塞等到读锁释放。

/** * 锁降级示例（伪代码，示例来源于ReentrantReadWriteLock类上的注释） */
    public class CachedData { 
       	private Object data;
       	private volatile boolean cacheValid;
       	// 读写锁
       	private final ReentrantReadWriteLock rwl = new ReentrantReadWriteLock();
       	private final Lock readLock = readWriteLock.readLock()
    	private final Lock writeLock = readWriteLock.writeLock();
    
       	public void processCachedData() { 
       		// 1.获取读锁
         	readLock.lock();
         	if (!cacheValid) { 
           		// 2.在获取写锁前必须释放读锁
           		readLock.unlock();
           		// 3.获取写锁
           		writeLock.lock();
           		try { 
             		// 重新检测下状态，可能其他写线程已经获取到锁更新了数据
             		if (!cacheValid) { 
               			data = ...
               			cacheValid = true;
             		}
             		// 4.锁降级，在释放写锁前获取读锁
             		readLock.lock();
           		} finally { 
           			// 5.释放写锁，此时当前线程仍然持有读锁
             		writeLock.unlock();
           		}
         	}
    
         	try { 
           		use(data);
         	} finally { 
         		// 6.释放读锁
           		readLock.unlock();
         	}
       	}
    }

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L215dHRfMTA1NjY_size_16_color_FFFFFF_t_70]: /images/20220829/b790ca7cc0c842b0b63c5458bef64111.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L215dHRfMTA1NjY_size_16_color_FFFFFF_t_70 1]: /images/20220829/3a3fcd6ee9e845a6a49b2528063f2250.png