一、ReentrantLock 類

1.1 什麼是reentrantlock

1.2 ReentrantLock與synchronized的比較

相同：ReentrantLock提供了synchronized類似的功能和記憶體語義。

不同：

（1）ReentrantLock功能性方面更全面，比如時間鎖等候，可中斷鎖等候，鎖投票等，因此更有擴充套件性。在多個條件變數和高度競爭鎖的地方，用ReentrantLock更合適，ReentrantLock還提供了Condition，對執行緒的等待和喚醒等操作更加靈活，一個ReentrantLock可以有多個Condition例項，所以更有擴充套件性。

（2）ReentrantLock 的效能比synchronized會好點。

（3）ReentrantLock提供了可輪詢的鎖請求，他可以嘗試的去取得鎖，如果取得成功則繼續處理，取得不成功，可以等下次執行的時候處理，所以不容易產生死鎖，而synchronized則一旦進入鎖請求要麼成功，要麼一直阻塞，所以更容易產生死鎖。

1.3 ReentrantLock擴充套件的功能

1.3.1 實現可輪詢的鎖請求 

Lock lock = ...; 
if (lock.tryLock()) { 
try { 
// manipulate protected state 
} finally { 
lock.unlock(); 
} 
} else { 
// perform alternative actions 
} 

1.3.2 實現可定時的鎖請求 

1.3.3 實現可中斷的鎖獲取請求 

1.4 ReentrantLock不好與需要注意的地方

二、條件變數Condition

條件變數很大一個程度上是為了解決Object.wait/notify/notifyAll難以使用的問題。

條件（也稱為條件佇列 或條件變數）為執行緒提供了一個含義，以便在某個狀態條件現在可能為 true 的另一個執行緒通知它之前，一直掛起該執行緒（即讓其“等待”）。因為訪問此共享狀態資訊發生在不同的執行緒中，所以它必須受保護，因此要將某種形式的鎖與該條件相關聯。等待提供一個條件的主要屬性是：以原子方式 釋放相關的鎖，並掛起當前執行緒，就像 Object.wait 做的那樣。

上述API說明表明條件變數需要與鎖繫結，而且多個Condition需要繫結到同一鎖上。前面的Lock中提到，獲取一個條件變數的方法是Lock.newCondition()。

void await() throws InterruptedException;

void awaitUninterruptibly();

long awaitNanos(long nanosTimeout) throws InterruptedException;

boolean await(long time, TimeUnit unit) throws InterruptedException;

boolean awaitUntil(Date deadline) throws InterruptedException;

void signal();

void signalAll();

以上是Condition介面定義的方法，await*對應於Object.wait，signal對應於Object.notify，signalAll對應於Object.notifyAll。特別說明的是Condition的介面改變名稱就是為了避免與Object中的wait/notify/notifyAll的語義和使用上混淆，因為Condition同樣有wait/notify/notifyAll方法。

每一個Lock可以有任意資料的Condition物件，Condition是與Lock繫結的，所以就有Lock的公平性特性：如果是公平鎖，執行緒為按照FIFO的順序從Condition.await中釋放，如果是非公平鎖，那麼後續的鎖競爭就不保證FIFO順序了。

一個使用Condition實現生產者消費者的模型例子如下。

import java.util.concurrent.locks.Condition;
import java.util.concurrent.locks.Lock;
import java.util.concurrent.locks.ReentrantLock;

public class ProductQueue<T> {

    private final T[] items;

    private final Lock lock = new ReentrantLock();

    private Condition notFull = lock.newCondition();

    private Condition notEmpty = lock.newCondition();

    //
    private int head, tail, count;

    public ProductQueue(int maxSize) {
        items = (T[]) new Object[maxSize];
    }

    public ProductQueue() {
        this(10);
    }

    public void put(T t) throws InterruptedException {
        lock.lock();
        try {
            while (count == getCapacity()) {
                notFull.await();
            }
            items[tail] = t;
            if (++tail == getCapacity()) {
                tail = 0;
            }
            ++count;
            notEmpty.signalAll();
        } finally {
            lock.unlock();
        }
    }

    public T take() throws InterruptedException {
        lock.lock();
        try {
            while (count == 0) {
                notEmpty.await();
            }
            T ret = items[head];
            items[head] = null;//GC
            //
            if (++head == getCapacity()) {
                head = 0;
            }
            --count;
            notFull.signalAll();
            return ret;
        } finally {
            lock.unlock();
        }
    }

    public int getCapacity() {
        return items.length;
    }

    public int size() {
        lock.lock();
        try {
            return count;
        } finally {
            lock.unlock();
        }
    }

}

在這個例子中消費take()需要 佇列不為空，如果為空就掛起（await()），直到收到notEmpty的訊號；生產put()需要佇列不滿，如果滿了就掛起（await()），直到收到notFull的訊號。

