锁性能提升——ReadWriteLock

这篇文章主要记录下ReadWriteLock的实现原理与用处，ReentrantLock可以实现线程安全，但是它的锁粒度太大，和Synchronized一样要么获取锁要么阻塞，与数据库共享锁与排他锁的思想类似，其实读操作与读操作是不用互相阻塞的，读写锁就是解决这个问题。

1、 ReadWriteLock

ReadWriteLock的定义如下，从定义可以看出实现了读写锁的分离：

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();
}

我们一般使用是它的实现类ReentrantReadWriteLock：

 public ReentrantReadWriteLock(boolean fair) {
    sync = fair ? new FairSync() : new NonfairSync();
    readerLock = new ReadLock(this);
    writerLock = new WriteLock(this);
}

2、AQS

Java的很多同步机制像ReentrantLock、Semphore、CountDownLatch等等都是使用AQS(AbstractQueuedSynchronizer)实现的，AQS抽象类提供了同步实现的框架，它的核心在于state、tryAcquire、tryRelease三个域属性，通过state来保存信号量/锁的状态或者个数，然后获取与释放的tryAcquire、tryRelease操作就是通过对state状态的修改来实现的。

3、ReentrantReadWriteLock

ReentrantReadWriteLock中的sync实现了AQS类并定义了自己的acquire、release方法。当我们调用readerLock.lock/unlock时就是调用的sync的tryAcquireShared与tryReleaseShared方法，同样writerLock.lock/unlock调用的是tryAcquire与tryRelease方法。先看看ReentrantReadWriteLock中AQS的变量的定义：

  abstract static class Sync extends AbstractQueuedSynchronizer {
    private static final long serialVersionUID = 6317671515068378041L;

    /*
     * Read vs write count extraction constants and functions.
     * Lock state is logically divided into two unsigned shorts:
     * The lower one representing the exclusive (writer) lock hold count,
     * and the upper the shared (reader) hold count.
     */

    static final int SHARED_SHIFT   = 16;
    static final int SHARED_UNIT    = (1 << SHARED_SHIFT);
    static final int MAX_COUNT      = (1 << SHARED_SHIFT) - 1;
    static final int EXCLUSIVE_MASK = (1 << SHARED_SHIFT) - 1;

    /** Returns the number of shared holds represented in count. */
    static int sharedCount(int c)    { return c >>> SHARED_SHIFT; }
    /** Returns the number of exclusive holds represented in count. */
    static int exclusiveCount(int c) { return c & EXCLUSIVE_MASK; }

    /**
     * A counter for per-thread read hold counts.
     * Maintained as a ThreadLocal; cached in cachedHoldCounter.
     */
    static final class HoldCounter {
        int count;          // initially 0
        // Use id, not reference, to avoid garbage retention
        final long tid = LockSupport.getThreadId(Thread.currentThread());
    }

    /**
     * ThreadLocal subclass. Easiest to explicitly define for sake
     * of deserialization mechanics.
     */
    static final class ThreadLocalHoldCounter
        extends ThreadLocal<HoldCounter> {
        public HoldCounter initialValue() {
            return new HoldCounter();
        }
    }

    /**
     * The number of reentrant read locks held by current thread.*/
    private transient ThreadLocalHoldCounter readHolds;

    /**
     * The hold count of the last thread to successfully acquire
     * readLock. */
    private transient HoldCounter cachedHoldCounter;

    private transient Thread firstReader;
    private transient int firstReaderHoldCount;

这里只列出了重要的部分，之前说AQS的一个重点在于state，在ReentrantReadWriteLock中由于有读锁和写锁，但是只有一个state值，因为state是一个int值，所以这里的实现是高16位保存读锁的状态，低16位保存写锁的状态：

static final int SHARED_SHIFT   = 16;
static final int SHARED_UNIT    = (1 << SHARED_SHIFT);
static final int MAX_COUNT      = (1 << SHARED_SHIFT) - 1;
static final int EXCLUSIVE_MASK = (1 << SHARED_SHIFT) - 1;

/** Returns the number of shared holds represented in count. */   //这个c就是state值
static int sharedCount(int c)    { return c >>> SHARED_SHIFT; }
/** Returns the number of exclusive holds represented in count. */
static int exclusiveCount(int c) { return c & EXCLUSIVE_MASK; }

有了上面的基础，就可以看读写锁获取与释放锁的具体实现了，先看readLock的acquire方法：

@ReservedStackAccess
    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();
        int c = getState();       //获取state值
        if (exclusiveCount(c) != 0 &&          //如果有写锁，并且持有写锁的不是当前线程，则获取读锁失败
            getExclusiveOwnerThread() != current)
            return -1;
        int r = sharedCount(c);             //当前读锁的数量
        if (!readerShouldBlock() &&
            r < MAX_COUNT &&
            compareAndSetState(c, c + SHARED_UNIT)) {   //通过CAS来更新state(读锁数量+1)
            if (r == 0) {
                firstReader = current;
                firstReaderHoldCount = 1;     
            } else if (firstReader == current) {
                firstReaderHoldCount++;
            } else {

              //这里注意因为锁是可重入的，cachedHoldCounter记录了最后1个获取读锁的线程的重入次数。
              //firstReaderHoldCounter记录了第一个获取读锁的线程的重入次数
             //对读锁进行计数时需要对每个线程持有的读锁分别计数。 
             //HoldCounter 是一个ThreadLocal对象，使用它来记录线程持有的读锁数量
                HoldCounter rh = cachedHoldCounter;
                if (rh == null ||
                    rh.tid != LockSupport.getThreadId(current))
                    cachedHoldCounter = rh = readHolds.get();
                else if (rh.count == 0)
                    readHolds.set(rh);
                rh.count++;
            }
            return 1;
        }
        return fullTryAcquireShared(current);
    }

再看看readLock的release方法，获取锁的时候计数增加，释放锁自然是计数减少：

   @ReservedStackAccess
    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 != LockSupport.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;
        }
    }

对于writeLock，因为写锁是排他的，所以更改状态(写锁数量)就行了，因为锁的可重入性，所以状态值也可能是任意值：

    /*
     * Note that tryRelease and tryAcquire can be called by
     * Conditions. So it is possible that their arguments contain
     * both read and write holds that are all released during a
     * condition wait and re-established in tryAcquire.
     */
    @ReservedStackAccess
    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;
    }

    @ReservedStackAccess
    protected final boolean tryAcquire(int acquires) {
        /*
         * Walkthrough:
         * 1. If read count nonzero or write count nonzero
         *    and owner is a different thread, fail.
         * 2. If count would saturate, fail. (This can only
         *    happen if count is already nonzero.)
         * 3. Otherwise, this thread is eligible for lock if
         *    it is either a reentrant acquire or
         *    queue policy allows it. If so, update state
         *    and set owner.
         */
        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)
            //  // c!=0,w==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;
    }
  }

4、其他

除了上面的基础讲解，ReentrantReadWriteLock还有一些其他的特性：

1、公平锁与非公平锁(公平模式下锁的申请都必须按照AQS锁等待队列先进先出，非公平下可插队)
2、如果1个线程获得了读锁，那么它不能同时再获得写锁，这个就是所谓的“锁升级”，读锁升级到写锁可能会造成死锁，所以是不允许的；如果1个线程获得了写锁，那么不允许其他线程再获得读锁和写锁，但是它自己可以获得读锁，就是所谓的“锁降级”