之前提到锁（如Mutex和ReentrantLock）基本都是排他锁，这些锁在同一时刻只允许一个线程进行访问，而读写锁在同一时刻可以允许多个读线程访问，但是在写线程访问时，所有的读线程和其他写线程均被阻塞。读写锁维护了一对锁，一个读锁和一个写锁，通过分离读锁和写锁，使得并发性相比一般的排他锁有了很大提升。
在没有读写锁支持的（Java 5之前）时候，如果需要完成上述工作就要使用Java的等待通知机制，就是当写操作开始时，所有晚于写操作的读操作均会进入等待状态，只有写操作完成并进行通知之后，所有等待的读操作才能继续执行（写操作之间依靠synchronized关键进行同步），这样做的目的是使读操作能读取到正确的数据，不会出现脏读。
改用读写锁实现上述功能，只需要在读操作时获取读锁，写操作时获取写锁即可。当写锁被获取到时，后续（非当前写操作线程）的读写操作都会被阻塞，写锁释放之后，所有操作继续执行，编程方式相对于使用等待通知机制的实现方式而言，变得简单明了。
ReentrantReadWriteLock的特性
ReadWriteLock仅定义了获取读锁和写锁的两个方法，即readLock()方法和writeLock()方法，而其实现——ReentrantReadWriteLock，除了接口方法之外，还提供了一些便于外界监控其内部工作状态的方法.
接下来分析ReentrantReadWriteLock的实现，主要包括：1.读写状态的设计、2.写锁的获取与释放、3.读锁的获取与释放以及锁降级:
读写锁同样依赖自定义同步器来实现同步功能，而读写状态就是其同步器的同步状态。回想ReentrantLock(www.jianshu.com/p/5d57573b0…)中自定义同步器的实现，同步状态表示锁被一个线程重复获取的次数，而读写锁的自定义同步器需要在同步状态（一个整型变量）上维护多个读线程和一个写线程的状态，使得该状态的设计成为读写锁实现的关键。
如果在一个整型变量上维护多种状态，就一定需要“按位切割使用”这个变量，读写锁将变量切分成了两个部分，高16位表示读，低16位表示写，划分方式如图5-8所示
在搞清楚读写锁的获取和释放之前，我们需要对读写锁的整体设计有一个轮廓。
看类源码:
public interface ReadWriteLock {
Lock readLock();
Lock writeLock();
}
public class ReentrantReadWriteLock
implements ReadWriteLock, java.io.Serializable {
private final ReentrantReadWriteLock.ReadLock readerLock;
private final ReentrantReadWriteLock.WriteLock writerLock;
final Sync sync;
}
实现了ReadWriteLock这个接口，把读锁和写锁的获取抽离出来，还有同样有一个继承了AQS的子类Aync的实现，这跟大多数锁的设计是一样的。 然后接着看下构造方法:
public ReentrantReadWriteLock() {
//默认还是实现非公平调度策略。
this(false);
}
public ReentrantReadWriteLock(boolean fair) {
sync = fair ? new FairSync() : new NonfairSync();
readerLock = new ReadLock(this);
writerLock = new WriteLock(this);
}
可以看出，默认还是实现非公平调度策略。初始化会各自创建读锁和写锁。
写锁加锁获取
写锁是一个支持重进入的排它锁。如果当前线程已经获取了写锁，则增加写状态。如果当前线程在获取写锁时，读锁已经被获取（读状态不为0）或者该线程不是已经获取写锁的线程，则当前线程进入等待状态，获取写锁的代码。
//执行的是WriteLock中的lock()方法
public void lock() {
sync.acquire(1);
}
//该方法调用的是对应的sync中的父类AQS的方法。而tryAcquire(int arg)则是已经在sync中重写了，如代码二，
//该方法是AQS专门提供给子类重写的。然后先来分析下代码二tryAcquire(int acquires)
//在AQS代码中
public final void acquire(int arg) {
if (!tryAcquire(arg) &&
acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
selfInterrupt();
}
//代码二，在ReentrantReadWriteLock中
protected final boolean tryAcquire(int acquires) {
//1.获取当前线程
Thread current = Thread.currentThread();
//获取读写锁的同步状态
int c = getState();
// 2. 获取写锁获取的次数
// exclusiveCount() 里面执行的是return c & EXCLUSIVE_MASK;
//看下面的标注二
int w = exclusiveCount(c);
//如果读写状态不等于0
if (c != 0) {
// (Note: if c != 0 and w == 0 then shared count != 0)
// 3.1 当读锁已被读线程获取或者当前线程不是已经获取写锁的线程的话
// 当前线程获取写锁失败
//看下面标注一
if (w == 0 || current != getExclusiveOwnerThread())
return false;
//如果超过获取锁的次数的最大值，则抛异常
if (w + exclusiveCount(acquires) > MAX_COUNT)
//超过最大锁计数
throw new Error("Maximum lock count exceeded");
//3.2 当前线程获取写锁，支持可重复加锁
setState(c + acquires);
return true;
}
//写锁未被任何线程获取，当前线程可获取写锁
if (writerShouldBlock() ||
!compareAndSetState(c, c + acquires))
return false;
//写锁第一次获取成功，设置当前线程为写锁的线程，返回获取成功。
setExclusiveOwnerThread(current);
return true;
}
标注一:如果存在读锁，则写锁不能被获取，原因在于：读写锁要确保写锁的操作对读锁可见，如果允许读锁在已被获取的情况下对写锁的获取，那么正在运行的其他读线程就无法感知到当前写线程的操作。因此，只有等待其他读线程都释放了读锁，写锁才能被当前线程获取，而写锁一旦被获取，则其他读写线程的后续访问均被阻塞。
标注二: 其中EXCLUSIVE_MASK为: static final int EXCLUSIVE_MASK = (1 << SHARED_SHIFT) - 1; EXCLUSIVE _MASK为1左移16位然后减1，即为0x0000FFFF。而exclusiveCount方法是将同步状态（state为int类型）与0x0000FFFF相与，即取同步状态的低16位。那么低16位代表什么呢？根据exclusiveCount方法的注释为独占式获取的次数即写锁被获取的次数，现在就可以得出来一个结论同步状态的低16位用来表示写锁的获取次数。所以该方法返回的是写状态数。
然后trylock的加锁实现也是差不多的。
public boolean tryLock( ) {
return sync.tryWriteLock();
}
final boolean tryWriteLock() {
Thread current = Thread.currentThread();
int c = getState();
if (c != 0) {
int w = exclusiveCount(c);
if (w == 0 || current != getExclusiveOwnerThread())
return false;
if (w == MAX_COUNT)
throw new Error("Maximum lock count exceeded");
}
if (!compareAndSetState(c, c + 1))
return false;
setExclusiveOwnerThread(current);
return true;
}
这里不做具体的说明的，不懂得看上面注释。
写锁获取相应中断的锁方法如下(该线程被中断时，会释放锁):
public void lockInterruptibly() throws InterruptedException {
sync.acquireInterruptibly(1);
}
public final void acquireInterruptibly(int arg)
throws InterruptedException {
if (Thread.interrupted())
throw new InterruptedException();
if (!tryAcquire(arg))
doAcquireInterruptibly(arg);
}
这步如果看过AQS独占式获取同步状态的，基本也懂，实现逻辑是一样的。可以看这篇文章。(www.jianshu.com/p/e0066f934…)写锁超时获取响应中断的锁的实现也是一样的。
然后我们来研究下如何释放锁:
//在ReentrantReadWriteLock的内部中的WriteLock的重写了unLock方法，
//调用的是sync类的release，同样是重写了AQS的方法
public void unlock() {
sync.release(1);
}
//该方法在AQS类中
public final boolean release(int arg) {
//尝试释放锁成功，如果当前头节点不等于null，并且等待状态不等于0，则唤醒后继节点unparkSuccessor()
if (tryRelease(arg)) {
Node h = head;
if (h != null && h.waitStatus != 0)
unparkSuccessor(h);
return true;
}
return false;
}
//在ReentrantReadWriteLock的内部中的Sync重写了
protected final boolean tryRelease(int releases) {
//如果当前线程不是持有的线程，抛出异常
if (!isHeldExclusively())
throw new IllegalMonitorStateException();
//判断释放后，写状态的值，
int nextc = getState() - releases;
//如果是最后一次释放，则设置当前独占线程为null。
boolean free = exclusiveCount(nextc) == 0;
if (free)
setExclusiveOwnerThread(null);
setState(nextc);
return free;
}
读锁的获取
看完了写锁，现在来看看读锁，读锁不是独占式锁，即同一时刻该锁可以被多个读线程获取也就是一种共享式锁。 如果当前线程在获取读锁时，写锁已被其他线程获取，则进入等待状态。获取读锁的实现从Java 5到Java 6变得复杂许多，主要原因是新增了一些功能，例如getReadHoldCount()方法，作用是返回当前线程获取读锁的次数。读状态是所有线 程获取读锁次数的总和，而每个线程各自获取读锁的次数只能选择保存ThreadLocal中，由线程自身维护，这使获取读锁的实现变得复杂。按照之前对AQS介绍，实现共享式同步组件的同步语义需要通过重写AQS的tryAcquireShared和tryReleaseShared方法。
读锁的获取实现方法为(取tryAcquireShared重写的)：
public boolean tryLock() {
return sync.tryReadLock();
}
final boolean tryReadLock() {
Thread current = Thread.currentThread();
for (;;) {
int c = getState();
//1. 如果写锁已经被获取并且获取写锁的线程不是当前线程的话，当前
// 线程获取读锁失败返回false
if (exclusiveCount(c) != 0 &&
getExclusiveOwnerThread() != current)
return false;
//获取读状态
int r = sharedCount(c);
if (r == MAX_COUNT)
throw new Error("Maximum lock count exceeded");
//如果读状态使用CAS操作加一也就是获取读锁成功。
if (compareAndSetState(c, c + SHARED_UNIT)) {
//如果读状态为0，表示第一次读取成功，设置读状态为1
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 true;
}
}
}
读锁的释放:
读锁释放的实现主要通过方法tryReleaseShared，读锁的每次释放（线程安全的，可能有多个读线程同时释放读锁）均减少读状态，减少的值是（1<<16）源码如下
这种的实现跟写锁是一样的。还有另外一种，在下面
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;
}
//第二种:
//在ReadLock类中
public void unlock() {
sync.releaseShared(1);
}
//在AQS中
public final boolean releaseShared(int arg) {
if (tryReleaseShared(arg)) {
doReleaseShared();
return true;
}
return false;
}
//主要还是ReentrantReadWriteLock的sync类中重写tryReleaseShared
protected final boolean tryReleaseShared(int unused) {
Thread current = Thread.currentThread();
//当前线程为持有读锁的线程
if (firstReader == current) {
// assert firstReaderHoldCount > 0;
//如果当前读锁的状态值为1，则读锁只有一个。把firstReader = null;
if (firstReaderHoldCount == 1)
firstReader = null;
else
//否则firstReaderHoldCount减一
firstReaderHoldCount--;
} else {
其他情况下。
HoldCounter rh = cachedHoldCounter;
if (rh == null || rh.tid != getThreadId(current))
rh = readHolds.get();
int count = rh.count;
if (count <= 1) {
readHolds.remove();
if (count <= 0)
throw unmatchedUnlockException();
}
--rh.count;
}
//自旋获取读状态，并替换。
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;
}
}
锁降级
锁降级指的是写锁降级成为读锁。如果当前线程拥有写锁，然后将其释放，最后再获取读锁，这种分段完成的过程不能称之为锁降级。锁降级是指把持住（当前拥有的）写锁，再获取到读锁，随后释放（先前拥有的）写锁的过程。
void processCachedData() {
rwl.readLock().lock();
if (!cacheValid) {
// Must release read lock before acquiring write lock
rwl.readLock().unlock();
rwl.writeLock().lock();
try {
// Recheck state because another thread might have
// acquired write lock and changed state before we did.
if (!cacheValid) {
data = ...
cacheValid = true;
}
// Downgrade by acquiring read lock before releasing write lock
rwl.readLock().lock();
} finally {
rwl.writeLock().unlock(); // Unlock write, still hold read
}
}
try {
use(data);
} finally {
rwl.readLock().unlock();
}
}
}
