通俗易懂的 ReentrantLock，不懂你來砍我

前言

自己開的坑，跪着也要填完，歡迎來到 Java 併發編程系列第五篇ReentrantLock，文章風格依然是圖文並茂，通俗易懂，本文帶讀者們深入理解ReentrantLock設計思想。

認識下 ReentrantLock

阿星先帶讀者們和ReentrantLock見個面，簡單的認識下什麼是ReentrantLock。

ReentrantLock是可重入的互斥鎖，雖然具有與synchronized相同功能，但是會比synchronized更加靈活（具有更多的方法）。

ReentrantLock底層基於AbstractQueuedSynchronizer實現，AbstractQueuedSynchronizer在前一篇已經詳細解剖過了，本文不做過多描述，但是會簡單的介紹下，照顧小白。

AbstractQueuedSynchronizer抽象類定義了一套多線程訪問共享資源的同步模板，解決了實現同步器時涉及的大量細節問題，能夠極大地減少實現工作，用大白話來說，AbstractQueuedSynchronizer爲加鎖和解鎖過程提供了統一的模板函數，只有少量細節由子類自己決定。

經過上述介紹，相信讀者們對ReentrantLock有了初步的影響，下面開始發車了~

ReentrantLock 結構組成

阿星覺得，學任何知識的第一件事，就是看清它的全貌，梳理出整體結構與主流程，之後逐個擊破，所以阿星帶讀者們先看下ReentrantLock整體結構組成，對它的實現有個大致的瞭解。

上圖可以看出來，ReentrantLock整體結構還是非常簡單，阿星給讀者們分析一波，爲什麼ReentrantLock結構是這樣設計的，首先ReentrantLock實現了Lock接口，Lock接口是Java中對鎖操作行爲的統一規範，遵守規則規範是守法公民的基本素養，合情合理，Lock接口的定義如下

public interface Lock {

    /**
     * 獲取鎖
     */
    void lock();

    /**
     * 獲取鎖-響應中斷 
     */
    void lockInterruptibly() throws InterruptedException;

    /**
     * 返回獲取鎖是否成功狀態
     */
    boolean tryLock();

    /**
     * 返回獲取鎖是否成功狀態-響應中斷 
     */
    boolean tryLock(long time, TimeUnit unit) throws InterruptedException;

    /**
     * 釋放鎖
     */
    void unlock();

    /**
     * 創建條件變量
     */
    Condition newCondition();
}

Lock接口定義的函數不多，接下來ReentrantLock要去實現這些函數，遵循着解耦可擴展設計，ReentrantLock內部定義了專門的組件Sync， Sync繼承AbstractQueuedSynchronizer提供釋放資源的實現，NonfairSync和FairSync是基於Sync擴展的子類，即ReentrantLock的非公平模式與公平模式，它們作爲Lock接口功能的基本實現。

大白話來說，企業的老闆，爲了響應政府的政策，需要對企業內部做調整，但是政府每年政策都不一樣，每次都要自己去親力親爲，索性長痛不如短痛，專門成立一個政策應對部門，以後這些事情都交予這個部門去做，老闆只需要指揮它們就好了。

ReentrantLock結構組成讀者們也清楚了，下面阿星只需對Sync、NonfairSync、FairSync逐個擊破，ReentrantLock自然水到渠成。

小貼士：在ReentrantLock中，它對AbstractQueuedSynchronizer的state狀態值定義爲線程獲取該鎖的重入次數，state狀態值爲0表示當前沒有被任何線程持有，state狀態值爲1表示被其他線程持有，因爲支持可重入，如果是持有鎖的線程，再次獲取同一把鎖，直接成功，並且state狀態值+1，線程釋放鎖state狀態值-1，同理重入多次鎖的線程，需要釋放相應的次數。

Sync

Sync可以說是ReentrantLock的親兒子，它寄託了全村的希望，完美的繼承了AbstractQueuedSynchronizer，是ReentrantLock的核心，後面的NonfairSync與FairSync都是基於Sync擴展出來的子類。