可能有人會問題，如果一個執行緒lock()物件後被掛起還沒有unlock，那麼另外一個執行緒就拿不到鎖了（lock()操作會掛起），那麼就無法通知(notify)前一個執行緒，這樣豈不是“死鎖”了？

2.1 await* 操作

上一節中說過多次ReentrantLock是獨佔鎖，一個執行緒拿到鎖後如果不釋放，那麼另外一個執行緒肯定是拿不到鎖，所以在lock.lock()和lock.unlock()之間可能有一次釋放鎖的操作（同樣也必然還有一次獲取鎖的操作）。我們再回頭看程式碼，不管take()還是put()，在進入lock.lock()後唯一可能釋放鎖的操作就是await()了。也就是說await()操作實際上就是釋放鎖，然後掛起執行緒，一旦條件滿足就被喚醒，再次獲取鎖！

public final void await() throws InterruptedException {
    if (Thread.interrupted())
        throw new InterruptedException();
    Node node = addConditionWaiter();
    int savedState = fullyRelease(node);
    int interruptMode = 0;
    while (!isOnSyncQueue(node)) {
        LockSupport.park(this);
        if ((interruptMode = checkInterruptWhileWaiting(node)) != 0)
            break;
    }
    if (acquireQueued(node, savedState) && interruptMode != THROW_IE)
        interruptMode = REINTERRUPT;
    if (node.nextWaiter != null)
        unlinkCancelledWaiters();
    if (interruptMode != 0)
        reportInterruptAfterWait(interruptMode);
}

上面是await()的程式碼片段。上一節中說過,AQS在獲取鎖的時候需要有一個CHL的FIFO佇列，所以對於一個Condition.await()而言，如果釋放了鎖，要想再一次獲取鎖那麼就需要進入佇列，等待被通知獲取鎖。完整的await()操作是安裝如下步驟進行的：

1. 1. 將當前執行緒加入Condition鎖佇列。特別說明的是，這裡不同於AQS的佇列，這裡進入的是Condition的FIFO佇列。後面會具體談到此結構。進行2。
   2. 釋放鎖。這裡可以看到將鎖釋放了，否則別的執行緒就無法拿到鎖而發生死鎖。進行3。
   3. 自旋(while)掛起，直到被喚醒或者超時或者CACELLED等。進行4。
   4. 獲取鎖(acquireQueued)。並將自己從Condition的FIFO佇列中釋放，表明自己不再需要鎖（我已經拿到鎖了）。

這裡再回頭介紹Condition的資料結構。我們知道一個Condition可以在多個地方被await*()，那麼就需要一個FIFO的結構將這些Condition串聯起來，然後根據需要喚醒一個或者多個（通常是所有）。所以在Condition內部就需要一個FIFO的佇列。

private transient Node firstWaiter;
private transient Node lastWaiter;

上面的兩個節點就是描述一個FIFO的佇列。我們再結合前面提到的節點（Node）資料結構。我們就發現Node.nextWaiter就派上用場了！nextWaiter就是將一系列的Condition.await*串聯起來組成一個FIFO的佇列。

2.2 signal/signalAll 操作

await*()清楚了，現在再來看signal/signalAll就容易多了。按照signal/signalAll的需求，就是要將Condition.await*()中FIFO佇列中第一個Node喚醒（或者全部Node）喚醒。儘管所有Node可能都被喚醒，但是要知道的是仍然只有一個執行緒能夠拿到鎖，其它沒有拿到鎖的執行緒仍然需要自旋等待，就上上面提到的第4步(acquireQueued)。

private void doSignal(Node first) {
    do {
        if ( (firstWaiter = first.nextWaiter) == null)
            lastWaiter = null;
        first.nextWaiter = null;
    } while (!transferForSignal(first) &&
             (first = firstWaiter) != null);
}

private void doSignalAll(Node first) {
    lastWaiter = firstWaiter  = null;
    do {
        Node next = first.nextWaiter;
        first.nextWaiter = null;
        transferForSignal(first);
        first = next;
    } while (first != null);
}

上面的程式碼很容易看出來，signal就是喚醒Condition佇列中的第一個非CANCELLED節點執行緒，而signalAll就是喚醒所有非CANCELLED節點執行緒。當然了遇到CANCELLED執行緒就需要將其從FIFO佇列中剔除。

final boolean transferForSignal(Node node) {
    if (!compareAndSetWaitStatus(node, Node.CONDITION, 0))
        return false;

    Node p = enq(node);
    int c = p.waitStatus;
    if (c > 0 || !compareAndSetWaitStatus(p, c, Node.SIGNAL))
        LockSupport.unpark(node.thread);
    return true;
}

上面就是喚醒一個await*()執行緒的過程，根據前面的小節介紹的，如果要unpark執行緒，並使執行緒拿到鎖，那麼就需要執行緒節點進入AQS的佇列。所以可以看到在LockSupport.unpark之前呼叫了enq(node)操作，將當前節點加入到AQS佇列。

參考：