AQS之ReenReadWriteLock

前言

在传统的对共享变量的操作过程中,无论是对其进行读操作还是写操作,都会进行加锁.对于写操作而言加锁的意义就比较明显因为写操作要修改共享变量这就需要不同线程之间的互斥.但是读操作却不涉及到修改操作,仅仅是把共享变量加载到线程的工作内存中.AQS中的ReenReadWriteLock内部实现了读读并发，读写/写读，写写互斥.

源码解读

ReenReadWriteLock对于AQS内部维护的state跟ReentrantLock略有不同,state被切割为了两部分,一个int类型的变量占4个字节,1个字节占8个长度.state将高16位表示共享锁(读锁),低16位表示独占锁(写锁).那么为什么要这样设计呢？为何不把两个模式的加锁设成两个变量?

个人认为有以下几个原因:
1.空间利用率方面.一把锁的状态不大可能超过2的16次幂.也就是65536.无论是读锁还是写锁也好.几率可以说非常小.如果用32位来表示,可想而知空间利用率多么地低下.
2.时间效率方面.这两种状态是密不可分的,也就是说两种状态存在一定的依赖性.典型的例子就是锁降级.加载两个状态值的时间花费肯定是大于加载一个状态值的.每次从内存中读取另一个状态值也是需要消耗时间的.位运算是要比从内存中读取快很多的.

两种状态值的获取方式:
独占锁:将state与1左移 16位做与运算.
共享锁:直接将state右移16位

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

1.writeLock

        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.*/// 1.获取当前线程Thread current = Thread.currentThread();// 2.获取锁的状态int c = getState();// 3.获取独占锁的数量int w = exclusiveCount(c);// 4.判断当前锁是不是自由状态(没有读锁也没有写锁)if (c != 0) {// 5.当前锁被人持有// 6.当前锁的状态是共享锁还是独占锁// 如果是共享锁,判断当前上锁的线程是否是自己// 注意:这里是一个逻辑或运算,如果第一个条件为true,会发生短路.// 第二个条件不会进行判断// 场景一:如果没有人来进行独占锁加锁,如果当前线程来加锁.意味着要锁升级,// 这是不允许的.需要等待读锁释放完毕才可以进行加锁// 这可能会导致脏数据的产生,另外也违背了互斥性原则// 场景二:锁被人持有,但是w不为0,说明有人在上独占锁,第一个条件为false// 接着走第二个条件,当前锁的持有者是不是自己,如果是自己,则进行锁的重入.// 如果不是自己,那么遵循互斥性原则的写写互斥.当前线程要加锁失败// (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 acquiresetState(c + acquires);return true;}// 7.该方法在非公平模式下,直接返回的是false.公平锁模式下是判断是否有队列形成if (writerShouldBlock() ||// 8. CAS加锁失败直接返回!compareAndSetState(c, c + acquires))return false;// 9.将当前持有者线程设为自己setExclusiveOwnerThread(current);return true;}

获取失败后进行入队.写锁的上锁模式相比于ReentrantLock还是比较容易理解的.需要注意的是锁升级的禁止.接下来我们来重点看下Doug Lea是如何做到读读并发的.在未看源码之前,我们可以自己设想一下,我们自己应该如何设计.

2.readLock

        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.*/// 1.获取当前线程Thread current = Thread.currentThread();// 2.获取锁的状态int c = getState();// 3.判断当前锁的状态是否为独占锁,如果是独占锁则判断独占锁是否是自己.// 如果当前状态是独占锁,并且持有者线程不是自己,直接返回-1执行入队操作// 写写互斥if (exclusiveCount(c) != 0 &&getExclusiveOwnerThread() != current)return -1;// 4. 获取共享锁int r = sharedCount(c);// 5.该方法判断了队列是否形成,并且head的下一个节点是否是独占锁,// 因为如果head节点下一个节点是独占锁的话,!readerShouldBlock()则是false,// 这里顺着代码分析,如果head节点的下一个节点是共享锁,则判断当前的读锁是否小于// 最大读锁.接着CAS加锁if (!readerShouldBlock() &&r < MAX_COUNT &&compareAndSetState(c, c + SHARED_UNIT)) {// 6.如果队列没有形成,并且当前线程是第一次来进行加锁.// firstReader 置为当前线程.这里设计的目的是,当这个线程重入时,// 可以直接进行加锁,有点像sync的偏向锁if (r == 0) {firstReader = current;firstReaderHoldCount = 1;} else if (firstReader == current) {// 7.如果当前当前线程不是第一次加锁,第二次进行加锁,是锁的重入.// 则firstReaderHoldCount++firstReaderHoldCount++;} else {// 8.如果锁的状态是被人持有共享锁.进入以下判断// 9.这里的HoldCounter只有两个属性// 一个是count一个是tid(这个tid是根据偏移量计算出来的一个值)// HoldCounter是用来统计每个线程的共享锁的上锁次数的.HoldCounter rh = cachedHoldCounter;// 如果当前线程没有缓存过,短路// 直接进行存储,readHolds底层是一个ThreadLocal// key是Thread value是int类型的countif (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);}

    final boolean apparentlyFirstQueuedIsExclusive() {Node h, s;return (h = head) != null &&(s = h.next)  != null &&!s.isShared()         &&s.thread != null;}

写锁的释放可以参考<AQS之ReentrantLock>在此不再赘述
https://blog.csdn.net/Cover_sky/article/details/117737555
接下来我们再来看下读锁是如何释放的

        protected final boolean tryReleaseShared(int unused) {// 1.获取当前线程Thread current = Thread.currentThread();// 2.判断当前线程是否是第一个加共享锁的线程if (firstReader == current) {// 3.如果是第一个加共享锁的线程,并且只添加过一次// 那么直接将firstReader 置为NULL// 反之则自减// assert firstReaderHoldCount > 0;if (firstReaderHoldCount == 1)firstReader = null;elsefirstReaderHoldCount--;} else {// 4.如果来释放共享锁的线程不是第一个来加共享锁的线程// 获取最后获取共享锁的线程信息// 如果当前线程不是最后一个加共享锁的线程// 则从readHolds中获取该线程对应的ThreadLocalHoldCounter rh = cachedHoldCounter;if (rh == null || rh.tid != getThreadId(current))rh = readHolds.get();// 5.获取该线程对应的共享锁次数int count = rh.count;// 6.判断是否小于等于1,if (count <= 1) {// 7.小于等于1 则删除该线程对应的ThreadLocalreadHolds.remove();// 8. 并发场景下移除ThreadLocal将直接抛出异常if (count <= 0)throw unmatchedUnlockException();}// 9.该线程曾多次添加共享锁,进行自减--rh.count;}// 10.以上操作只是把该线程对应的加锁次数进行了修改.state还没有进行修改// 下方是CAS修改state的操作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;}}