摘要：的主要功能和關(guān)鍵字一致，均是用于多線程的同步。而僅支持通過查詢當(dāng)前線程是否持有鎖。由于和使用的是同一把可重入鎖，所以線程可以進(jìn)入方法，并再次獲得鎖，而不會(huì)被阻塞住。公平與非公平公平與非公平指的是線程獲取鎖的方式。

可重入鎖ReentrantLock自 JDK 1.5 被引入，功能上與synchronized關(guān)鍵字類似。所謂的可重入是指，線程可對(duì)同一把鎖進(jìn)行重復(fù)加鎖，而不會(huì)被阻塞住，這樣可避免死鎖的產(chǎn)生。ReentrantLock 的主要功能和 synchronized 關(guān)鍵字一致，均是用于多線程的同步。但除此之外，ReentrantLock 在功能上比 synchronized 更為豐富。比如 ReentrantLock 在加鎖期間，可響應(yīng)中斷，可設(shè)置超時(shí)等。

ReentrantLock 是我們?nèi)粘Ｊ褂煤茴l繁的一種鎖，所以在使用之余，我們也應(yīng)該去了解一下它的內(nèi)部實(shí)現(xiàn)原理。ReentrantLock 內(nèi)部是基于 AbstractQueuedSynchronizer（以下簡(jiǎn)稱AQS）實(shí)現(xiàn)的。所以要想理解 ReentrantLock，應(yīng)先去 AQS 相關(guān)原理。我在之前的文章 AbstractQueuedSynchronizer 原理分析 - 獨(dú)占/共享模式 中，已經(jīng)詳細(xì)分析過 AQS 原理，有興趣的朋友可以去看看。本文僅會(huì)在需要的時(shí)候?qū)?AQS 相關(guān)原理進(jìn)行簡(jiǎn)要說明，更詳細(xì)的說明請(qǐng)參考我的其他文章。

本章將會(huì)簡(jiǎn)單介紹重入鎖 ReentrantLock 中的一些概念和相關(guān)原理，包括可重入、公平和非公平鎖等原理。在介紹這些原理前，首先我會(huì)介紹 ReentrantLock 與 synchronized 關(guān)鍵字的相同和不同之處。在此之后才回去介紹重入、公平和非公平等原理。

ReentrantLock 和 synchronized 都是用于線程的同步控制，但它們?cè)诠δ苌蟻碚f差別還是很大的。對(duì)比下來 ReentrantLock 功能明顯要豐富的多。下面簡(jiǎn)單列舉一下兩者之間的差異，如下：

除此之外，ReentrantLock 提供了豐富的接口用于獲取鎖的狀態(tài)，比如可以通過isLocked()查詢 ReentrantLock 對(duì)象是否處于鎖定狀態(tài), 也可以通過getHoldCount()獲取 ReentrantLock 的加鎖次數(shù)，也就是重入次數(shù)等。而 synchronized 僅支持通過Thread.holdsLock查詢當(dāng)前線程是否持有鎖。另外，synchronized 使用的是對(duì)象或類進(jìn)行加鎖，而 ReentrantLock 內(nèi)部是通過 AQS 中的同步隊(duì)列進(jìn)行加鎖，這一點(diǎn)和 synchronized 也是不一樣的。

這里列舉了不少兩者的相同和不同之處，暫時(shí)這能想到這些。如果還有其他的區(qū)別，歡迎補(bǔ)充。

可重入這個(gè)概念并不難理解，本節(jié)通過一個(gè)例子簡(jiǎn)單說明一下。

現(xiàn)在有方法 m1 和 m2，兩個(gè)方法均使用了同一把鎖對(duì)方法進(jìn)行同步控制，同時(shí)方法 m1 會(huì)調(diào)用 m2。線程 t 進(jìn)入方法 m1 成功獲得了鎖，此時(shí)線程 t 要在沒有釋放鎖的情況下，調(diào)用 m2 方法。由于 m1 和 m2 使用的是同一把可重入鎖，所以線程 t 可以進(jìn)入方法 m2，并再次獲得鎖，而不會(huì)被阻塞住。示例代碼大致如下：

void m1() {
    lock.lock();
    try {
        // 調(diào)用 m2，因?yàn)榭芍厝?，所以并不?huì)被阻塞
        m2();
    } finally {
        lock.unlock()
    }
}

void m2() {
    lock.lock();
    try {
        // do something
    } finally {
        lock.unlock()
    }
}

