前言

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

如果讀過阿星寫的前篇萬字長文 | 16張圖解開AbstractQueuedSynchronizer，本篇的效果拉滿，未讀過也沒關系，依然能get到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;
    }

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

可獲取，嘗試使用C A S設定state為1，C A S成功代表獲取資源成功，否則獲取資源失敗
不可獲取，判斷當執行緒是不是持有鎖的執行緒，如果是，state重入計數，獲取資源成功，否則獲取資源失敗

就兩句話，是不是十分簡單，雖然簡單但阿星還是畫了一張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();
    }

}