ReentrantReadWriteLock 讀寫鎖解析

1. 鎖介紹

　　java中鎖是個很重要的概念，當然這里的前提是你會涉及並發編程。

　　除了語言提供的鎖關鍵字 synchronized和volatile之外，jdk還有其他多種實用的鎖。

　　不過這些鎖大多都是基於AQS隊列同步器。ReadWriteLock 讀寫鎖就是其中一個。

　　讀寫鎖的含義是，將讀鎖與寫鎖分開對待，讀鎖可以任意個一起讀，因為讀並不涉及數據變更，而遇到寫鎖后，所有后續的讀寫都將被阻塞。這特性有什么用呢？比如我們有一個緩存，我們可以用它來提高訪問速度，但是當數據變更時，怎樣能保證能讀到准確的數據？

　　在沒有讀寫鎖之前，我們可以使用wait/notify機制，我們可以以寫鎖作為一個同步介質，當寫鎖被占用時，讀只能等待，寫操作完成后，通知所有讀繼續。這看起來不那么好實現！

　　當有了讀寫鎖后，我們就不需要這么麻煩了，只需要讀操作使用讀鎖，寫操作獲取寫鎖操作。大家可能會想，既然都要獲取鎖，那和其他鎖有什么差別呢，一般看到鎖咱們都會想到串行，阻塞。但其實讀寫鎖不是這樣的。看起來你是每次都獲取讀鎖，但其實單純的讀鎖並不會阻塞線程，所以同樣是並行無阻，讀鎖只有在一種情況下會阻塞，那就是寫鎖被某線程占用時。因為寫鎖被占用則意味着，數據可能馬上發生變化，如果此再允許讀操作任意進行的話，多半可能讀到寫了一半或者是老數據，而這簡直太糟了。而寫鎖則只每次都會真正進行后續操作的阻塞動作，使寫操作保證強一致性。

　　好了，以上就是咱們從概念上來理解讀寫鎖。

　　而實際上呢？ReadWriteLock只是一個接口，而其實現則可能是n多的。我們就以jdk實現的 ReentrantReadWriteLock 為契機，看一下讀寫鎖的實現吧。

　　在介紹 ReetrantReadWriteLock 之前，我們要先簡單說下 ReentrantLock 重入鎖，從字面意思理解，就是可重新進入的鎖。那么，到底是什么意思呢？我們想一下，如果我們有2個資源鎖可用，那么，如果我在本線程上上鎖兩次，是不是資源就沒有了呢，那第三次進行鎖獲取的時候，是不是就把自己給鎖死了呢？想想應該是這樣的，但是為啥平時咱們都遇不到這種情況呢？原因就在於可重入性。可重入的意思是說，如果當前線程進行多次加鎖操作，那么無論如何它自己都是可以進入的。簡單從實現來說就是，鎖會排除當前線程，從而避免自身阻塞。這些需求看起來很理所當然，但是咱們自己實現的時候可能會因為場景不一樣，從而不一定需要這種特性呢。syncronized也是一種重入鎖。好了，說了這么多，還是沒有看到 ReetrantLock是怎么實現的！

用個不恰當的圖描繪下：（該鎖是讀寫分離的，讀多於寫的場景能夠在保證線程安全的同時提供盡可能大的並發能力）

 

2. 簡單沒獲取

我們來看下源碼就一目了然了。

        /**
         * Fair version of tryAcquire
         */
        protected final boolean tryAcquire(int acquires) {
            final Thread current = Thread.currentThread();
            int c = getState();
            if (c == 0) {
                if (!hasQueuedPredecessors() &&
                    compareAndSetState(0, acquires)) {
                    // 第一次進入獲取到鎖后，標記獲得鎖的線程，后續判定重入
                    setExclusiveOwnerThread(current);
                    return true;
                }
            }
            // 重入鎖判定，否則失敗
            else if (current == getExclusiveOwnerThread()) {
                // 最多可重入 int 次
                int nextc = c + acquires;
                if (nextc < 0)
                    throw new Error("Maximum lock count exceeded");
                setState(nextc);
                return true;
            }
            return false;
        }
    }

 

　　重入鎖介紹完后，咱們可以安心的來說說 ReentrantReadWriteLock了。該讀寫鎖也是一種可重入鎖。它要實現的特性就是，讀讀鎖無阻塞，寫鎖必阻塞（包括寫讀鎖/寫寫鎖），讀寫鎖阻塞（需等待讀鎖釋放后才能獲取寫鎖從而保證無臟讀）。