假如 lock 是不可重入鎖，那么上面的示例代碼必然會(huì)引起死鎖情況的發(fā)生。這里請(qǐng)大家思考一個(gè)問題，ReentrantLock 的可重入特性是怎樣實(shí)現(xiàn)的呢？簡(jiǎn)單說一下，ReentrantLock 內(nèi)部是通過 AQS 實(shí)現(xiàn)同步控制的，AQS 有一個(gè)變量 state 用于記錄同步狀態(tài)。初始情況下，state = 0，表示 ReentrantLock 目前處于解鎖狀態(tài)。如果有線程調(diào)用 lock 方法進(jìn)行加鎖，state 就由0變?yōu)?，如果該線程再次調(diào)用 lock 方法加鎖，就讓其自增，即 state++。線程每調(diào)用一次 unlock 方法釋放鎖，會(huì)讓 state--。通過查詢 state 的數(shù)值，即可知道 ReentrantLock 被重入的次數(shù)了。這就是可重復(fù)特性的大致實(shí)現(xiàn)流程。

公平與非公平指的是線程獲取鎖的方式。公平模式下，線程在同步隊(duì)列中通過 FIFO 的方式獲取鎖，每個(gè)線程最終都能獲取鎖。在非公平模式下，線程會(huì)通過“插隊(duì)”的方式去搶占鎖，搶不到的則進(jìn)入同步隊(duì)列進(jìn)行排隊(duì)。默認(rèn)情況下，ReentrantLock 使用的是非公平模式獲取鎖，而不是公平模式。不過我們也可通過 ReentrantLock 構(gòu)造方法ReentrantLock(boolean fair)調(diào)整加鎖的模式。

既然既然有兩種不同的加鎖模式，那么他們有什么優(yōu)缺點(diǎn)呢？答案如下：

公平模式下，可保證每個(gè)線程最終都能獲得鎖，但效率相對(duì)比較較低。非公平模式下，效率比較高，但可能會(huì)導(dǎo)致線程出現(xiàn)饑餓的情況。即一些線程遲遲得不到鎖，每次即將到手的鎖都有可能被其他線程搶了。這里再提個(gè)問題，為啥非公平模式搶了其他線程獲取鎖的機(jī)會(huì)，而整個(gè)程序的運(yùn)行效率會(huì)更高呢？說實(shí)話，開始我也不明白。不過好在《Java并發(fā)編程實(shí)戰(zhàn)》在第13.3節(jié) 公平性（p232）說明了具體的原因，這里引用一下：

在激烈競(jìng)爭(zhēng)的情況下，非公平鎖的性能高于公平鎖的性能的一個(gè)原因是：在恢復(fù)一個(gè)被掛起的線程與該線程真正開始運(yùn)行之間存在著嚴(yán)重的延遲。假設(shè)線程 A 持有一個(gè)鎖，并且線程 B 請(qǐng)求這個(gè)鎖。由于這個(gè)線程已經(jīng)被線程 A 持有，因此 B 將被掛起。當(dāng) A 釋放鎖時(shí)，B 將被喚醒，因此會(huì)再次嘗試獲取鎖。與此同時(shí)，如果 C 也請(qǐng)求這個(gè)鎖，那么 C 很有可能會(huì)在 B 被完全喚醒前獲得、使用以及釋放這個(gè)鎖。這樣的情況時(shí)一種“雙贏”的局面：B 獲得鎖的時(shí)刻并沒有推遲，C 更早的獲得了鎖，并且吞吐量也獲得了提高。

上面的原因大家看懂了嗎？下面配個(gè)圖輔助說明一下：

如上圖，線程 C 在線程 B 蘇醒階段內(nèi)獲取和使用鎖，并在線程 B 獲取鎖前釋放了鎖，所以線程 B 可以順利獲得鎖。線程 C 在搶占鎖的情況下，仍未影響線程 B 獲取鎖，因此是個(gè)“雙贏”的局面。

除了上面的原因外，《Java并發(fā)編程的藝術(shù)》在其5.3.2 公平與非公平鎖的區(qū)別（p137）分析了另一個(gè)可能的原因。即公平鎖線程切換次數(shù)要比非公平鎖線程切換次數(shù)多得多，因此效率上要低一些。更多的細(xì)節(jié)，可以參考作者的論述，這里不展開說明了。

