一.读写锁介绍
在Java并发包中常用的锁（如：ReentrantLock），基本上都是排他锁，这些锁在同一时刻只允许一个线程进行访问，而读写锁在同一时刻可以允许多个读线程访问，但是在写线程访问时，所有的读线程和其他写线程均被阻塞。读写锁维护了一对锁，一个读锁和一个写锁，通过分离读锁和写锁，使得并发性相比一般的排他锁有了很大提升。
二.读写锁的特性
ReentrantReadWriteLock的特性总结：
①基本性质：读锁是一个共享锁，写锁是一个独占锁。读锁能同时被多个线程获取，写锁只能被一个线程获取。读锁和写锁不能同时存在。
②重入性：一个线程可以多次重复获取读锁和写锁。
③锁降级：一个线程在已经获取写锁的情况下，可以再次获取读锁，如果线程又释放了写锁，就完成了一次锁降级。
④锁升级：ReentrantReadWriteLock不支持锁升级。一个线程在获取读锁的情况下，如果试图去获取写锁，将会导致死锁（后面会详细说明）。
⑤获取锁中断：提供了可中断的lock方法。
⑥重入数：读锁和写锁的重入上限为65535（所有线程获取的锁的总数，为什么是这个值后面会详细说明）。
⑦公平性：ReentrantReadWriteLock提供了公平&非公平两种工作模式。
三.ReentrantReadWriteLock类层次图
ReentrantReadWriterLock并不实现Lock接口，而是通过两个内部类实现Lock接口，分别是ReadLock和WriterLock类。与ReentrantLock一样，ReentrantReadWriterLock同样使用自己的内部类Sync（继承AbstractQueuedSynchronizer）实现CLH算法。
四.读写锁的接口
public interface ReadWriteLock { /** * Returns the lock used for reading. * * @return the lock used for reading */ Lock readLock(); /** * Returns the lock used for writing. * * @return the lock used for writing */ Lock writeLock(); } ReadWriteLock仅定义了获取读锁和写锁的两个方法，即readLock()和writeLock()方法，而其实现— ReentrantReadWriteLock，除了接口方法之外，还提供了一些便于外界监控其内部工作状态的方法。
ReentrantReadWriteLock展示内部工作状态的方法：
//返回当前读锁被获取的次数。该次数不等于获取读锁的线程数， // 比如：仅一个线程，它连续获取（重进入）了n次读锁，那么占据读锁的线程数是1，但该方法返回n int getReadLockCount() //返回当前线程获取读锁的次数。该方法在Java 6 中加入ReentrantReadWriteLock //中，使用ThreadLocal保存当前线程获取的次数，这也使得Java 6 的实现变得更//加复杂 int getReadHoldCount() //判断写锁是否被获取 boolean isWriteLocked() //返回当前写锁被获取的次数 int getWriteHoldCount() 五.《java并发编程的艺术》一书上读写锁的demo
package com.secondbook.thread.lock; import java.util.HashMap; import java.util.Map; import java.util.concurrent.locks.Lock; import java.util.concurrent.locks.ReentrantReadWriteLock; /** * Created by w1992wishes on 2017/6/2. */ public class ReadWriterLockForCache { static Map<String, Object> cache = new HashMap<>(); static ReentrantReadWriteLock lock = new ReentrantReadWriteLock(); static Lock r = lock.readLock(); static Lock w = lock.writeLock(); //获取key对应的value public static final Object get(String key){ r.lock(); try { return cache.get(key); }finally { r.unlock(); } } // 设置key对应的value，并返回旧的value public static final Object put(String key, Object value){ w.lock(); try{ return cache.put(key, value); }finally { w.unlock(); } } // 清空所有的内容 public static final void clear(){ w.lock(); try { cache.clear(); }finally { w.unlock(); } } } ReadWriterLockForCache组合一个非线程安全的HashMap作为缓存的实现，同时使用读写锁的读锁和写锁来保证ReadWriterLockForCache是线程安全的。在读操作get(String key)方法中，需要获取读锁，这使得并发访问该方法时不会被阻塞。写操作put(String key,Object value)方法和clear()方法，在更新HashMap时必须提前获取写锁，当获取写锁后，其他线程对于读锁和写锁的获取均被阻塞，而只有写锁被释放之后，其他读写操作才能继续。ReadWriterLockForCache使用读写锁提升读操作的并发性，也保证每次写操作对所有的读写操作的可见性，同时简化了编程方式。
六.读写锁的实现分析
ReentrantReadWriterLock使用一个32位的int类型来表示锁被占用的线程数（ReentrantLock中的state），如果在一个整型变量上维护多种状态，就需要“按位切割使用”这个变量，高16位用来表示读锁占有的线程数量，用低16位表示写锁被同一个线程申请的次数。
上图是一个划分图，表示一个线程已经获取了写锁，且重进入了两次，同时也连续获取了两次读锁。
读写锁是通过位运算迅速确定读和写各自的状态。假设当前同步状态值为S，写状态等于S&0x0000FFFF（将高16位全部抹去），读状态等于S>>>16（无符号补0右移16位）。当写状态增加1时，等于S+1，当读状态增加1时，等于S+(1<<16)，也就是S+0x00010000。
根据状态的划分能得出一个推论：S不等于0时，当写状态（S&0x0000FFFF）等于0时，则读状态（S>>>16）大于0，即读锁已被获取。
6.1 读锁的获取
写锁是一个支持重进入的排它锁。如果当前线程已经获取了写锁，则增加写状态。如果当前线程在获取写锁时，读锁已经被获取（读状态不为0）或者该线程不是已经获取写锁的线程，则当前线程进入等待状态。
读锁的lock方法在ReentrantReadWriteLock中：
public void lock() { sync.acquireShared(1); } sync.acquireShared方法存在于AbstractQueuedSynchronizer类中：
public final void acquireShared(int arg) { if (tryAcquireShared(arg) < 0) doAcquireShared(arg); } ReentrantReadWriteLock中的tryAcquire：protected final int tryAcquireShared(int unused) { /* * Walkthrough: * 1. If write lock held by another thread, fail. * 2. Otherwise, this thread is eligible for * lock wrt state, so ask if it should block * because of queue policy. If not, try * to grant by CASing state and updating count. * Note that step does not check for reentrant * acquires, which is postponed to full version * to avoid having to check hold count in * the more typical non-reentrant case. * 3. If step 2 fails either because thread * apparently not eligible or CAS fails or count * saturated, chain to version with full retry loop. */ Thread current = Thread.currentThread(); //@1 start int c = getState(); if (exclusiveCount(c) != 0 && getExclusiveOwnerThread() != current) return -1; // @1 end int r = sharedCount(c); if (!readerShouldBlock() && r < MAX_COUNT && compareAndSetState(c, c + SHARED_UNIT)) { // @2 if (r == 0) { //@21 firstReader = current; firstReaderHoldCount = 1; } else if (firstReader == current) { //@22 firstReaderHoldCount++; } else { // @23 HoldCounter rh = cachedHoldCounter; if (rh == null || rh.tid != current.getId()) cachedHoldCounter = rh = readHolds.get(); else if (rh.count == 0) readHolds.set(rh); rh.count++; } return 1; } return fullTryAcquireShared(current); // @3 }@1，start–end ，如果有线程已经抢占了写锁，并且不是当前线程，则直接返回-1，通过排队获取锁。
@2，如果线程不需要阻塞，并且获取读锁的线程数没有超过最大值，并且使用 CAS更新共享锁线程数量成功的话；表示成获取读锁，然后进行内部变量的相关更新操作；先关注一下，成功获取读锁后，内部变量的更新操作。
@21，如果r=0, 表示，当前线程为第一个获取读锁的线程。
@22，如果第一个获取读锁的对象为当前对象，将firstReaderHoldCount 加一。
@23，成功获取锁后，如果不是第一个获取多锁的线程，将该线程持有锁的次数信息，放入线程本地变量中，方便在整个请求上下文（请求锁、释放锁等过程中）使用持有锁次数信息。
@3，如果CAS失败或readerShouldBlock方法返回true，我们调用fullTryAcquireShared方法继续试图获取读锁。fullTryAcquireShared方法是tryAcquireShared方法的完整版，或者叫升级版，它处理了CAS失败的情况和readerShouldBlock返回true的情况。
readerShouldBlock区分公平和非公平模式两种：
公平模式下，根据等待队列中在当前线程之前有没有等待线程来判断：
final boolean readerShouldBlock() { return hasQueuedPredecessors(); }而在非公平模式下：
final boolean readerShouldBlock() { /* As a heuristic to avoid indefinite writer starvation, * block if the thread that momentarily appears to be head * of queue, if one exists, is a waiting writer. This is * only a probabilistic effect since a new reader will not * block if there is a waiting writer behind other enabled * readers that have not yet drained from the queue. */ return apparentlyFirstQueuedIsExclusive(); } 调用了apparentlyFirstQueuedIsExclusive方法：
final boolean apparentlyFirstQueuedIsExclusive() { Node h, s; return (h = head) != null && (s = h.next) != null && !s.isShared() && s.thread != null; } 该方法如果头节点不为空，并头节点的下一个节点不为空，并且不是共享模式【独占模式，写锁】、并且线程不为空，则返回true。
这个方法判断队列的head.next是否正在等待独占锁（写锁）。当然这个方法执行的过程中队列的形态可能发生变化。这个方法的意思是：读锁不应该让写锁始终等待。
现在再来看fullTryAcquireShared方法：
final int fullTryAcquireShared(Thread current) { /* * This code is in part redundant with that in * tryAcquireShared but is simpler overall by not * complicating tryAcquireShared with interactions between * retries and lazily reading hold counts. */ HoldCounter rh = null; for (;;) { int c = getState(); if (exclusiveCount(c) != 0) { if (getExclusiveOwnerThread() != current) return -1; // else we hold the exclusive lock; blocking here // would cause deadlock. } else if (readerShouldBlock()) { // Make sure we're not acquiring read lock reentrantly if (firstReader == current) { // assert firstReaderHoldCount > 0; } else { if (rh == null) { rh = cachedHoldCounter; if (rh == null || rh.tid != getThreadId(current)) { rh = readHolds.get(); if (rh.count == 0) readHolds.remove(); } } if (rh.count == 0) return -1; } } if (sharedCount(c) == MAX_COUNT) throw new Error("Maximum lock count exceeded"); if (compareAndSetState(c, c + SHARED_UNIT)) { if (sharedCount(c) == 0) { firstReader = current; firstReaderHoldCount = 1; } else if (firstReader == current) { firstReaderHoldCount++; } else { if (rh == null) rh = cachedHoldCounter; if (rh == null || rh.tid != getThreadId(current)) rh = readHolds.get(); else if (rh.count == 0) readHolds.set(rh); rh.count++; cachedHoldCounter = rh; // cache for release } return 1; } } }首先检查是否有其他线程正在持有写锁，如果是，直接返回false。
如果没有线程正在持有写锁，则调用readerShouldBlock检测当前线程是否应该进入等待队列。就算readerShouldBlock方法返回true，原因可能因为当前是公平模式或者队列的第一个等待线程（head.next）正在等待写锁，也不能直接返回false，因为返回false意味着当前线程将要进入等待队列（见AQS的acquireShared方法），原因是：①如果当前线程正在持有读锁，且这次读锁的重入被放入等待队列，万一之前队列中有线程正在等待写锁，将会导致死锁；②另一种情况是当前线程正在持有写锁，且这次读锁的“降级申请”被放入等待队列，如果队列中之前有线程正在等待锁，不论等待的是写锁还是读锁，都将导致死锁。
成功获取读锁，后续就是更新readHolds等内部变量。
如果返回-1,那么需要排队申请,具体要看acquireShared方法中的doAcquireShared(arg)。
private void doAcquireShared(int arg) { final Node node = addWaiter(Node.SHARED); boolean failed = true; try { boolean interrupted = false; for (;;) { final Node p = node.predecessor(); if (p == head) { int r = tryAcquireShared(arg); if (r >= 0) { setHeadAndPropagate(node, r); p.next = null; // help GC if (interrupted) selfInterrupt(); failed = false; return; } } if (shouldParkAfterFailedAcquire(p, node) && parkAndCheckInterrupt()) interrupted = true; } } finally { if (failed) cancelAcquire(node); } } 读锁的申请的申请流程图如下：
6.2 读锁的释放
public void unlock() { sync.releaseShared(1); } readLock的unlock方法调用AQS提供的releaseShared方法实现：
public final boolean releaseShared(int arg) { if (tryReleaseShared(arg)) { doReleaseShared(); return true; } return false; } 自定义同步器Sync重写的tryReleaseShared方法：
protected final boolean tryReleaseShared(int unused) { Thread current = Thread.currentThread(); if (firstReader == current) { // assert firstReaderHoldCount > 0; if (firstReaderHoldCount == 1) firstReader = null; else 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; } } 读锁的每次释放（线程安全的，可能有多个读线程同时释放读锁）均减少读状态，减少的值是（1<<16）。
6.3 写锁的获取与释放
写锁是互斥锁，相对读锁实现要简单一些，具体就不往下了。