聽阿星吹完了Sync，下面就來看看Sync類定義的核心部分

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

        /**
         * 獲取鎖-子類實現
         */
        abstract void lock();

        /**
         * 非公平-獲取資源
         */
        final boolean nonfairTryAcquire(int acquires) {
            //獲取當前線程
            final Thread current = Thread.currentThread();
            //獲取當前狀態
            int c = getState();
            if (c == 0) { // state==0 代表資源可獲取
                //cas設置state爲acquires，acquires傳入的是1
                if (compareAndSetState(0, acquires)) {
                    //cas成功，設置當前持有鎖的線程
                    setExclusiveOwnerThread(current);
                    //返回成功
                    return true;
                }
            }
            else if (current == getExclusiveOwnerThread()) { //如果state!=0,但是當前線程是持有鎖線程，直接重入
                //state狀態+1
                int nextc = c + acquires;
                if (nextc < 0) // overflow
                    throw new Error("Maximum lock count exceeded");
                //設置state狀態，此處不需要cas，因爲持有鎖的線程只有一個    
                setState(nextc);
                //返回成功
                return true;
            }
            //返回失敗
            return false;
        }
        
        /**
         * 釋放資源
         */
        protected final boolean tryRelease(int releases) {
            //state狀態-releases，releases傳入的是1
            int c = getState() - releases;
            if (Thread.currentThread() != getExclusiveOwnerThread()) //如果當前線程不是持有鎖線程，拋出異常
                throw new IllegalMonitorStateException();
            //設置返回狀態，默認爲失敗
            boolean free = false;
            if (c == 0) {//state-1後，如果c==0代表釋放資源成功
                //返回狀態設置爲true
                free = true;
                //清空持有鎖線程
                setExclusiveOwnerThread(null);
            }
            //如果state-1後，state還是>0，代表當前線程有鎖重入操作，需要做相應的釋放次數，設置state值
            setState(c);
            return free;
        }
}

阿星發現Sync有點偏心，首先Sync實現釋放資源的細節（A Q S留給子類實現的tryRelease），然後聲明瞭獲取鎖的抽象函數（lock），子類根據業務實現，目前看來還是很公平，但是Sync還定義了一個nonfairTryAcquire函數，這個函數是專門給NonfairSync使用的，FairSync卻沒有這種待遇，所以說Sync偏心。

Sync邏輯都比較簡單，實現了A Q S類的釋放資源（tryRelease），然後抽象了一個獲取鎖的函數讓子類自行實現（lock），再加一個偏心的函數nonfairTryAcquire，但是再怎麼簡單，圖還是要有的，這是阿星讀者們的福利。

下面放一張tryRelease流程圖，在後續的NonfairSync、FairSync都會有全面的流程。

NonfairSync

現在我們把視線轉移到NonfairSync，在ReentrantLock中支持兩種獲取鎖的策略，分別是非公平策略與公平策略，NonfairSync就是非公平策略。

此時讀者會有問道，阿星什麼是非公平策略？

在說非公平策略前，先簡單的說下A Q S（AbstractQueuedSynchronizer）流程，A Q S爲加鎖和解鎖過程提供了統一的模板函數，加鎖與解鎖的模板流程是，獲取鎖失敗的線程，會進入CLH隊列阻塞，其他線程解鎖會喚醒CLH隊列線程，如下圖所示（簡化流程）

上圖中，線程釋放鎖時，會喚醒CLH隊列阻塞的線程，重新競爭鎖，要注意，此時可能還有非CLH隊列的線程參與競爭，所以非公平就體現在這裏，非CLH隊列線程與CLH隊列線程競爭，各憑本事，不會因爲你是CLH隊列的線程，排了很久的隊，就把鎖讓給你。

