學(xué)習(xí)AQS的時(shí)候，了解到AQS依賴于內(nèi)部的FIFO同步隊(duì)列來(lái)完成同步狀態(tài)的管理，當(dāng)前線程獲取同步狀態(tài)失敗時(shí)，同步器會(huì)將當(dāng)前線程以及等待狀態(tài)等信息構(gòu)造成一個(gè)Node對(duì)象并將其加入到同步隊(duì)列，同時(shí)會(huì)阻塞當(dāng)前線程，當(dāng)同步狀態(tài)釋放時(shí)，會(huì)把首節(jié)點(diǎn)中的線程喚醒，使其再次嘗試獲取同步狀態(tài)。

這時(shí)，我有了一個(gè)疑問(wèn)，AQS的同步隊(duì)列是FIFO的，就是先來(lái)排隊(duì)的先走。那怎么實(shí)現(xiàn)非公平鎖呢？查閱了一些資料，總算知道了。

首先從公平鎖開(kāi)始看起。

ReentrantLock 的公平鎖

ReentrantLock 默認(rèn)采用非公平鎖，除非在構(gòu)造方法中傳入?yún)?shù) true 。

//默認(rèn)
public ReentrantLock() {
    sync = new NonfairSync();
}
//傳入true or false
public ReentrantLock(boolean fair) {
    sync = fair ? new FairSync() : new NonfairSync();
}

公平鎖的 lock 方法：

static final class FairSync extends Sync {
    final void lock() {
        acquire(1);
    }
    // AbstractQueuedSynchronizer.acquire(int arg)
    public final void acquire(int arg) {
        if (!tryAcquire(arg) &&
            acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
            selfInterrupt();
    }
    protected final boolean tryAcquire(int acquires) {
        final Thread current = Thread.currentThread();
        int c = getState();
        if (c == 0) {
            // 1. 和非公平鎖相比，這里多了一個(gè)判斷：是否有線程在等待
            if (!hasQueuedPredecessors() &&
                compareAndSetState(0, acquires)) {
                setExclusiveOwnerThread(current);
                return true;
            }
        }
        else if (current == getExclusiveOwnerThread()) {
            int nextc = c + acquires;
            if (nextc < 0)
                throw new Error("Maximum lock count exceeded");
            setState(nextc);
            return true;
        }
        return false;
    }
}

我們可以看到，在注釋1的位置，有個(gè)!hasQueuedPredecessors()條件，意思是說(shuō)當(dāng)前同步隊(duì)列沒(méi)有前驅(qū)節(jié)點(diǎn)（也就是沒(méi)有線程在等待）時(shí)才會(huì)去compareAndSetState(0, acquires)使用CAS修改同步狀態(tài)變量。所以就實(shí)現(xiàn)了公平鎖，根據(jù)線程發(fā)出請(qǐng)求的順序獲取鎖。

非公平鎖的lock方法

static final class NonfairSync extends Sync {
    final void lock() {
        // 2. 和公平鎖相比，這里會(huì)直接先進(jìn)行一次CAS，成功就返回了
        if (compareAndSetState(0, 1))
            setExclusiveOwnerThread(Thread.currentThread());
        else
            acquire(1);
    }
    // AbstractQueuedSynchronizer.acquire(int arg)
    public final void acquire(int arg) {
        if (!tryAcquire(arg) &&
            acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
            selfInterrupt();
    }
    protected final boolean tryAcquire(int acquires) {
        return nonfairTryAcquire(acquires);
    }
}
/**
 * Performs non-fair tryLock.  tryAcquire is implemented in
 * subclasses, but both need nonfair try for trylock method.
 */
final boolean nonfairTryAcquire(int acquires) {
    final Thread current = Thread.currentThread();
    int c = getState();
    if (c == 0) {
        //3.這里也是直接CAS，沒(méi)有判斷前面是否還有節(jié)點(diǎn)。
        if (compareAndSetState(0, acquires)) {
            setExclusiveOwnerThread(current);
            return true;
        }
    }
    else if (current == getExclusiveOwnerThread()) {
        int nextc = c + acquires;
        if (nextc < 0) // overflow
            throw new Error("Maximum lock count exceeded");
        setState(nextc);
        return true;
    }
    return false;
}

非公平鎖的實(shí)現(xiàn)在剛進(jìn)入lock方法時(shí)會(huì)直接使用一次CAS去嘗試獲取鎖，不成功才會(huì)到acquire方法中，如注釋2。而在nonfairTryAcquire方法中并沒(méi)有判斷是否有前驅(qū)節(jié)點(diǎn)在等待，直接CAS嘗試獲取鎖，如注釋3。由此實(shí)現(xiàn)了非公平鎖。

總結(jié)

非公平鎖和公平鎖的兩處不同：

1. 非公平鎖在調(diào)用 lock 后，首先就會(huì)調(diào)用 CAS 進(jìn)行一次搶鎖，如果這個(gè)時(shí)候恰巧鎖沒(méi)有被占用，那么直接就獲取到鎖返回了。

2. 非公平鎖在 CAS 失敗后，和公平鎖一樣都會(huì)進(jìn)入到 tryAcquire 方法，在 tryAcquire 方法中，如果發(fā)現(xiàn)鎖這個(gè)時(shí)候被釋放了（state == 0），非公平鎖會(huì)直接 CAS 搶鎖，但是公平鎖會(huì)判斷等待隊(duì)列是否有線程處于等待狀態(tài)，如果有則不去搶鎖，乖乖排到后面。

公平鎖和非公平鎖就這兩點(diǎn)區(qū)別，如果這兩次 CAS 都不成功，那么后面非公平鎖和公平鎖是一樣的，都要進(jìn)入到阻塞隊(duì)列等待喚醒。

相對(duì)來(lái)說(shuō)，非公平鎖會(huì)有更好的性能，因?yàn)樗耐掏铝勘容^大。當(dāng)然，非公平鎖讓獲取鎖的時(shí)間變得更加不確定，可能會(huì)導(dǎo)致在阻塞隊(duì)列中的線程長(zhǎng)期處于饑餓狀態(tài)。