本節(jié)最后說一下公平鎖和非公平鎖的使用場(chǎng)景。如果線程持鎖時(shí)間短，則應(yīng)使用非公平鎖，可通過“插隊(duì)”提升效率。如果線程持鎖時(shí)間長(zhǎng)，“插隊(duì)”帶來的效率提升可能會(huì)比較小，此時(shí)應(yīng)使用公平鎖。

前面說到 ReentrantLock 是基于 AQS 實(shí)現(xiàn)的，AQS 很好的封裝了同步隊(duì)列的管理，線程的阻塞與喚醒等基礎(chǔ)操作?；?AQS 的同步組件，推薦的使用方式是通過內(nèi)部非 public 靜態(tài)類繼承 AQS，并重寫部分抽象方法。其代碼結(jié)構(gòu)大致如下：

上圖中，Sync是一個(gè)靜態(tài)抽象類，繼承了 AbstractQueuedSynchronizer。公平和非公平鎖的實(shí)現(xiàn)類NonfairSync和FairSync則繼承自 Sync 。至于 ReentrantLock 中的其他一些方法，主要邏輯基本上都在幾個(gè)內(nèi)部類中實(shí)現(xiàn)的。

在分析 ReentrantLock 加鎖的代碼前，下來簡(jiǎn)單介紹一下 AQS 同步隊(duì)列的一些知識(shí)。AQS 維護(hù)了一個(gè)基于雙向鏈表的同步隊(duì)列，線程在獲取同步狀態(tài)失敗的情況下，都會(huì)被封裝成節(jié)點(diǎn)，然后加入隊(duì)列中。同步隊(duì)列大致示意圖如下：

在同步隊(duì)列中，頭結(jié)點(diǎn)是獲取同步狀態(tài)的節(jié)點(diǎn)。其他節(jié)點(diǎn)在嘗試獲取同步狀態(tài)失敗后，會(huì)被阻塞住，暫停運(yùn)行。當(dāng)頭結(jié)點(diǎn)釋放同步狀態(tài)后，會(huì)喚醒其后繼節(jié)點(diǎn)。后繼節(jié)點(diǎn)會(huì)將自己設(shè)為頭節(jié)點(diǎn)，并將原頭節(jié)點(diǎn)從隊(duì)列中移除。大致示意圖如下：

介紹完 AQS 同步隊(duì)列，以及節(jié)點(diǎn)線程獲取同步狀態(tài)的過程。下面來分析一下 ReentrantLock 中獲取鎖方法的源碼，如下：

public void lock() {
    sync.lock();
}

abstract static class Sync extends AbstractQueuedSynchronizer {
    // 這里的 lock 是抽象方法，具體的實(shí)現(xiàn)在兩個(gè)子類中
    abstract void lock();
    
    // 省略其他無(wú)關(guān)代碼
}

lock 方法的實(shí)現(xiàn)很簡(jiǎn)單，不過這里的 lock 方法只是一個(gè)殼子而已。由于獲取鎖的方式有公平和非公平之分，所以具體的實(shí)現(xiàn)是在NonfairSync和FairSync兩個(gè)類中。那么我們繼續(xù)往下分析一下這兩個(gè)類的實(shí)現(xiàn)。

公平鎖對(duì)應(yīng)的邏輯是 ReentrantLock 內(nèi)部靜態(tài)類 FairSync，我們沿著上面的 lock 方法往下分析，如下：

+--- ReentrantLock.FairSync.java
final void lock() {
    // 調(diào)用 AQS acquire 獲取鎖
    acquire(1);
}

+--- AbstractQueuedSynchronizer.java
/**
 * 該方法主要做了三件事情：
 * 1. 調(diào)用 tryAcquire 嘗試獲取鎖，該方法需由 AQS 的繼承類實(shí)現(xiàn)，獲取成功直接返回
 * 2. 若 tryAcquire 返回 false，則調(diào)用 addWaiter 方法，將當(dāng)前線程封裝成節(jié)點(diǎn)，
 *    并將節(jié)點(diǎn)放入同步隊(duì)列尾部
 * 3. 調(diào)用 acquireQueued 方法讓同步隊(duì)列中的節(jié)點(diǎn)循環(huán)嘗試獲取鎖
 */
