1、fullTryAcquireShare该方法内部是一个循环。2、本质上就是把上一个方法tryAcquireShared的获取读锁的逻辑拿到for循环中再判断一遍。3、因为CAS失败后，进入自旋。
doReleaseShared
更新等待队列中的头节点。把当前Node设置为头节点。
非公平锁下的读锁获取结论：1、A线程在获取读锁的情况下，如果还想去获取写锁，必须先释放读锁，再去获取写锁。会让是当前线程阻塞挂起，且永远无法被唤醒。ReadWriteLock不支持锁的升级。2、如果A线程获取读锁下，B线程去获取写锁，则B线程进入阻塞队列。然后，又有C线程去获取读锁。C线程也会进入阻塞队列。【因为非公平锁的readerShouldBlock实现。避免写线程陷入饥饿等待】
否
获取到读锁
是
线程唤醒后
最终是否获取读锁？
readerShouldBlock()
在共享模式下，当一个Node唤醒后，如果它的后继节点也是共享锁，那么就会触发『传播』。即继续唤醒它的后继节点。
lock
readerShouldBlock的非公平锁实现逻辑是：1、阻塞队列不为空，且下个节点不是共享模式，那么读线程要阻塞。2、公平锁的实现逻辑是：阻塞队列不为空，且有其它节点排队中了，则读线程要阻塞。
fullTryAcquireShared
当前读锁的数量是否超过最大限制
成功
失败
当前线程进入阻塞状态，挂起
是否已经上了写锁？
addWaiter(Node.SHARED);
加锁成功？
尝试获取锁（ tryAcquireShared)
lock方法结束
tryAcquireShared
CAS修改state高16位
getExclusiveOwnerThread() == current
当前Node的前驱节点是否是头节点？
是否需要传播后继节点？