　　從上面可以看出，讀和寫是兩個鎖，但是他們的狀態卻是互相關聯的，那怎樣設計其數據結構呢？用兩個變量去推導往往不太可行，因為其本身就是鎖，如果再用兩個變量去判定鎖狀態，那么又如何保證變量自身的可靠性呢？ReentrantReadWriteLock 是通過一個狀態變量來控制的，具體為 高16位保存讀鎖狀態，低16位保存寫鎖狀態，而在改變狀態時，使用cas保證寫入的可靠性。（其實這里可以看出，鎖個數不應該超過16位即65536個，這種鎖數量已經完全被忽略掉了）。有了數據結構，咱們再看下怎么控制讀寫互聯。讀鎖的獲取，寫鎖沒被占用時，即低位為0時，高位大於0即可代表獲取了讀鎖，所以，讀鎖是n個可用的。而寫鎖的獲取，則要依賴高低位判定了，高位大於0，即代表還有讀鎖存在，不能進入，如果高位為0，也不一定可進入，低位不為0則代表有寫鎖在占用，所以只有高低位都為0時，寫鎖才可用。

　　下面，來看下讀寫鎖的具體實現！

3. 來個例子先:

public class ReadWriteLockTest {

    private ReentrantReadWriteLock reentrantReadWriteLock = new ReentrantReadWriteLock();
    /**
     * 讀鎖
     */
    private Lock r = reentrantReadWriteLock.readLock();

    /**
     * 寫鎖
     */
    private Lock w = reentrantReadWriteLock.writeLock();

    /**
     * 執行線程池
     */
    private ExecutorService executorService = Executors.newCachedThreadPool();

    @Test
    public void testReadLock() {
        for (int i = 0; i < 10; i++) {
            Thread readWorker = new ReadWorker();
            executorService.submit(readWorker);
        }
        waitForExecutorFinish();
    }

    @Test
    public void testWriteLock() {
        for (int i = 0; i < 10; i++) {
            Thread writeWorker = new WriteWorker();
            executorService.submit(writeWorker);
        }
        waitForExecutorFinish();
    }

    @Test
    public void testReadWriteLock() {
        for (int i = 0; i < 10; i++) {
            Thread readWorker = new ReadWorker();
            Thread writeWorker = new WriteWorker();
            executorService.submit(readWorker);
            executorService.submit(writeWorker);
        }
        waitForExecutorFinish();
    }

    /**
     * 線程模擬完成后，關閉線程池
     */
    private void waitForExecutorFinish() {
        executorService.shutdown();
        try {
            executorService.awaitTermination(100, TimeUnit.SECONDS);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }

    private final class ReadWorker extends Thread {
        @Override
        public void run() {
            r.lock();
            try {
                SleepUtils.second(1);
                System.out.println(System.currentTimeMillis() + ": " + Thread.currentThread().getName() + " reading...");
                SleepUtils.second(1);
            }
            finally {
                r.unlock();
            }
        }
    }

    private final class WriteWorker extends Thread {
        @Override
        public void run() {
            w.lock();
            try {
                SleepUtils.second(1);
                System.out.println(System.currentTimeMillis() + ": " + Thread.currentThread().getName() + " writing...");
                SleepUtils.second(1);
            }
            finally {
                w.unlock();
            }
        }
    }

}

　　可以看到 testReadLock(), 無阻塞，立即完成10個讀任務！

　　而 testWriteLock()，則是全部阻塞執行，20秒完成串行10個任務！

　　而 testReadWriteLock(), 則是 讀鎖與寫鎖交替執行，在執行寫鎖時，所有鎖等待，在執行讀鎖時，可能存在多個鎖同時運行！執行結果樣例如下:

1543816105277: pool-1-thread-1 reading...
1543816107278: pool-1-thread-2 writing...
1543816109278: pool-1-thread-20 writing...
1543816111278: pool-1-thread-16 writing...
1543816113279: pool-1-thread-12 writing...
1543816115279: pool-1-thread-8 writing...
1543816117280: pool-1-thread-19 reading...
1543816117280: pool-1-thread-15 reading...
1543816119280: pool-1-thread-4 writing...
1543816121280: pool-1-thread-18 writing...
1543816123281: pool-1-thread-3 reading...
1543816123281: pool-1-thread-7 reading...
1543816125287: pool-1-thread-14 writing...
1543816127290: pool-1-thread-6 writing...
1543816129290: pool-1-thread-10 writing...
1543816131290: pool-1-thread-11 reading...
1543816131290: pool-1-thread-13 reading...
1543816131290: pool-1-thread-9 reading...
1543816131290: pool-1-thread-5 reading...
1543816131290: pool-1-thread-17 reading...

 

　　ok, 現象已經展示了，是時候透過現象看本質了！

4. 讀鎖的獲取過程 r.lock(), 其實現為 ReadLock！

