1. 概述
ReentrantLock是一個可重入的互斥鎖，也被稱為“獨占鎖”。在上一篇講解AQS的時候已經提到，“獨占鎖”在同一個時間點只能被一個線程持有；而可重入的意思是，ReentrantLock可以被單個線程多次獲取。
ReentrantLock又分為“公平鎖(fair lock)”和“非公平鎖(non-fair lock)”。它們的區別體現在獲取鎖的機制上：在“公平鎖”的機制下，線程依次排隊獲取鎖；而“非公平鎖”機制下，如果鎖是可獲取狀態，不管自己是不是在隊列的head節點都會去嘗試獲取鎖。
2. 數據結構和核心參數
可以看到ReetrantLock繼承自AQS，并實現了Lock接口。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提供的獲取鎖方法中，有lock()、lockInterruptibly()、tryLock()和tryLock(long time, TimeUnit unit)四種方式，他們的區別如下：
-
lock()獲取失敗后，線程進入等待隊列自旋或休眠，直到鎖可用，并且忽略中斷的影響 -
lockInterruptibly()線程進入等待隊列park后，如果線程被中斷，則直接響應中斷（拋出InterruptedException） -
tryLock()獲取鎖失敗后直接返回，不進入等待隊列 -
tryLock(long time, TimeUnit unit)獲取鎖失敗等待給定的時間后返回獲取結果
ReetrantLock通過AQS實現了自己的同步器Sync，分為公平鎖FairSync和非公平鎖NonfairSync。在構造時，通過所傳參數boolean fair來確定使用那種類型的鎖。
本篇會以對比的方式分析兩種鎖的源碼實現方式。
3. 源碼解析
3.1 lock()
lock()方法用于獲取鎖，兩種類型的鎖源碼實現如下：
//獲取鎖，一直等待鎖可用
public void lock() {
sync.lock();
}
//公平鎖獲取
final void lock() {
acquire(1);
}
//非公平鎖獲取
final void lock() {
if (compareAndSetState(0, 1))
setExclusiveOwnerThread(Thread.currentThread());
else
acquire(1);
}
說明：公平鎖的lock方法調用了AQS的acquire(1)；而非公平鎖則直接通過CAS修改state值來獲取鎖，當獲取失敗時才會調用acquire(1)來獲取鎖。
關于acquire()方法，在上篇介紹AQS的時候已經講過，印象不深的同學可以翻回去看一下，這里主要來看一下tryAcquire在ReetrantLock中的實現。
公平鎖tryAcquire：
protected final boolean tryAcquire(int acquires) {
final Thread current = Thread.currentThread();
int c = getState();//獲取鎖狀態state
if (c == 0) {
if (!hasQueuedPredecessors() && //判斷當前線程是否還有前節點
compareAndSetState(0, acquires)) {//CAS修改state
//獲取鎖成功，設置鎖的持有線程為當前線程
setExclusiveOwnerThread(current);
return true;
}
}
else if (current == getExclusiveOwnerThread()) {//當前線程已經持有鎖
int nextc = c + acquires;//重入
if (nextc < 0)
throw new Error("Maximum lock count exceeded");
setState(nextc);//更新state狀態
return true;
}
return false;
}
說明：公平鎖模式下的tryAcquire，執行流程如下：
- 如果當前鎖狀態
state為0，說明鎖處于閑置狀態可以被獲取，首先調用hasQueuedPredecessors方法判斷當前線程是否還有前節點(prev node)在等待獲取鎖。如果有，則直接返回false；如果沒有，通過調用compareAndSetState（CAS）修改state值來標記自己已經拿到鎖，CAS執行成功后調用setExclusiveOwnerThread設置鎖的持有者為當前線程。程序執行到現在說明鎖獲取成功，返回true； - 如果當前鎖狀態
state不為0，但當前線程已經持有鎖（current == getExclusiveOwnerThread()），由于鎖是可重入（多次獲取）的，則更新重入后的鎖狀態state += acquires。鎖獲取成功返回true。
非公平鎖tryAcquire
//非公平鎖獲取
protected final boolean tryAcquire(int acquires) {
return nonfairTryAcquire(acquires);
}
final boolean nonfairTryAcquire(int acquires) {
final Thread current = Thread.currentThread();
int c = getState();
if (c == 0) {
if (compareAndSetState(0, acquires)) {//CAS修改state
setExclusiveOwnerThread(current);
return true;
}
}
else if (current == getExclusiveOwnerThread()) {
int nextc = c + acquires;//計算重入后的state
if (nextc < 0) // overflow
throw new Error("Maximum lock count exceeded");
setState(nextc);
return true;
}
return false;
}
說明：通過對比公平鎖和非公平鎖tryAcquire的代碼可以看到，非公平鎖的獲取略去了!hasQueuedPredecessors()這一操作，也就是說它不會判斷當前線程是否還有前節點(prev node)在等待獲取鎖，而是直接去進行鎖獲取操作。
3.2 unlock()
//釋放鎖
public void unlock() {
sync.release(1);
}
說明：關于release()方法，在上篇介紹AQS的時候已經講過，印象不深的同學可以翻回去看一下，這里主要來看一下tryRelease在ReetrantLock中的實現：
protected final boolean tryRelease(int releases) {
int c = getState() - releases;//計算釋放后的state值
if (Thread.currentThread() != getExclusiveOwnerThread())
throw new IllegalMonitorStateException();
boolean free = false;
if (c == 0) {
free = true;//鎖全部釋放，可以喚醒下一個等待線程
setExclusiveOwnerThread(null);//設置鎖持有線程為null
}
setState(c);
return free;
}
說明：tryRelease用于釋放給定量的資源。在ReetrantLock中每次釋放量為1，也就是說，在可重入鎖中，獲取鎖的次數必須要等于釋放鎖的次數，這樣才算是真正釋放了鎖。在鎖全部釋放后（state==0）才可以喚醒下一個等待線程。
3.3 等待條件Condition
在上篇介紹AQS中提到過，在AQS中不光有等待隊列，還有一個條件隊列，這個條件隊列就是我們接下來要講的Condition。
Condition的作用是對鎖進行更精確的控制。Condition中的await()、signal()、signalAll()方法相當于Object的wait()、notify()、notifyAll()方法。不同的是，Object中的wait()、notify()、notifyAll()方法是和"同步鎖"(synchronized關鍵字)捆綁使用的；而Condition是需要與Lock捆綁使用的。
Condition函數列表
//使當前線程在被喚醒或被中斷之前一直處于等待狀態。
void await()
//使當前線程在被喚醒、被中斷或到達指定等待時間之前一直處于等待狀態。
boolean await(long time, TimeUnit unit)
//使當前線程在被喚醒、被中斷或到達指定等待時間之前一直處于等待狀態。
long awaitNanos(long nanosTimeout)
//使當前線程在被喚醒之前一直處于等待狀態。
void awaitUninterruptibly()
//使當前線程在被喚醒、被中斷或到達指定最后期限之前一直處于等待狀態。
boolean awaitUntil(Date deadline)
//喚醒一個等待線程。
void signal()
//喚醒所有等待線程。
void signalAll()
下面我們來看一下Condition在AQS中的實現
3.3.1 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)) {
//當前線程不在等待隊列，park阻塞
LockSupport.park(this);
if ((interruptMode = checkInterruptWhileWaiting(node)) != 0)
//線程被中斷，跳出循環
break;
}
if (acquireQueued(node, savedState) && interruptMode != THROW_IE)
interruptMode = REINTERRUPT;
if (node.nextWaiter != null) // clean up if cancelled
unlinkCancelledWaiters();//解除條件隊列中已經取消的等待節點的鏈接
if (interruptMode != 0)
reportInterruptAfterWait(interruptMode);//等待結束后處理中斷
}
說明： await()方法相當于Object的wait()。把當前線程添加到條件隊列中調用LockSupport.park()阻塞，直到被喚醒或中斷。函數流程如下：
- 首先判斷線程是否被中斷，如果是，直接拋出
InterruptedException，否則進入下一步； - 添加當前線程到條件隊列中，然后釋放全部資源/鎖;
- 如果當前節點不在等待隊列中，調用
LockSupport.park()阻塞當前線程，直到被unpark或被中斷。這里先簡單說一下signal方法，在線程接收到signal信號后，unpark當前線程，并把當前線程轉移到等待隊列中（sync queue）。所以，在當前方法中，如果線程被解除阻塞（unpark），也就是說當前線程被轉移到等待隊列中，就會跳出while循環，進入下一步； - 線程進入等待隊列后，調用
acquireQueued方法獲取鎖； - 調用
unlinkCancelledWaiters方法檢查條件隊列中已經取消的節點，并解除它們的鏈接（這些取消的節點在隨后的垃圾收集中被回收掉）； - 邏輯處理結束，最后處理中斷（拋出
InterruptedException或把忽略的中斷補上）。
3.3.2 signal()
//喚醒線程
public final void signal() {
if (!isHeldExclusively())
throw new IllegalMonitorStateException();
Node first = firstWaiter;
if (first != null)
doSignal(first);//喚醒條件隊列的首節點線程
}
//從條件隊列中移除給定節點，并把它轉移到等待隊列
private void doSignal(Node first) {
do {
if ( (firstWaiter = first.nextWaiter) == null)
lastWaiter = null;
first.nextWaiter = null; //解除首節點鏈接
} while (!transferForSignal(first) && //接收到signal信號后，把節點轉入等待隊列
(first = firstWaiter) != null);
}
//接收到signal信號后，把節點轉入等待隊列
final boolean transferForSignal(Node node) {
/*
* If cannot change waitStatus, the node has been cancelled.
*/
if (!compareAndSetWaitStatus(node, Node.CONDITION, 0))
//CAS修改狀態失敗，說明節點被取消，直接返回false
return false;
Node p = enq(node);//添加節點到等待隊列，并返回節點的前繼節點(prev)
int ws = p.waitStatus;
if (ws > 0 || !compareAndSetWaitStatus(p, ws, Node.SIGNAL))
//如果前節點被取消，說明當前為最后一個等待線程，unpark喚醒當前線程
LockSupport.unpark(node.thread);
return true;
}
說明：signal方法用于發送喚醒信號。在不考慮線程爭用的情況下，執行流程如下：
- 獲取條件隊列的首節點，解除首節點的鏈接（
first.nextWaiter = null;）； - 調用
transferForSignal把條件隊列的首節點轉移到等待隊列的尾部。在transferForSignal中，轉移節點后，轉移的節點沒有前繼節點，說明當前最后一個等待線程，直接調用unpark()喚醒當前線程。
Condition的其他例如awaitNanos(long nanosTimeout)、signalAll()等方法這里這里就不多贅述了，執行流程都差不多，同學們可以參考上述分析閱讀。
synchronized和ReentrantLock的選擇
ReentrantLock在加鎖和內存上提供的語義與內置鎖synchronized相同，此外它還提供了一些其他功能，包括定時的鎖等待、可中斷的鎖等待、公平性，以及實現非塊結構的加鎖。從性能方面來說，在JDK5的早期版本中，ReentrantLock的性能遠遠好于synchronized，但是從JDK6開始，JDK在synchronized上做了大量優化，使得兩者的性能差距不大。synchronized的優點就是簡潔。 所以說，兩者之間的選擇還是要看具體的需求，ReentrantLock可以作為一種高級工具，當需要一些高級功能時可以使用它。
