网上很多大神写了关于AQS和读写锁的源码分析，看了收益良多。但是发现很少有基于读锁和写锁被持有的场景结合源码进行分析的，
所以尝试记录自己的分析结果，如果有人有暇发现了错误，请不吝赐教。
1： 读锁请求和释放
readLock.lock()
多个读请求锁，主要是调用ReentrantReadWriteLock的tryAcquireShared()方法
下面仔细分析下这个方法：
tryAcquireShared()方法：
①：判断是当前否存在独占锁，如果存在独占锁，那么返回-1，进入doAcquireShared方法（）
②：判断readshouldBlock方法，这个方法判断是否需要当前读阻塞。在公平锁的前提下是看SYN队列是否存在先驱节点；如果是非公平模式则看队列中
第一个是否为写。（多个读场景不可能阻塞因为 没有写 读是不会进入阻塞队列）
③：如果读锁持有的数量小于MAX_COUNT(2^32-1=65535)则，通过CAS操作来比较。如果比较成功则返回成功；如果失败则进入步骤④FullAcqurireShared方法
④：
FullAcqurireShared()
其实就是重复1,2,3步骤，知道获取到state或者返回-1.这里需要注意的是这里用例ThreadLocal对象readHolds来存储当前线程锁重入的次数。
如果上述方法返回-1，基本上归结为公平模式下SYN的队列中有先驱，或者非公平模式下有阻塞的写在队列头中（这种情况一般是被之前读锁阻塞的写），则进入doAcquired方法。
doAcquireShared()方法：
①：把当前线程包装成共享类型的Node放入SYN队列中
②：如果当前节点前驱为头结点（既当前节点是队列中的第一个阻塞节点），则再一次调用tryAcquireShared（）方法
（需要说明的，这边这样做的原因可能是在这个读锁请求过程中，已阻塞在队列中的的读或者写已经被释放。）
如果tryAcquiredShared()成功了，则尝试释放队列中的存在后继节点且前继waitStatus小于0 则调用doReleaseShared()方法
③：如果第二步失败，则用LockSupport.park()挂起当前节点，进入阻塞状态
doReleaseShared()方法：
这里需要注意的是前一个节点的waitStatus代表后一个节点的状态，如果是singnal状态 则代表后一个节点所在线程已经被挂起。
所以doReleaseShared()方法中 unpark的是singanal状态的节点。队列中下一个节点的unpark()是由前一个节点先前阻塞的doAcquireShared()
方法锁唤醒。
readLock.unlock()
tryReleaseShared()方法:
①：更具ThreadLocalmap中的 readHolds对象，并把数量-1
②：CAS把高位读state-1.如果修改后的state为0 则返回true；否则返回false
③：步骤②返回true 代表需要进行doRelaeaseShared方法。这里这样做的原因是 当前锁不被 任何读锁或者写锁持有，则doReleaseShared（）。因为如果队列中有写请求，写锁需要等刀所有读释放掉才能获得，后于这个写锁来的读锁，肯定被加入到了队列中；如果队列中没有写请求，那么队列中肯定也不会有阻塞(之前和这个读一起阻塞的读线程已经被unpark掉) 因为读是共享的
2：写锁请求和释放
writeLock .lock()
tryAcquire()方法:
tryAcquire()方法 RRWL重写了这个方法
①： 如果state不为0 且写锁数为0，则代表当前有读锁被持有，当前写阻塞；如果state不为0，写锁数w不为0且独占线程=本身，则当前lock请求为锁的重入
②：如果state为0，则表示当前没有写锁或者读锁被持有。判断writerShouldBlock()当前线程是否要阻塞：如果公平模式下，判断是否有前驱节点，非公平模式
下，直接返回false
③：步骤②返回true 则当前线程获得锁；返回false，则用当前线程封装一个独占节点Node.
EXCLUSIVE,并加入AQS的队列，进入步骤acquireQueued()
acquireQueued()方法:
①： 以当前线程构造独占节点并加入到AQS的队列中
②：如果当前的前驱节点是head节点，则再次调用tryAcquired方法,这边再次判断的原因是可能的读锁或者写锁已经释放，如果tryAcquired失败
则挂起当前线程
writeLock .unlock()
①：tryRelease()方法:
unLock必须是取得锁的线程，因为是独占的 写锁只有一个 所以判断独占线程是否一致 不一致则抛出异常；一致就把state-1，如果写锁被持有数为0
则把独占线程置成null。
②：unparkSuccessor后继节点
1）判断head是否为空，既判断AQS队列中是否有元素，如果有head节点不为null且waitStatus不为0，则进入步骤2）
2）进入unparkSuccessor()方法，这个方法意义和名字一样 释放后续的阻塞线程
2.1)如果当前节点状态小于0则给他置0，这里当前节点状态代表后继节点线程的状态
2.2)如果后继节点是null或者waitStatus>0(既为CANCELLED取消状态，则跳过)，否则unpark()线程
这种情况，可能是当前写锁被持有，后续来了N个读锁的请求或者写锁请求，这几个锁请求显然被park()变成阻塞状态,放在了队列中。
unLock的unparkSuccessor，唤醒了队列中的head，依次唤醒队列的后续节点，这里需要注意的是，唤醒的顺序 不一定是获得锁的顺序！