        public void lock() {
            // 調用 AQS 的 acquireShared() 方法，進行統一調度
            sync.acquireShared(1);
        }
    // AQS 獲取共享讀鎖    
    public final void acquireShared(int arg) {
        // 調用 ReentrantReadWriteLock.Sync.tryAcquireShared(), 定義鎖獲取方式
        if (tryAcquireShared(arg) < 0)
            doAcquireShared(arg);
    }
    
    
    // 獲取讀鎖，unused 傳參未使用，直接使用內置的高位加1方式處理
        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();
            // 寫鎖使用中，則直接獲取失敗
            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);
        }
        
        // 獲取低位數，即寫鎖狀態值
        static int exclusiveCount(int c) {
            return c & EXCLUSIVE_MASK; 
        }
        // 獲取高位數，即讀鎖狀態值
        static int sharedCount(int c) { 
            return c >>> SHARED_SHIFT; 
        }
        
        /**
         * Full version of acquire for reads, that handles CAS misses
         * and reentrant reads not dealt with in tryAcquireShared.
         */
        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");
                // 驗證通過，cas更新鎖狀態，使用 SHARED_UNIT 進行高位加1
                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;
                }
            }
        }

　　以上是獲取讀鎖的過程，其實際控制很簡單，只是多了很多的狀態統計，所以看起來復雜！

5. 下面，來看寫鎖的獲取過程，WriteLock.lock()

        public void lock() {
            // AQS獲取獨占鎖
            sync.acquire(1);
        }
        
    // AQS 鎖調度
    public final void acquire(int arg) {
        // 如果獲取鎖失敗，則加入到等待隊列中
        if (!tryAcquire(arg) &&
            acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
            selfInterrupt();
    }

    // ReentrantReadWriteLock.Sync.tryAcquire(), 寫鎖獲取過程
        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);
            // 如果是0，則說明不存在讀寫鎖，直接成功
            // 否則分有讀鎖和有寫鎖兩種情況判斷
            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;
            }
            // cas 更新 state 
            if (writerShouldBlock() ||
                !compareAndSetState(c, c + acquires))
                return false;
            setExclusiveOwnerThread(current);
            return true;
        }
        
    /**
     * Creates and enqueues node for current thread and given mode.
     *
     * @param mode Node.EXCLUSIVE for exclusive, Node.SHARED for shared
     * @return the new node
     */
    private Node addWaiter(Node mode) {
        Node node = new Node(Thread.currentThread(), mode);
        // Try the fast path of enq; backup to full enq on failure
        Node pred = tail;
        if (pred != null) {
            node.prev = pred;
            if (compareAndSetTail(pred, node)) {
                pred.next = node;
                return node;
            }
        }
        enq(node);
        return node;
    }

    // AQS 的鎖入隊列操，從隊列中進行鎖獲取，如果獲取失敗，則產線一個中斷標志
    final boolean acquireQueued(final Node node, int arg) {
        boolean failed = true;
        try {
            boolean interrupted = false;
            for (;;) {
                final Node p = node.predecessor();
                // 這里是公平鎖的實現方式，只會從隊列頭獲取鎖
                if (p == head && tryAcquire(arg)) {
                    setHead(node);
                    p.next = null; // help GC
                    failed = false;
                    return interrupted;
                }
                // 阻塞判定，響應中斷
                if (shouldParkAfterFailedAcquire(p, node) &&
                    parkAndCheckInterrupt())
                    interrupted = true;
            }
        } finally {
            if (failed)
                cancelAcquire(node);
        }
    }

　　ok, 讀寫鎖的獲取已經完成，再來看一下釋放的過程！