public final void acquire(int arg) {
    // acquireQueued 和 addWaiter 屬于 AQS 中的方法，這里不展開分析了
    if (!tryAcquire(arg) &&
        acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
        selfInterrupt();
}

+--- ReentrantLock.FairSync.java
protected final boolean tryAcquire(int acquires) {
    final Thread current = Thread.currentThread();
    // 獲取同步狀態(tài)
    int c = getState();
    // 如果同步狀態(tài) c 為0，表示鎖暫時(shí)沒被其他線程獲取
    if (c == 0) {
        /*
         * 判斷是否有其他線程等待的時(shí)間更長(zhǎng)。如果有，應(yīng)該先讓等待時(shí)間更長(zhǎng)的節(jié)點(diǎn)先獲取鎖。
         * 如果沒有，調(diào)用 compareAndSetState 嘗試設(shè)置同步狀態(tài)。
         */ 
        if (!hasQueuedPredecessors() &&
            compareAndSetState(0, acquires)) {
            // 將當(dāng)前線程設(shè)置為持有鎖的線程
            setExclusiveOwnerThread(current);
            return true;
        }
    }
    // 如果當(dāng)前線程為持有鎖的線程，則執(zhí)行重入邏輯
    else if (current == getExclusiveOwnerThread()) {
        // 計(jì)算重入后的同步狀態(tài)，acquires 一般為1
        int nextc = c + acquires;
        // 如果重入次數(shù)超過限制，這里會(huì)拋出異常
        if (nextc < 0)
            throw new Error("Maximum lock count exceeded");
        // 設(shè)置重入后的同步狀態(tài)
        setState(nextc);
        return true;
    }
    return false;
}

+--- AbstractQueuedSynchronizer.java
/** 該方法用于判斷同步隊(duì)列中有比當(dāng)前線程等待時(shí)間更長(zhǎng)的線程 */
public final boolean hasQueuedPredecessors() {
    Node t = tail;
    Node h = head;
    Node s;
    /*
     * 在同步隊(duì)列中，頭結(jié)點(diǎn)是已經(jīng)獲取了鎖的節(jié)點(diǎn)，頭結(jié)點(diǎn)的后繼節(jié)點(diǎn)則是即將獲取鎖的節(jié)點(diǎn)。
     * 如果有節(jié)點(diǎn)對(duì)應(yīng)的線程等待的時(shí)間比當(dāng)前線程長(zhǎng)，則返回 true，否則返回 false
     */
    return h != t &&
        ((s = h.next) == null || s.thread != Thread.currentThread());
}

ReentrantLock 中獲取鎖的流程并不是很復(fù)雜，上面的代碼執(zhí)行流程如下：

調(diào)用 acquire 方法，將線程放入同步隊(duì)列中進(jìn)行等待

線程在同步隊(duì)列中成功獲取鎖，則將自己設(shè)為持鎖線程后返回

若同步狀態(tài)不為0，且當(dāng)前線程為持鎖線程，則執(zhí)行重入邏輯

分析完公平鎖相關(guān)代碼，下面再來看看非公平鎖的源碼分析，如下：

+--- ReentrantLock.NonfairSync
final void lock() {
    /*
     * 這里調(diào)用直接 CAS 設(shè)置 state 變量，如果設(shè)置成功，表明加鎖成功。這里并沒有像公平鎖
     * 那樣調(diào)用 acquire 方法讓線程進(jìn)入同步隊(duì)列進(jìn)行排隊(duì)，而是直接調(diào)用 CAS 搶占鎖。搶占失敗
     * 再調(diào)用 acquire 方法將線程置于隊(duì)列尾部排隊(duì)。
     */
    if (compareAndSetState(0, 1))
        setExclusiveOwnerThread(Thread.currentThread());
    else
        acquire(1);
}

+--- AbstractQueuedSynchronizer
/** 參考上一節(jié)的分析 */
public final void acquire(int arg) {
    if (!tryAcquire(arg) &&
        acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
        selfInterrupt();
}

+--- ReentrantLock.NonfairSync
protected final boolean tryAcquire(int acquires) {
    return nonfairTryAcquire(acquires);
}

+--- ReentrantLock.Sync
final boolean nonfairTryAcquire(int acquires) {
    final Thread current = Thread.currentThread();
    // 獲取同步狀態(tài)
    int c = getState();
    
    // 如果同步狀態(tài) c = 0，表明鎖當(dāng)前沒有線程獲得，此時(shí)可加鎖。
    if (c == 0) {
        // 調(diào)用 CAS 加鎖，如果失敗，則說明有其他線程在競(jìng)爭(zhēng)獲取鎖
        if (compareAndSetState(0, acquires)) {
            // 設(shè)置當(dāng)前線程為鎖的持有線程
            setExclusiveOwnerThread(current);
            return true;
        }
    }
    // 如果當(dāng)前線程已經(jīng)持有鎖，此處條件為 true，表明線程需再次獲取鎖，也就是重入
    else if (current == getExclusiveOwnerThread()) {
        // 計(jì)算重入后的同步狀態(tài)值，acquires 一般為1
        int nextc = c + acquires;
        if (nextc < 0) // overflow
            throw new Error("Maximum lock count exceeded");
        // 設(shè)置新的同步狀態(tài)值
        setState(nextc);
        return true;
    }
    return false;
}

非公平鎖的實(shí)現(xiàn)也不是很復(fù)雜，其加鎖的步驟大致如下：

調(diào)用 compareAndSetState 方法搶占式加鎖，加鎖成功則將自己設(shè)為持鎖線程，并返回

若加鎖失敗，則調(diào)用 acquire 方法，將線程置于同步隊(duì)列尾部進(jìn)行等待

線程在同步隊(duì)列中成功獲取鎖，則將自己設(shè)為持鎖線程后返回

若同步狀態(tài)不為0，且當(dāng)前線程為持鎖線程，則執(zhí)行重入邏輯

如果大家之前閱讀過公平鎖和非公平鎖的源碼，會(huì)發(fā)現(xiàn)兩者之間的差別不是很大。為了找出它們之間的差異，這里我將兩者的對(duì)比代碼放在一起，大家可以比較一下，如下：

從上面的源碼對(duì)比圖中，可以看出兩種的差異并不大。那么現(xiàn)在請(qǐng)大家思考一個(gè)問題：在代碼差異不大情況下，是什么差異導(dǎo)致了公平鎖和非公平鎖的產(chǎn)生呢？大家先思考一下，答案將會(huì)在下面展開說明。

在上面的源碼對(duì)比圖中，左邊是非公平鎖的實(shí)現(xiàn)，右邊是公平鎖的實(shí)現(xiàn)。從對(duì)比圖中可看出，兩者的 lock 方法有明顯區(qū)別。非公平鎖的 lock 方法會(huì)首先嘗試去搶占設(shè)置同步狀態(tài)，而不是直接調(diào)用 acquire 將線程放入同步隊(duì)列中等待獲取鎖。除此之外，tryAcquire 方法實(shí)現(xiàn)上也有差異。由于非公平鎖的 tryAcquire 邏輯主要封裝在 Sync 中的 nonfairTryAcquire 方法里，所以我們直接對(duì)比這個(gè)方法即可。由上圖可以看出，Sync 中的 nonfairTryAcquire 與公平鎖中的 tryAcquire 實(shí)現(xiàn)上差異并不大，唯一的差異在第18行，這里我用一條紅線標(biāo)注了出來。公平鎖的 tryAcquire 在第18行多出了一個(gè)條件，即!hasQueuedPredecessors()。這個(gè)方法的目的是判斷是否有其他線程比當(dāng)前線程在同步隊(duì)列中等待的時(shí)間更長(zhǎng)。有的話，返回 true，否則返回 false。比如下圖：

node1 對(duì)應(yīng)的線程比 node2 對(duì)應(yīng)的線程在隊(duì)列中等待的時(shí)間更長(zhǎng)，如果 node2 線程調(diào)用 hasQueuedPredecessors 方法，則會(huì)返回 true。如果 node1 調(diào)用此方法，則會(huì)返回 false。因?yàn)?node1 前面只有一個(gè)頭結(jié)點(diǎn)，但頭結(jié)點(diǎn)已經(jīng)獲取同步狀態(tài)，不處于等待狀態(tài)。所以在所有處于等待狀態(tài)的節(jié)點(diǎn)中，沒有節(jié)點(diǎn)比它等待的更長(zhǎng)了。理解了 hasQueuedPredecessors 方法的用途后，那么現(xiàn)在請(qǐng)大家思考個(gè)問題，假如把條件去掉對(duì)公平鎖會(huì)有什么影響呢？答案在 lock 所調(diào)用的 acquire 方法中，再來看一遍 acquire 方法源碼：

public final void acquire(int arg) {
    if (!tryAcquire(arg) &&
        acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
        selfInterrupt();
}

acquire 方法先調(diào)用子類實(shí)現(xiàn)的 tryAcquire 方法，用于嘗試獲取同步狀態(tài)，調(diào)用成功則直接返回。若調(diào)用失敗，則應(yīng)將線程插入到同步隊(duì)列尾部，按照 FIFO 原則獲取鎖。如果我們把 tryAcquire 中的條件!hasQueuedPredecessors()去掉，公平鎖將不再那么“謙讓”，它將會(huì)像非公平鎖那樣搶占獲取鎖，搶占失敗才會(huì)入隊(duì)。若如此，公平鎖將不再公平。

分析完了獲取鎖的相關(guān)邏輯，接下來再來分析一下釋放鎖的邏輯。與獲取鎖相比，釋放鎖的邏輯會(huì)簡(jiǎn)單一些，因?yàn)獒尫沛i的過程沒有公平和非公平之分。好了，下面開始分析 unlock 的邏輯：

+--- ReentrantLock
public void unlock() {
    // 調(diào)用 AQS 中的 release 方法
    sync.release(1);
}

+--- AbstractQueuedSynchronizer
public final boolean release(int arg) {
    // 調(diào)用 ReentrantLock.Sync 中的 tryRelease 嘗試釋放鎖
    if (tryRelease(arg)) {
        Node h = head;
        /*
         * 如果頭結(jié)點(diǎn)的等待狀態(tài)不為0，則應(yīng)該喚醒頭結(jié)點(diǎn)的后繼節(jié)點(diǎn)。
         * 這里簡(jiǎn)單說個(gè)結(jié)論：
         *     頭結(jié)點(diǎn)的等待狀態(tài)為0，表示頭節(jié)點(diǎn)的后繼節(jié)點(diǎn)線程還是活躍的，無(wú)需喚醒
         */
        if (h != null && h.waitStatus != 0)
            // 喚醒頭結(jié)點(diǎn)的后繼節(jié)點(diǎn)，該方法的分析請(qǐng)參考我寫的關(guān)于 AQS 的文章
            unparkSuccessor(h);
        return true;
    }
    return false;
}

+--- ReentrantLock.Sync
protected final boolean tryRelease(int releases) {
    /*
     * 用同步狀態(tài)量 state 減去釋放量 releases，得到本次釋放鎖后的同步狀態(tài)量。
     * 當(dāng)將 state 為 0，鎖才能被完全釋放
     */ 
    int c = getState() - releases;
    // 檢測(cè)當(dāng)前線程是否已經(jīng)持有鎖，僅允許持有鎖的線程執(zhí)行鎖釋放邏輯
    if (Thread.currentThread() != getExclusiveOwnerThread())
        throw new IllegalMonitorStateException();
        
    boolean free = false;
    // 如果 c 為0，則表示完全釋放鎖了，此時(shí)將持鎖線程設(shè)為 null
    if (c == 0) {
        free = true;
        setExclusiveOwnerThread(null);
    }
    
    // 設(shè)置新的同步狀態(tài)
    setState(c);
    return free;
}

重入鎖的釋放邏輯并不復(fù)雜，這里就不多說了。

本文分析了可重入鎖 ReentrantLock 公平與非公平獲取鎖以及釋放鎖原理，并與 synchronized 關(guān)鍵字進(jìn)行了類比?？傮w來說，ReentrantLock 的原理在熟悉 AQS 原理的情況下，理解并不是很復(fù)雜。ReentrantLock 是大家經(jīng)常使用的一個(gè)同步組件，還是很有必要去弄懂它的原理的。

好了，本文到這里就結(jié)束了。謝謝大家的閱讀，再見。

《Java并發(fā)編程實(shí)戰(zhàn)》- Brian Goetz / Tim Peierls / Joshua Bloch / Joseph Bowbeer / David Holmes / Doug Lea

《Java并發(fā)編程的藝術(shù)》- 方騰飛 / 魏鵬 / 程曉明

本文在知識(shí)共享許可協(xié)議 4.0 下發(fā)布，轉(zhuǎn)載需在明顯位置處注明出處
作者：coolblog
本文同步發(fā)布在我的個(gè)人博客：http://www.coolblog.xyz

本作品采用知識(shí)共享署名-非商業(yè)性使用-禁止演繹 4.0 國(guó)際許可協(xié)議進(jìn)行許可。