瞭解了什麼是非公平策略，我們再來看看NonfairSync類定義

    static final class NonfairSync extends Sync {
        private static final long serialVersionUID = 7316153563782823691L;

        /**
         * 獲取鎖
         */
        final void lock() {
            if (compareAndSetState(0, 1))//cas設置state爲1成功，代表獲取資源成功    
                //資源獲取成功，設置當前線程爲持有鎖線程
                setExclusiveOwnerThread(Thread.currentThread());
            else
                //cas設置state爲1失敗，代表獲取資源失敗，執行AQS獲取鎖模板流程，否獲取資源成功
                acquire(1);
        }
        
        /**
         * 獲取資源-使用的是Sync提供的nonfairTryAcquire函數
         */
        protected final boolean tryAcquire(int acquires) {
            return nonfairTryAcquire(acquires);
        }
    }
    
    /**
     * AQS獲取鎖模板函數，這是AQS類中的函數
     */
    public final void acquire(int arg) {
        /**
         * 我們只需要關注tryAcquire函數，後面的函數是AQS獲取資源失敗，線程節點進入CLH隊列的細節流程，本文不關注
         */
        if (!tryAcquire(arg) &&
            acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
            selfInterrupt();
    }

NonfairSync繼承Sync實現了lock函數，lock函數也非常簡單，C A S設置狀態值state爲1代表獲取鎖成功，否則執行A Q S的acquire函數（獲取鎖模板），另外NonfairSync還實現了A Q S留給子類實現的tryAcquire函數（獲取資源），這個被Sync寵幸的幸運兒，直接使用Sync提供的nonfairTryAcquire函數來實現tryAcquire，最後子類實現的tryAcquire函數在A Q S的acquire函數中被使用。

是不是有點繞？沒事阿星帶大家一起縷一縷

首先A Q S的acquire函數是獲取鎖的流程模板，模板流程會先執行tryAcquire函數獲取資源，tryAcquire函數要子類實現，NonfairSync作爲子類，實現了tryAcquire函數，具體實現是調用了Sync的nonfairTryAcquire函數。

接下來，我們再看看Sync專門給NonfairSync準備的nonfairTryAcquire函數邏輯

    /**
     * 非公平-獲取資源
     */
    final boolean nonfairTryAcquire(int acquires) {
        //獲取當前線程
        final Thread current = Thread.currentThread();
        //獲取當前狀態
        int c = getState();
        if (c == 0) { // state==0 代表資源可獲取
            //cas設置state爲acquires，acquires傳入的是1
            if (compareAndSetState(0, acquires)) {
                //cas成功，設置當前持有鎖的線程
                setExclusiveOwnerThread(current);
                //返回成功
                return true;
            }
        }
        //如果state!=0,但是當前線程是持有鎖線程，直接重入
        else if (current == getExclusiveOwnerThread()) {
            //state狀態+1
            int nextc = c + acquires;
            if (nextc < 0) // overflow
                throw new Error("Maximum lock count exceeded");
            //設置state狀態，此處不需要cas，因爲持有鎖的線程只有一個    
            setState(nextc);
            //返回成功
            return true;
        }
        //返回失敗
        return false;
    }

阿星對上述代碼邏輯做個簡單的概括，當前線程查看資源是否可獲取：

就兩句話，是不是十分簡單，雖然簡單但阿星還是畫了一張nonfairTryAcquire流程圖給讀者們觀賞

FairSync

有非公平策略，就有公平策略，FairSync就是ReentrantLock的公平策略。

所謂公平策略就是，嚴格按照CLH隊列順序獲取鎖，線程釋放鎖時，會喚醒CLH隊列阻塞的線程，重新競爭鎖，要注意，此時可能還有非CLH隊列的線程參與競爭，爲了保證公平，一定會讓CLH隊列線程競爭成功，如果非CLH隊列線程一直佔用時間片，那就一直失敗（構建成節點插入到CLH隊尾，由A S Q模板流程執行），直到時間片輪到CLH隊列線程爲止，所以公平策略的性能會更差。

瞭解了什麼是公平策略，我們再來看看FairSync類定義

static final class FairSync extends Sync {
        private static final long serialVersionUID = -3000897897090466540L;
        
        /**
         * 獲取鎖
         */
        final void lock() {
        //cas設置state爲1失敗，代表獲取資源失敗，執行AQS獲取鎖模板流程，否獲取資源成功
            acquire(1);
        }

        /**
         * 獲取資源
         */
        protected final boolean tryAcquire(int acquires) {
            //獲取當前線程
            final Thread current = Thread.currentThread();
            //獲取state狀態
            int c = getState();
            if (c == 0) { // state==0 代表資源可獲取
                //1.hasQueuedPredecessors判斷當前線程是不是CLH隊列被喚醒的線程，如果是執行下一個步驟
               //2.cas設置state爲acquires，acquires傳入的是1
                if (!hasQueuedPredecessors() &&
                    compareAndSetState(0, acquires)) {
                    //cas成功，設置當前持有鎖的線程
                    setExclusiveOwnerThread(current);
                    //返回成功
                    return true;
                }
            }
            //如果state!=0,但是當前線程是持有鎖線程，直接重入
            else if (current == getExclusiveOwnerThread()) {
                //state狀態+1
                int nextc = c + acquires;
                if (nextc < 0)
                    throw new Error("Maximum lock count exceeded");
                //設置state狀態，此處不需要cas，因爲持有鎖的線程只有一個 
                setState(nextc);
                //返回成功
                return true;
            }
            return false;
        }
    }

    /**
     * AQS獲取鎖模板函數，這是AQS類中的函數
     */
    public final void acquire(int arg) {
        /**
         * 我們只需要關注tryAcquire函數，後面的函數是AQS獲取資源失敗，線程節點進入CLH隊列的細節流程，本文不關注
         */
        if (!tryAcquire(arg) &&
            acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
            selfInterrupt();
    }

其實我們不難發現FairSync流程與NonfairSync基本一致，唯一的區別就是在C A S執行前，多了一步hasQueuedPredecessors函數，這一步就是判斷當前線程是不是CLH隊列被喚醒的線程，如果是就執行C A S，否則獲取資源失敗，下面水一張圖

Lock 的實現

最後阿星帶大家看看ReentrantLock中是如何實現Lock的，先看構造器部分

    //同步器
    private final Sync sync;
    
    //默認使用非公平策略
    public ReentrantLock() {
        sync = new NonfairSync();
    }

    //true-公平策略 false非公平策略
    public ReentrantLock(boolean fair) {
        sync = fair ? new FairSync() : new NonfairSync();
    }

ReentrantLock默認是使用非公平策略，如果想指定模式，可以通過入參fair來選擇，這裏就不做過多概述，接下來看看ReentrantLock對Lock的實現

public class ReentrantLock implements Lock, java.io.Serializable {
    private static final long serialVersionUID = 7373984872572414699L;
    //同步器
    private final Sync sync;

    //默認使用非公平策略
    public ReentrantLock() {
        sync = new NonfairSync();
    }

    //true-公平策略 false非公平策略
    public ReentrantLock(boolean fair) {
        sync = fair ? new FairSync() : new NonfairSync();
    }

    /**
     * 獲取鎖-阻塞
     */
    public void lock() {
        //基於sync實現
        sync.lock();
    }

    /**
     * 獲取鎖-阻塞，支持響應線程中斷
     */
    public void lockInterruptibly() throws InterruptedException {
        //基於sync實現
        sync.acquireInterruptibly(1);
    }

    /**
     * 獲取資源，返回是否成功狀態-非阻塞
     */
    public boolean tryLock() {
        //基於sync實現
        return sync.nonfairTryAcquire(1);
    }

    /**
     * 獲取鎖-阻塞，支持超時 
     */
    public boolean tryLock(long timeout, TimeUnit unit)
            throws InterruptedException {
        //基於sync實現    
        return sync.tryAcquireNanos(1, unit.toNanos(timeout));
    }

    /**
     * 釋放鎖
     */
    public void unlock() {
        //基於sync實現
        sync.release(1);
    }

    /**
     * 創建條件變量
     */
    public Condition newCondition() {
        //基於sync實現
        return sync.newCondition();
    }

}

是不是特別簡單，ReentrantLock對Lock的實現都是基於Sync來做的，有一種神器在手，天下我有的風範。

Sync承包了所有事情，爲何它如此牛皮，因爲Sync上有AbstractQueuedSynchronizer老大哥罩着，下有NonfairSync與FairSync兩小弟可差遣，所以成爲ReentrantLock的利器也合情合理。

最後阿星肝一張結合A Q S的流程圖，來結束ReentrantLock。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/7c_LDi_-OqWb8iDUm_eWQg

猜你喜歡