5. 讀鎖的釋放 ReadLock.unlock()

        public void unlock() {
            // AQS 的釋放控制
            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;
                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;
                // cas更新狀態，每次減1，直到為0，鎖才算真正釋放
                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;
            }
        }
        
    /**
     * Release action for shared mode -- signals successor and ensures
     * propagation. (Note: For exclusive mode, release just amounts
     * to calling unparkSuccessor of head if it needs signal.)
     */
    private void doReleaseShared() {
        /*
         * Ensure that a release propagates, even if there are other
         * in-progress acquires/releases.  This proceeds in the usual
         * way of trying to unparkSuccessor of head if it needs
         * signal. But if it does not, status is set to PROPAGATE to
         * ensure that upon release, propagation continues.
         * Additionally, we must loop in case a new node is added
         * while we are doing this. Also, unlike other uses of
         * unparkSuccessor, we need to know if CAS to reset status
         * fails, if so rechecking.
         */
        for (;;) {
            Node h = head;
            if (h != null && h != tail) {
                int ws = h.waitStatus;
                if (ws == Node.SIGNAL) {
                    if (!compareAndSetWaitStatus(h, Node.SIGNAL, 0))
                        continue;            // loop to recheck cases
                    unparkSuccessor(h);
                }
                else if (ws == 0 &&
                         !compareAndSetWaitStatus(h, 0, Node.PROPAGATE))
                    continue;                // loop on failed CAS
            }
            if (h == head)                   // loop if head changed
                break;
        }
    }

6. 讀鎖的釋放, WriteLock.unlock()

        public void unlock() {
            // AQS 釋放控制
            sync.release(1);
        }
    // AQS
    public final boolean release(int arg) {
        if (tryRelease(arg)) {
            Node h = head;
            // 釋放鎖
            if (h != null && h.waitStatus != 0)
                unparkSuccessor(h);
            return true;
        }
        return false;
    }
        // Sync.tryRelease()
        protected final boolean tryRelease(int releases) {
            if (!isHeldExclusively())
                throw new IllegalMonitorStateException();
            int nextc = getState() - releases;
            // 如果寫鎖狀態為0，則意味着當前線程完全釋放鎖，將 owner 線各設置為null
            boolean free = exclusiveCount(nextc) == 0;
            if (free)
                setExclusiveOwnerThread(null);
            setState(nextc);
            return free;
        }
    
    /**
     * Wakes up node's successor, if one exists.
     *
     * @param node the node
     */
    private void unparkSuccessor(Node node) {
        /*
         * If status is negative (i.e., possibly needing signal) try
         * to clear in anticipation of signalling.  It is OK if this
         * fails or if status is changed by waiting thread.
         */
        int ws = node.waitStatus;
        if (ws < 0)
            compareAndSetWaitStatus(node, ws, 0);

        /*
         * Thread to unpark is held in successor, which is normally
         * just the next node.  But if cancelled or apparently null,
         * traverse backwards from tail to find the actual
         * non-cancelled successor.
         */
        Node s = node.next;
        if (s == null || s.waitStatus > 0) {
            s = null;
            for (Node t = tail; t != null && t != node; t = t.prev)
                if (t.waitStatus <= 0)
                    s = t;
        }
        // 調用 LockSupport 釋放鎖
        if (s != null)
            LockSupport.unpark(s.thread);
    }

 

 7. 鎖降級

       鎖降級是指把寫鎖降級為讀鎖。如果當前線程，然后將其釋放，最后再獲取讀鎖，最后再獲取讀鎖，這種不能稱為鎖降級！

       鎖降級是指把持住當前的寫鎖，再獲取到讀鎖，隨后釋放寫鎖的過程；

       鎖降級的兩個重要問題：

             1. 為什么擁有了寫鎖，還要去再獲取讀鎖？

             2. 既然已經被寫鎖占有了，還能獲取讀鎖嗎？

       回答完上面兩個問題，才算真正明白鎖降級的意義所在！

             1. 再次想獲取讀鎖的目的在於，讀和寫模塊是分開的，而更新操作則可能在讀的時候觸發的。比如在讀的時候發現數據過期了，這時就要調用寫操作，而此時讀鎖又不能釋放，所以需要在安全的情況下，釋放和重新獲取讀鎖；

             2. 在寫鎖已經被獲取的情況下，當前線程的讀鎖是可重入的，所以讀鎖對當前線程是開放的。而且，當前線程重新獲取讀鎖后，其他線程的寫鎖將會被延遲獲取，從而更高效地保證了當前線程的運行效率；

　　綜上，讀寫鎖的簡要解析就算完成了。 其主要使用 AQS 的基礎組件，進行鎖調度！ 使用CAS進行狀態的安全設置！ 而鎖的阻塞，則是使用 LockSupport 工具組件進行實際阻塞！