ReentrantReadWriteLock源码分析

---

title: JUC.ReentrantReadWriteLock

ReentrantReadWriteLock提纲

• ReentrantReadWriteLock简介
• 原理剖析

ReentrantReadWriteLock简介

ReentrantReadWriteLock适用于读多写少的场景，ReentrantReadWriteLock采用的是读写分离的方式。相比较上一章的StampedLock来说由于没有使用乐观锁的方式，可以保证强一致性。
但是也存在一个问题那就是很有可能会导致写锁饿死。因为有读锁存在则写锁需要等待，有写锁存在则读锁需要等待。上面的StampedLock可以解决这个问题，但是前面也有提到使用的注意规则小心脏数据。
综合来说具体怎么用，用哪种方式还是根据具体的业务场景来判断。没有完美的方案，不然也不会存在两个锁了。接着继续说ReentrantReadWriteLock。

首先看一下类结构图

从类图中可以看出ReentrantReadWriteLock实现了以下锁
1.写锁（独占锁，可以存在非公平与公平两种锁方式）
2.读锁（共享锁，可以存在非公平与公平两种锁方式）
上述就是ReentrantReadWriteLock的大致描述

原理剖析

其实通过上面咱们应该会有以下几个疑问
1.内部如何维护的读写锁分离
2.写锁如何获取以及释放
3.读锁如何获取以及释放
4.当有写锁或者读锁存在，又有线程获取写锁或者读锁怎么处理。
带着上面四个疑问咱们开始看源码。

• 读写分离如何维护
  ReentrantReadWriteLock很明显也是通过AQS实现，内部也是通过state维护锁状态。
  看源码有下面这一段，高16位表示读锁，低16位表示写锁。读锁总数加重入数65535和写锁可重入最多次数是65535次。
  这里真这么多次读锁state的值早超了int最大值。。。。不过影响不大。

   static final int SHARED_SHIFT   = 16;
   //读状态65536
   static final int SHARED_UNIT    = (1 << SHARED_SHIFT);
   //最大读65535
   static final int MAX_COUNT      = (1 << SHARED_SHIFT) - 1;
   //独占锁二进制15个1
   static final int EXCLUSIVE_MASK = (1 << SHARED_SHIFT) - 1;

• 写锁获取与释放
  写锁还是看重写tryAcquire方法

            protected final boolean tryAcquire(int acquires) {
            /*
             * Walkthrough:
             * 1. If read count nonzero or write count nonzero
             *    and owner is a different thread, fail.有读写存在而且不是当前线程
             * 2. If count would saturate, fail. (This can only
             *    happen if count is already nonzero.)超了次数
             * 3. Otherwise, this thread is eligible for lock if
             *    it is either a reentrant acquire or
             *    queue policy allows it. If so, update state
             *    and set owner.//拿锁或者进队列
             */
            Thread current = Thread.currentThread();
            int c = getState();
            int w = exclusiveCount(c);
            if (c != 0) {
                // (Note: if c != 0 and w == 0 then shared count != 0)
                if (w == 0 || current != getExclusiveOwnerThread())
                    return false;
                if (w + exclusiveCount(acquires) > MAX_COUNT)
                    throw new Error("Maximum lock count exceeded");
                // Reentrant acquire
                setState(c + acquires);
                return true;
            }
            if (writerShouldBlock() ||
                !compareAndSetState(c, c + acquires))
                return false;
            setExclusiveOwnerThread(current);
            return true;
        }

上述的英文注释写的很明白了三种情况不过多解释。
只说一下CAS这边存在的问题，如果已经有读锁存在则CAS失败进入队列否则成功拿到锁。这里就会很容易导致写锁饿死。。。因为进入队列了。
这里可以设置下公平锁不容易导致写锁饿死。。。这是我能想到的优化方案。
释放锁和以前的套路一样就是在state上面减少1到0了就释放。

• 读锁获取与释放

       protected final int tryAcquireShared(int unused) {
            /*
             * Walkthrough:
             * 1. If write lock held by another thread, fail.
             * 2. Otherwise, this thread is eligible for
             *    lock wrt state, so ask if it should block
             *    because of queue policy. If not, try
             *    to grant by CASing state and updating count.
             *    Note that step does not check for reentrant
             *    acquires, which is postponed to full version
             *    to avoid having to check hold count in
             *    the more typical non-reentrant case.
             * 3. If step 2 fails either because thread
             *    apparently not eligible or CAS fails or count
             *    saturated, chain to version with full retry loop.
             */
            Thread current = Thread.currentThread();
            int c = getState();
            if (exclusiveCount(c) != 0 &&
                getExclusiveOwnerThread() != current)
                return -1;
            int r = sharedCount(c);
            if (!readerShouldBlock() &&
                r < MAX_COUNT &&
                compareAndSetState(c, c + SHARED_UNIT)) {
                if (r == 0) {
                    firstReader = current;
                    firstReaderHoldCount = 1;
                } else if (firstReader == current) {
                    firstReaderHoldCount++;
                } else {
                    HoldCounter rh = cachedHoldCounter;
                    if (rh == null || rh.tid != getThreadId(current))
                        cachedHoldCounter = rh = readHolds.get();
                    else if (rh.count == 0)
                        readHolds.set(rh);
                    rh.count++;
                }
                return 1;
            }
            return fullTryAcquireShared(current);
        }

通过上面代码总结来说其实就是
1.有写锁存在则阻塞进入队列
2.多个线程拿读锁则CAS失败的进入fullTryAcquireShared继续CAS拿锁。
3.通过ThreadLocal记录每个线程重入次数
释放锁代码如下

      protected final boolean tryReleaseShared(int unused) {
            Thread current = Thread.currentThread();
            if (firstReader == current) {
                // assert firstReaderHoldCount > 0;
                if (firstReaderHoldCount == 1)
                    firstReader = null;
                else
                    firstReaderHoldCount--;
            } else {
                HoldCounter rh = cachedHoldCounter;
                if (rh == null || rh.tid != getThreadId(current))
                    rh = readHolds.get();
                int count = rh.count;
                if (count <= 1) {
                    readHolds.remove();
                    if (count <= 0)
                        throw unmatchedUnlockException();
                }
                --rh.count;
            }
            for (;;) {
                int c = getState();
                int nextc = c - SHARED_UNIT;
                if (compareAndSetState(c, nextc))
                    // Releasing the read lock has no effect on readers,
                    // but it may allow waiting writers to proceed if
                    // both read and write locks are now free.
                    return nextc == 0;
            }
        }

代码很简单减少当前线程ThreadLocal中的值，然后减少state当0的时候释放锁。
到这咱们上面的问题就都解决完了。
而且到这咱们JAVA中的锁基本都写完了，后面继续写JUC下面的其它工具类。
ThreadLocal的使用后面再写一篇源码分析，线程池里面用这东西还是需要注意下的。

欢迎扫码加入知识星球继续讨论