ReentrantReadWriteLock 这个对象，有两个内部类，readLock和writeLock，都有一个aqs的属性sync，实例化的时候，获取的是从ReentrantReadWriteLock自己的重写的内部类sync继承了aqs
看readLock的lock（）方法
RWlock 的 内部类sync 继承了aqs之后，对state进行了设计，后16位用来表示exlusiveCount，排他的数目。前16位用来表示sharedCount，共享的数目。readLock 的 Lock 调用的是 sync.acquireShared(1)，这是aqs的方法，
if (tryAcquireShared(arg) < 0)
doAcquireShared(arg);
其中，tryAcquireShared是RWLock自己重写了的
用意是：试着获取共享锁，如果获取成功，返回的是正数，如果获取失败，返回的是-1，
逻辑是：
如果exlusiveCount不为0，说明此时有人使用排它锁，而且排它锁的线程不是当前线程，所以不能重入，那么现在的试图获取共享锁的操作是失败的
如果以上不成立，那么，说明可以获取共享锁，如果用cas添加sharedcount成功，那么返回1
否则，进入full啥啥啥方法，逻辑和本方法差不多，只不过在for循环中，为了弥补cas miss，其实是个延迟加载
看readLock的unlock（）方法
public void unlock() {
sync.releaseShared(1);
}public final boolean releaseShared(int arg) {
if (tryReleaseShared(arg)) {
doReleaseShared();
return true;
}
return false;
}其中，tryReleaseShared是RWLOCK重写的，tryReleaseShared的逻辑是，获取sharedstate，减一，返回剩下的sharedstate是否等于0，如果不为0，不执行doReleaseShared方法，否则执行
doReleaseShared是AQS的，逻辑是很熟悉的：将head节点的后继节点唤醒。现在是readlock获取到锁之后的unlock，那么挂起线程的列表中绝不会有readlock的申请者，因为是共享的，所以试图获取读锁的线程不会被挂起。所以挂起的线程都是
写锁，那么现在读锁全部释放，唤醒写锁线程也是非常合理的。
看WriteLock的lock（）方法
public void lock() {
sync.acquire(1);
}
public final void acquire(int arg) {
if (!tryAcquire(arg) &&
acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
selfInterrupt();
}其实还是正常的获取锁的逻辑：尝试获取，如果获取到了，就设置state，exlusiveThread等待，然后往下走，如果获取不到就把线程挂起到队列里
关键是尝试获取的逻辑不同，交给不同的子类sync重写
RWLOCK的tryAcquire的逻辑是：
protected final boolean tryAcquire(int acquires) {
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;
}先不看具体逻辑，试想一个，如果一个写锁可以获取，那么前提应该是，没有读锁，没有任何别的写锁，也就是如果有写锁，只能是自己，这也是c != 0中的第一个条件判断的，其他的判断都是判断有没有其他写锁了，这个和普通的独占锁是一样的。
看WriteLock的unlock（）方法
public final boolean release(int arg) {
if (tryRelease(arg)) {
Node h = head;
if (h != null && h.waitStatus != 0)
unparkSuccessor(h);
return true;
}
return false;
}还是一样的逻辑，try方法自己重写，其他方法继承，
protected final boolean tryRelease(int releases) {
if (!isHeldExclusively())
throw new IllegalMonitorStateException();
int nextc = getState() - releases;
boolean free = exclusiveCount(nextc) == 0;
if (free)
setExclusiveOwnerThread(null);
setState(nextc);
return free;
}逻辑也很简单，减去state上的数目，因为exlusive的是后16位，所以直接减就行了，然后看看后16位是不是0，如果是的话返回真，不是的返回假。返回真的话，就可以唤醒挂起的线程，这个时候的挂起线程就是等待的写线程。