ReentrantReadWriteLock代码浅析
介绍
除了重入锁ReentrantLock以外，Doug Lea大神还顺带实现了读写重入锁ReentrantReadWriteLock，依旧支持重入特性、公平与非公平模式，分出了读锁和写锁。
读锁
当读锁被持有后，会阻止其他线程获取写锁，但读锁不排斥其他线程持有读锁。
写锁
当写锁被持有后，既排斥其他线程申请读锁，还排斥其他线程申请写锁。
结构
具体的结构关系，直接上图：
流程
通过ReentrantReadWriteLock的readLock()获取读锁，writeLock()获取写锁，读锁和写锁都有lock()、lockInterruptibly()、tryLock()、tryLock(long timeout, TimeUnit unit)，unlock()。
lock()方法，遵循初始化时的公平锁或非公平锁模式请求锁，请求锁的过程不会被中断，直到持有锁为止。
lockInterruptibly()方法，如果线程调用了interrupted()，请求锁的过程将会中断，并且抛出InterruptedException异常。如果线程没有被中断，那么会坚持到持有锁为止。
tryLock()方法，无视初始化时公平与非公平模式，直接尝试一次请求锁的CAS操作，如果成功，返回true，失败，返回false。
tryLock(long timeout, TimeUnit unit)方法，类似lockInterruptibly()，但是比lockInterruptibly()多了超时检查操作，当超时时，会中断请求锁过程。
unlock()方法，释放锁对象当前持有的锁一次。
申请读锁
因为请求写锁锁的流程与普通重入锁大同小异，所以这里只展示读锁的lock()方法的请求流程，lock()方法中通过sync调用acquireShared()方法，acquireShared()方法的实现在AbstractQueuedSynchronizer中：
public final void acquireShared(int arg) {
if (tryAcquireShared(arg) < 0)
doAcquireShared(arg);
}
所有读锁会进行一次tryAcquireShared(int arg)和doAcquireShared(int arg)。获取写锁则调用acquire(int arg)方法，方法中if条件中调用tryAcquire(arg) 和 acquireQueued(final Node node, int arg)，与读锁获取的流程有些小差别。
回到正题，tryAcquireShared(int arg)方法被Sync实现，再看ReentrantReadWriteLock.Sync中：
protected final int tryAcquireShared(int unused) {
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);
}
这个方法中有两个比较重要的流程，都会在特定条件下返回，先看看进入这两个流程的if条件。
第一个if条件，exclusiveCount(c) != 0 && getExclusiveOwnerThread() != current)，先检查写锁重入数，如果不为0，再检查当前线程是否已经持有写锁，如果未持有写锁则返回-1表示失败，那么可以看出，同一个线程是可以同时持有写锁和读锁的。
第二个if条件，!readerShouldBlock() && r < MAX_COUNT && compareAndSetState(c, c + SHARED_UNIT)
首先如果是公平锁，那么在readerShouldBlock()中会进入阻塞队列等待，如果非公平锁，就调用apparentlyFirstQueuedIsExclusive()方法检查队列第一个节点是否在等待写锁，如果不是，再来检查读锁持有是否超过最大值，如果未超过，再来CAS修改读锁持有数量，CAS操作成功之后，这个if流程中会修改部分引用和缓存信息，这个具体作用后面再说。
在公平锁模式阻塞重新被唤醒后或者已有其他线程持有读锁，又或者读锁当前持有数现在已经到了MAX_COUNT时，都会跳过第二个if流程直接进入fullTryAcquireShared(Thread current)方法中：
final int fullTryAcquireShared(Thread current) {
HoldCounter rh = null;
for (;;) {
int c = getState();
if (exclusiveCount(c) != 0) {
if (getExclusiveOwnerThread() != current)
return -1;
//这里注释写了一种造成读写锁死锁的情况
//当前线程持有写锁，而队列中有其他线程正在等待写锁释放时，这个时候再来请求读锁时，就会导致死锁
} else if (readerShouldBlock()) {
// Make sure we're not acquiring read lock reentrantly
if (firstReader == current) {
// assert firstReaderHoldCount > 0;
} else {
//省略部分代码
if (rh.count == 0)
return -1;
}
}
if (sharedCount(c) == MAX_COUNT)
throw new Error("Maximum lock count exceeded");
if (compareAndSetState(c, c + SHARED_UNIT)) {
//省略部分代码
}
return 1;
}
}
}
fullTryAcquireShared(Thread current)方法中的请求锁的过程其实和tryAcquireShared(int unused)中的过程十分相似，最重要的还是CAS操作的这个方法。只有compareAndSetState()成功之后才会结束fullTryAcquireShared(Thread current)方法中for循环，结束这次读锁请求操作。
exclusiveCount(int c)与sharedCount(int c)
在fullTryAcquireShared(Thread current)方法与tryAcquireShared(int unused)方法中中，变量c，就是持有锁的个数，通过getState()获取到值后，先exclusiveCount(int c)，再经过sharedCount(int c)后赋值给r，找到和它们有关的代码：
static final int SHARED_SHIFT = 16;
static final int SHARED_UNIT = (1 << SHARED_SHIFT);// 65536
static final int MAX_COUNT = (1 << SHARED_SHIFT) - 1;// 65535
static final int EXCLUSIVE_MASK = (1 << SHARED_SHIFT) - 1;// 65535
static int exclusiveCount(int c) { return c & EXCLUSIVE_MASK; }
static int sharedCount(int c) { return c >>> SHARED_SHIFT; }
exclusiveCount(int c)操作会清除整型变量c高16位的所有数值，保留低16位数值。
sharedCount(int c) 操作清除整型变量c低16位，保留高16位数值。
所以r < MAX_COUNT && compareAndSetState(c, c + SHARED_UNIT)就是在验证写锁持有数量，当c = 0时c + SHARED_UNIT = 65536，经过sharedCount(int c)计算后得1，c + SHARED_UNIT相当于对 c = (c >>> 16 + 1) << 16，对c高16位数值加1。
也就是说state值的高位保存着读锁数量，低位保存写锁数量，读锁与读锁最大持有数都是65535。
关于读写锁等待队列
不管是公平锁还是非公平锁，未能在其他线程释放锁时的特殊时刻正好获取到锁，都会进入等待锁队列，而这个队列被读锁与写锁共用，具体逻辑很多与重入锁高度重合，有兴趣可以看我写的这篇博客ReentrantLock源码通读（一）。
关于HoldCounter
HoldCounter遍布在所有读锁的请求和释放过程当中，并且为了缓存这个读锁持有数，代码占据了这些流程代码量大概两成左右，所以HoldCounter的重要性不言而喻，那么具体是什么作用呢？
在ReentrantReadWriteLock中对外提供了一个方法:
/**
* Queries the number of reentrant read holds on this lock by the
* current thread. A reader thread has a hold on a lock for
* each lock action that is not matched by an unlock action.
*
* @return the number of holds on the read lock by the current thread,
* or zero if the read lock is not held by the current thread
* @since 1.6
*/
public int getReadHoldCount() {
return sync.getReadHoldCount();
}
//Sync中getReadHoldCount()
final int getReadHoldCount() {
if (getReadLockCount() == 0)
return 0;
Thread current = Thread.currentThread();
if (firstReader == current)
return firstReaderHoldCount;
HoldCounter rh = cachedHoldCounter;
if (rh != null && rh.tid == getThreadId(current))
return rh.count;
int count = readHolds.get().count;
if (count == 0) readHolds.remove();
return count;
}
注释翻译过来就是，查询当前线程重入读锁的次数。不是可以通过Sync中的state全局变量获取重入次数吗，读锁与写锁是通过int的高低位来区分的，十分方便，为什么不能用这个state来获取读锁的重入次数呢？
事实上写锁的确是利用state的来获取写锁的重入次数的，但是写锁是一个线程独占的，它会排斥其他线程获取写锁以及读锁。
读锁，因为其可被共享的特殊性质，导致state中高位存储的是多个线程重入后的总数，所以state无法用来查询当前线程重入读锁的次数，当前线程无法知晓自己重入次数，这在某些复杂场景或者使用不规范的情况下，可能造成读锁无法被正常释放，而且排查起来也异常困难。
所以HoldCounter出现了，与HoldCounter配合当然少不了ThreadLocal，ReentrantReadWriteLock.Sync中包含有HoldCounter静态内部类和ThreadLocalHoldCounter静态内部类。
HoldCounter记录了重入计数与线程的tid。
ThreadLocalHoldCounter继承ThreadLocal，重载了initialValue()方法。
并且为了更快的获取重入数，还额外赠送了两个全局变量，cachedHoldCounter和firstReaderHoldCount。
cachedHoldCounter保存上个请求读锁线程的HoldCounter。
firstReaderHoldCount保存第一个获取读锁线程的重入数。
所以Sync实现的getReadHoldCount()方法根据return，分为四个分支，通过各种全局缓存变量，尽量高效的返回结果。
第一个分支，读取state的高位，如果为0返回。
第二个分支，检查当前线程是否等于firstReader，如果是，返回firstReaderHoldCount。
第三个分支，检查cachedHoldCounter中的tid是否等于当前线程的tid，如果是，返回cachedHoldCounter.count。
第四个分支，就是遍历ThreadLocal中的threadMap找到当前线程的HoldCounter返回count。
思考
一个线程是否可以同时获取到写锁与读锁？
肯定可以，不然也不会在注释里说明会产生死锁的场景了。
根据写锁的tryAcquire(int arg)源码:
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;
}
先判断了state != 0，再判断w==0 || current != getExclusiveOwnerThread()直接堵死线程获取读锁在获取写锁的可能性。
所以能同时获取读锁和写锁的操作只能是先获取写锁，然后获取读锁。
如何能成功同时获取读锁和写锁呢？
在非公平模式下，线程持有写锁后，去请求读锁，而此时等待线程队列中第一个节点不是请求写锁的线程，即可成功获取读锁与写锁，但如果是请求写锁的线程，会返回失败状态值-1，之后进入等待线程队列，线程在持有写锁的情况下休眠并且等待通知被唤醒，由于唤醒超时线程的触发点实在有线程释放锁之后，所以这时无论是否设置过超时参数，都是无效的，依然会导致死锁，所以在使用时需要格外注意。
总结
读锁可以与其他线程共享，但排斥其他线程获取写锁。
写锁排斥其他线程获取锁，当前持有写锁后，仍然可以去获取读锁，完全独占，但是写锁竞争激烈时，完全独占的操作也很容易导致死锁。
读写锁的持有或重入上限均是65535。
当前线程重入计数，读写锁是分开保存的，state中保存的是读锁重入的总数，写锁不受影响。
当前线程读锁重入次数是使用ThreadLocal保存的，每个线程单独维护一个HoldCounter。使用的三个全局变量缓存特殊状态的线程重入计数变量，尽量快的返回结果。
