作者： 一字馬胡
轉(zhuǎn)載標(biāo)志 【2017-11-03】
更新日志
| 日期 | 更新內(nèi)容 | 備注 |
|---|---|---|
| 2017-11-03 | 添加轉(zhuǎn)載標(biāo)志 | 持續(xù)更新 |
前言
在java中涛浙，鎖是實(shí)現(xiàn)并發(fā)的關(guān)鍵組件割笙，多個(gè)線程之間的同步關(guān)系需要鎖來(lái)保證，所謂鎖，其語(yǔ)義就是資源獲取到資源釋放的一系列過(guò)程需纳，使用lock的意圖就是想要進(jìn)入臨界區(qū)對(duì)共享資源執(zhí)行操作，使用unlock說(shuō)明線程已經(jīng)完成了相關(guān)工作或者發(fā)生了異常從而離開(kāi)臨界區(qū)釋放共享資源艺挪，可以說(shuō)不翩，在多線程環(huán)境下，鎖是一個(gè)必不可少的組件闺属。我們最為常用的并發(fā)鎖是synchronized關(guān)鍵字慌盯，在最新的jdk中，synchronized的性能已經(jīng)有了極大的提升了掂器，而且未來(lái)還會(huì)對(duì)它做更進(jìn)一步的優(yōu)化亚皂，最為重要的是synchronized使用起來(lái)特別方便，基本不需要要我們考慮太多的內(nèi)容国瓮，只需要將臨界區(qū)的代碼放在synchronized關(guān)鍵字里面灭必，然后設(shè)定好需要鎖定的對(duì)象，synchronized就會(huì)自動(dòng)為進(jìn)入的并發(fā)線程lock和unlock乃摹。在大多數(shù)情況下禁漓，我們寫并發(fā)代碼使用synchronized就足夠了，而且使用synchronized也是首選孵睬，不過(guò)如果我們希望更加靈活的使用鎖來(lái)做并發(fā)播歼，那么java還提供了一個(gè)借口Lock，本文并不會(huì)對(duì)synchronized進(jìn)行分析總結(jié)掰读，本文的重點(diǎn)在Lock接口秘狞，以及實(shí)現(xiàn)了Lock接口的一些子類的分析總結(jié)。
為了本文的完整性蹈集，可以參考Java同步框架AbstractQueuedSynchronizer烁试，這個(gè)俗稱為AQS的東西是Lock接口實(shí)現(xiàn)的根本，它實(shí)現(xiàn)了Lock的全部語(yǔ)義拢肆，可以說(shuō)减响，java的Lock接口的子類就是借助AQS來(lái)實(shí)現(xiàn)了lock和unlock的靖诗，理解了AQS，就可以很好的理解java中的鎖了支示。
Lock接口以及ReadWriteLock接口
下面首先展示出了Lock接口的內(nèi)容刊橘，然后是ReadWriteLock的接口，本文主要分析這兩個(gè)接口的幾個(gè)子類的實(shí)現(xiàn)細(xì)節(jié)颂鸿。
public interface ReadWriteLock {
/**
* Returns the lock used for reading.
*
* @return the lock used for reading
*/
Lock readLock();
/**
* Returns the lock used for writing.
*
* @return the lock used for writing
*/
Lock writeLock();
}
Lock接口提供了lock和unlock方法伤为，提供加鎖和釋放鎖的語(yǔ)義，lockInterruptibly方法可以響應(yīng)中斷据途，lock方法會(huì)阻塞線程直到獲取到鎖，而tryLock方法則會(huì)立刻返回叙甸，返回true代表獲取鎖成功颖医，而返回false則說(shuō)明獲取不到鎖。newCondition方法返回一個(gè)條件變量裆蒸，一個(gè)條件變量也可以做線程間通信來(lái)同步線程熔萧。多個(gè)線程可以等待在同一個(gè)條件變量上，一些線程會(huì)在某些情況下通知等待在條件變量上的線程僚祷，而有些變量在某些情況下會(huì)加入到條件變量上的等待隊(duì)列中去佛致。
ReadWriteLock是讀寫鎖，可以對(duì)共享變量的讀寫提供并發(fā)支持辙谜，ReadWriteLock接口的兩個(gè)方法分別返回一個(gè)讀鎖和一個(gè)寫鎖俺榆。本文將基于上面提到的兩個(gè)接口Lock和ReadWriteLock，對(duì)Lock的子類ReentrantLock和ReadWriteLock的子類ReentrantReadWriteLock進(jìn)行一些分析總結(jié)装哆，以備未來(lái)不時(shí)之需罐脊。
ReentrantLock
在Java同步框架AbstractQueuedSynchronizer提到了兩個(gè)概念，一個(gè)是獨(dú)占鎖蜕琴，一個(gè)是共享鎖萍桌，所謂獨(dú)占鎖就是只能有一個(gè)線程獲取到鎖，其他線程必須在這個(gè)鎖釋放了鎖之后才能競(jìng)爭(zhēng)而獲得鎖凌简。而共享鎖則可以允許多個(gè)線程獲取到鎖上炎。具體的分析不再本文的分析范圍之內(nèi)。
ReentrantLock翻譯過(guò)來(lái)為可重入鎖雏搂，它的可重入性表現(xiàn)在同一個(gè)線程可以多次獲得鎖藕施，而不同線程依然不可多次獲得鎖，這在下文中會(huì)進(jìn)行分析畔派。下文會(huì)分析它是如何借助AQS來(lái)實(shí)現(xiàn)lock和unlock的铅碍，本文只關(guān)注核心方法，比如lock和unlock线椰，而不會(huì)去詳細(xì)的描述所有的方法胞谈。ReentrantLock分為公平鎖和非公平鎖，公平鎖保證等待時(shí)間最長(zhǎng)的線程將優(yōu)先獲得鎖，而非公平鎖并不會(huì)保證多個(gè)線程獲得鎖的順序烦绳，但是非公平鎖的并發(fā)性能表現(xiàn)更好卿捎，ReentrantLock默認(rèn)使用非公平鎖。下面分公平鎖和非公平鎖來(lái)分析一下ReentrantLock的代碼径密。
鎖Sync
在文章Java同步框架AbstractQueuedSynchronizer中已經(jīng)提到了如何通過(guò)AQS來(lái)實(shí)現(xiàn)鎖的方法午阵，那就是繼承AbstractQueuedSynchronizer類，然后使用它提供的方法來(lái)實(shí)現(xiàn)自己的鎖享扔。ReentrantLock的Sync也是通過(guò)這個(gè)方法來(lái)實(shí)現(xiàn)鎖的底桂。
Sync有一個(gè)抽象方法lock，其子類FairSync和NonfairSync分別實(shí)現(xiàn)了公平上鎖和非公平上鎖惧眠。nonfairTryAcquire方法用于提供可重入的非公平上鎖籽懦，之所以把它放在Sync中而不是在子類NonfairSync中（FairSync中有公平的可重入上鎖版本的實(shí)現(xiàn)），是因?yàn)閚onfairTryAcquire不僅在NonfairSync中被使用了氛魁，而且在ReentrantLock.tryLock里面也使用到了暮顺。對(duì)于它的分析留到NonfairSync里面再分析。
Sync中還需要注意的一個(gè)方法是tryRelease秀存，執(zhí)行這個(gè)方法說(shuō)明線程在離開(kāi)臨界區(qū)捶码，下面是tryRelease方法的代碼：
protected final boolean tryRelease(int releases) {
int c = getState() - releases;
if (Thread.currentThread() != getExclusiveOwnerThread())
throw new IllegalMonitorStateException();
boolean free = false;
if (c == 0) {
free = true;
setExclusiveOwnerThread(null);
}
setState(c);
return free;
}
tryRelease方法重寫了父類的tryRelease方法，而父類的tryRelease方法在release方法中被調(diào)用或链，而release方法最后會(huì)被用于實(shí)現(xiàn)ReentrantLock的unlock方法惫恼。所以理解了該方法，就理解了ReentrantLock的unlock邏輯澳盐。
從上面展示的代碼分析尤筐，getState方法獲取當(dāng)前的共享變量，getState方法的返回值代表了有多少線程獲取了該條件變量洞就，而release代表著想要釋放的次數(shù)盆繁，然后根據(jù)這兩個(gè)值計(jì)算出最新的state值，接著判斷當(dāng)前線程是否獨(dú)占了鎖旬蟋，如果不是油昂，那么就拋出異常，否則繼續(xù)接下來(lái)的流程倾贰。如果最新的state為0了冕碟，說(shuō)明鎖已經(jīng)被釋放了，可以被其他線程獲取了匆浙。然后更新state值安寺。
公平鎖FairSync
FairSync實(shí)現(xiàn)了公平鎖的lock和tryAcquire方法，下面分別看一下這兩個(gè)方法的實(shí)現(xiàn)細(xì)節(jié)：
final void lock() {
acquire(1);
}
可以看到首尼，F(xiàn)airSync的lock實(shí)現(xiàn)使用了AQS提供的acquire方法挑庶，這個(gè)方法的詳細(xì)解析見(jiàn)Java同步框架AbstractQueuedSynchronizer言秸。
下面是tryAcquire方法的細(xì)節(jié)：
protected final boolean tryAcquire(int acquires) {
final Thread current = Thread.currentThread();
int c = getState();
if (c == 0) {
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;
}
}
可以看到，公平鎖的tryAcquire實(shí)現(xiàn)和非公平鎖的tryAcquire實(shí)現(xiàn)的區(qū)別在于：公平鎖多加了一個(gè)判斷條件：hasQueuedPredecessors迎捺，如果發(fā)現(xiàn)有線程在等待獲取鎖了举畸，那么就直接返回false，否則在繼承嘗試獲取鎖凳枝，這樣就保證了線程是按照排隊(duì)時(shí)間來(lái)有限獲取鎖的抄沮。而非公平鎖的實(shí)現(xiàn)則不考慮是否有節(jié)點(diǎn)在排隊(duì)，會(huì)直接去競(jìng)爭(zhēng)鎖岖瑰，如果獲取成功就返回true叛买，否則返回false。
當(dāng)然蹋订，這些分支執(zhí)行的條件是state為0聪全，也就是說(shuō)當(dāng)前沒(méi)有線程獨(dú)占著鎖，或者獲取鎖的線程就是當(dāng)前獨(dú)占著鎖的線程辅辩，如果是前者，就按照上面分析的流程進(jìn)行獲取鎖娃圆，如果是后者玫锋，則更新state的值，如果不是上述的兩種情況讼呢，那么直接返回false說(shuō)明嘗試獲取鎖失敗撩鹿。
非公平鎖NonfairSync
公平鎖的lock使用了AQS的acquire，而acquire會(huì)將參與鎖競(jìng)爭(zhēng)的線程加入到等待隊(duì)列中去按順序獲得鎖悦屏，隊(duì)列頭部的節(jié)點(diǎn)代表著當(dāng)前獲得鎖的節(jié)點(diǎn)节沦，頭結(jié)點(diǎn)釋放鎖之后會(huì)喚醒其后繼節(jié)點(diǎn)，然后讓后繼節(jié)點(diǎn)來(lái)競(jìng)爭(zhēng)獲取鎖础爬，這樣就可以保證鎖的獲取是按照一定的優(yōu)先級(jí)來(lái)的甫贯。而非公平鎖的實(shí)現(xiàn)則會(huì)首先嘗試去競(jìng)爭(zhēng)鎖，如果不成功看蚜，再走AQS提供的acquire方法叫搁，下面是NonfairSync的lock方法：
final void lock() {
if (compareAndSetState(0, 1))
setExclusiveOwnerThread(Thread.currentThread());
else
acquire(1);
}
非公平鎖的tryAcquire方法使用了父類的nonfairTryAcquire方法來(lái)實(shí)現(xiàn)。
ReentrantLock上鎖和釋放鎖
說(shuō)完了Sync類和其兩個(gè)子類供炎，現(xiàn)在來(lái)看一下ReentrantLock是如何使用這兩個(gè)類來(lái)實(shí)現(xiàn)lock和unlock的渴逻。首先是ReentrantLock的構(gòu)造方法：
/**
* Creates an instance of {@code ReentrantLock}.
* This is equivalent to using {@code ReentrantLock(false)}.
*/
public ReentrantLock() {
sync = new NonfairSync();
}
/**
* Creates an instance of {@code ReentrantLock} with the
* given fairness policy.
*
* @param fair {@code true} if this lock should use a fair ordering policy
*/
public ReentrantLock(boolean fair) {
sync = fair ? new FairSync() : new NonfairSync();
}
默認(rèn)構(gòu)造函數(shù)使用了非公平鎖來(lái)提高并發(fā)度，一般情況下使用默認(rèn)構(gòu)造函數(shù)即可音诫。而在一些特殊的情景下惨奕，需要使用公平鎖的話就傳遞一個(gè)true的參數(shù)。下面是lock和unlock方法的細(xì)節(jié)竭钝，lock使用了Sync的lock方法梨撞，而unlock使用了AQS的release方法雹洗，而release方法使用了其tryRelease方法，而這個(gè)方法在Sync類中被重寫聋袋，上面我們已經(jīng)有過(guò)分析队伟。
public void lock() {
sync.lock();
}
public void unlock() {
sync.release(1);
}
newCondition方法
newCondition這個(gè)方法需要一些篇幅來(lái)描述一下，而newCondition方法的返回內(nèi)容涉及AQS類中的內(nèi)部類ConditionObject幽勒，所以也就是分析一下ConditionObject這個(gè)類的一些細(xì)節(jié)嗜侮。下面的圖片展示了ConditionObject這個(gè)類的類圖，可以看出啥容，它實(shí)現(xiàn)了Condition的所有方法锈颗。
關(guān)于Condition接口的描述，可以參考下面的文檔內(nèi)容：
* Conditions (also known as condition queues or
* condition variables) provide a means for one thread to
* suspend execution (to wait) until notified by another
* thread that some state condition may now be true. Because access
* to this shared state information occurs in different threads, it
* must be protected, so a lock of some form is associated with the
* condition. The key property that waiting for a condition provides
* is that it atomically releases the associated lock and
* suspends the current thread, just like {@code Object.wait}.
await和await(long time, TimeUnit unit)方法
接下來(lái)分析一下ConditionObject類是如何實(shí)現(xiàn)Condition接口的方法的咪惠。首先是await方法击吱，這個(gè)方法的意思是讓當(dāng)前線程等待直到有別的線程signalled，或者被interrupted遥昧。調(diào)用此方法的線程會(huì)被阻塞直到有其他的線程喚醒或者打斷它覆醇。下面是它的實(shí)現(xiàn)。
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) // clean up if cancelled
unlinkCancelledWaiters();
if (interruptMode != 0)
reportInterruptAfterWait(interruptMode);
}
首先炭臭，如果線程被中斷了永脓，那么拋出異常。否則調(diào)用addConditionWaiter方法生成一個(gè)Node鞋仍，下面來(lái)看一下addConditionWaiter這個(gè)方法的細(xì)節(jié)：
private Node addConditionWaiter() {
Node t = lastWaiter;
// If lastWaiter is cancelled, clean out.
if (t != null && t.waitStatus != Node.CONDITION) {
unlinkCancelledWaiters();
t = lastWaiter;
}
Node node = new Node(Thread.currentThread(), Node.CONDITION);
if (t == null)
firstWaiter = node;
else
t.nextWaiter = node;
lastWaiter = node;
return node;
}
lastWaiter是等待在該Condition上的隊(duì)列末尾的線程常摧，根據(jù)代碼，首先威创，如果最后一個(gè)線程從Condition上被取消了落午，并且當(dāng)前線程并沒(méi)有在該Condition的等待隊(duì)列上，那么就將當(dāng)前線程作為該Condition上等待隊(duì)列的末尾節(jié)點(diǎn)肚豺。如果上面的條件不成立溃斋，那么就使用當(dāng)前線程生成一個(gè)新的Node，然后將其狀態(tài)變?yōu)镹ode.CONDITION代表其等待在某個(gè)Condition上吸申，然后將該新的節(jié)點(diǎn)添加到隊(duì)列的末尾盐类。
現(xiàn)在回頭看await方法，我們發(fā)現(xiàn)addConditionWaiter的作用就是將當(dāng)前線程添加到Condition的等待隊(duì)列上去呛谜。接下來(lái)的步驟特別關(guān)鍵在跳。await方法調(diào)用了fullyRelease方法，我們來(lái)看一下這個(gè)方法是干嘛用的：
final int fullyRelease(Node node) {
boolean failed = true;
try {
int savedState = getState();
if (release(savedState)) {
failed = false;
return savedState;
} else {
throw new IllegalMonitorStateException();
}
} finally {
if (failed)
node.waitStatus = Node.CANCELLED;
}
}
fullyRelease會(huì)調(diào)用release方法來(lái)是釋放當(dāng)前線程的同步狀態(tài)隐岛，并且返回釋放之后的狀態(tài)值猫妙，這個(gè)值在await方法中作為了acquireQueued方法參數(shù)，這個(gè)方法在稍后分析【郯迹現(xiàn)在來(lái)看一下接下來(lái)的步驟割坠，在獲得了當(dāng)前線程的state值了之后齐帚，就會(huì)進(jìn)入一個(gè)while循環(huán)中去，while循環(huán)停止的條件是isOnSyncQueue(node)這個(gè)方法返回true彼哼，這個(gè)方法是用來(lái)判斷一個(gè)Node是否在AQS的等待隊(duì)列中的对妄，下面是其方法內(nèi)容：
final boolean isOnSyncQueue(Node node) {
if (node.waitStatus == Node.CONDITION || node.prev == null)
return false;
if (node.next != null) // If has successor, it must be on queue
return true;
return findNodeFromTail(node);
}
private boolean findNodeFromTail(Node node) {
Node t = tail;
for (;;) {
if (t == node)
return true;
if (t == null)
return false;
t = t.prev;
}
}
也就是說(shuō)，只要當(dāng)前線程的Node還在Condition上等待的話敢朱，就會(huì)一直在while循環(huán)中等待剪菱，而這個(gè)等待被破除的關(guān)鍵是signal方法，后面會(huì)分析到拴签。我們現(xiàn)在假設(shè)signal方法運(yùn)行完了孝常，并且當(dāng)前線程已經(jīng)被添加到了AQS的SYNC等待隊(duì)列中去了，那么接下來(lái)就使用我們一開(kāi)始獲取到的state值來(lái)競(jìng)爭(zhēng)鎖了蚓哩，而這個(gè)競(jìng)爭(zhēng)就是AQS的邏輯构灸，下面的方法就是這個(gè)競(jìng)爭(zhēng)去獲取鎖的方法：
final boolean acquireQueued(final Node node, int arg) {
boolean failed = true;
try {
boolean interrupted = false;
for (;;) {
final Node p = node.predecessor();
if (p == head && tryAcquire(arg)) {
setHead(node);
p.next = null; // help GC
failed = false;
return interrupted;
}
if (shouldParkAfterFailedAcquire(p, node) &&
parkAndCheckInterrupt())
interrupted = true;
}
} finally {
if (failed)
cancelAcquire(node);
}
}
這個(gè)方法會(huì)自旋的來(lái)獲得同步變量，這個(gè)方法中的循環(huán)結(jié)束的條件是：
- 該節(jié)點(diǎn)的前驅(qū)節(jié)點(diǎn)是頭結(jié)點(diǎn)岸梨，頭結(jié)點(diǎn)代表的是獲得鎖的節(jié)點(diǎn)喜颁，只有它釋放了state其他線程才能獲得這個(gè)變量的所有權(quán)
- 在條件1的前提下，方法tryAcquire返回true曹阔，也就是可以獲得同步資源state
整個(gè)await方法總結(jié)起來(lái)就是首先釋放當(dāng)前線程的條件變量半开，然后獲取到釋放完了之后的state值，我們假設(shè)這就是這個(gè)線程當(dāng)前上下文的一部分內(nèi)容次兆，然后進(jìn)入阻塞等待，一直在while循環(huán)里面等待锹锰，如果當(dāng)前線程的Node被添加到了Sync隊(duì)列中去了芥炭，那么就可以開(kāi)始去競(jìng)爭(zhēng)鎖了，否則一直在等待恃慧，在await方法的整個(gè)過(guò)程中园蝠，可以相應(yīng)中斷。
上面分析了await方法痢士，await(long time, TimeUnit unit)方法只是在await方法上加了一個(gè)超時(shí)時(shí)間彪薛，await會(huì)死等直到被添加到Sync隊(duì)列中去，而await(long time, TimeUnit unit)方法只會(huì)等設(shè)定的超時(shí)時(shí)間怠蹂，如果超時(shí)時(shí)間到了善延，會(huì)自己去競(jìng)爭(zhēng)鎖。
還有awaitUninterruptibly方法是await方法的簡(jiǎn)化版本城侧，它不會(huì)相應(yīng)中斷易遣。awaitUntil(Date deadline)方法讓你可以設(shè)定一個(gè)deadline時(shí)間，如果超過(guò)這個(gè)時(shí)間了還沒(méi)有被添加到Sync隊(duì)列中去嫌佑，那么線程就會(huì)自作主張的去競(jìng)爭(zhēng)鎖了豆茫。
signal和signalAll方法
上面分析了如何使用await等一系列方法來(lái)block線程侨歉，現(xiàn)在來(lái)分析如何使線程沖破block從而參與到獲取鎖的競(jìng)爭(zhēng)中去埂伦。首先分析一下signal方法掰吕，使用這個(gè)方法可以使得線程被添加到Sync隊(duì)列中去競(jìng)爭(zhēng)鎖。
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) &&
(first = firstWaiter) != null);
}
final boolean transferForSignal(Node node) {
if (!compareAndSetWaitStatus(node, Node.CONDITION, 0))
return false;
Node p = enq(node);
int ws = p.waitStatus;
if (ws > 0 || !compareAndSetWaitStatus(p, ws, Node.SIGNAL))
LockSupport.unpark(node.thread);
return true;
}
private Node enq(final Node node) {
for (;;) {
Node t = tail;
if (t == null) { // Must initialize
if (compareAndSetHead(new Node()))
tail = head;
} else {
node.prev = t;
if (compareAndSetTail(t, node)) {
t.next = node;
return t;
}
}
}
}
signal方法首先要喚醒的是等待在它的Condition的等待隊(duì)列上的第一個(gè)節(jié)點(diǎn)撤蟆，signal方法調(diào)用了doSignal方法火脉，而doSignal方法調(diào)用了transferForSignal方法牵舵，transferForSignal方法調(diào)用enq方法將節(jié)點(diǎn)添加到了Sync隊(duì)列中去，至此忘分，await方法的while循環(huán)將不滿足繼續(xù)循環(huán)的條件棋枕，會(huì)執(zhí)行循環(huán)之后的流程，也就是會(huì)去競(jìng)爭(zhēng)鎖妒峦，而之后的流程已經(jīng)在Java同步框架AbstractQueuedSynchronizer中有分析重斑，不在此贅述。
signalAll方法的意思是把所有等待在條件變量上的線程都喚醒去競(jìng)爭(zhēng)鎖肯骇，下面是它的流程窥浪。
public final void signalAll() {
if (!isHeldExclusively())
throw new IllegalMonitorStateException();
Node first = firstWaiter;
if (first != null)
doSignalAll(first);
}
private void doSignalAll(Node first) {
lastWaiter = firstWaiter = null;
do {
Node next = first.nextWaiter;
first.nextWaiter = null;
transferForSignal(first);
first = next;
} while (first != null);
}
在方法doSignalAll中遍歷每一個(gè)等待在條件變量上的Node，然后調(diào)用transferForSignal方法將它們添加到Sync隊(duì)列中去笛丙。關(guān)于Condition的內(nèi)容就分析這么多漾脂，介于后文還要對(duì)java的可重入讀寫鎖進(jìn)行分析，所以篇幅不宜過(guò)長(zhǎng)胚鸯，日后會(huì)對(duì)Condition進(jìn)行更為深入的學(xué)習(xí)和總結(jié)骨稿。
ReentrantReadWriteLock
ReentrantReadWriteLock即可重入讀寫鎖，下文將分析它在什么情況下是可重入的姜钳，而在什么情況下是獨(dú)占的坦冠。ReentrantReadWriteLock 類實(shí)現(xiàn)了ReadWriteLock接口，它提供的讀寫鎖是分離的哥桥，讀鎖和寫鎖分別是獨(dú)立的鎖辙浑。而讀鎖和寫鎖的實(shí)現(xiàn)也是不一樣的，ReentrantReadWriteLock使用了兩個(gè)內(nèi)部類ReadLock和WriteLock來(lái)分別表示讀鎖和寫鎖拟糕，而這兩種鎖又依賴于基于AQS的類Sync來(lái)實(shí)現(xiàn)判呕，Sync也是一個(gè)內(nèi)部類，它繼承了AQS類來(lái)實(shí)現(xiàn)了lock和unlock的語(yǔ)義送滞。首先來(lái)分析一下其Sync內(nèi)部類侠草。
Sync內(nèi)部類
首要解決的一個(gè)問(wèn)題是，我們知道犁嗅，AQS是使用了一個(gè)int類型的值來(lái)表示同步變量的梦抢，現(xiàn)在要使用一個(gè)int值來(lái)表示讀鎖和寫鎖兩種類型的同步，怎么辦呢愧哟？我們知道奥吩，一個(gè)int是32位的哼蛆，ReentrantReadWriteLock使用高16位代表了讀鎖同步變量，而低16位代表了寫鎖同步變量霞赫，所以讀鎖與寫鎖的可重入數(shù)量限定在了(2^16-1)個(gè)腮介，當(dāng)然AQS還有一個(gè)使用long變量來(lái)實(shí)現(xiàn)的版本AbstractQueuedLongSynchronizer，它的實(shí)現(xiàn)和AQS除了使用了long類型的變量來(lái)代表同步變量之外沒(méi)有區(qū)別端衰。下面我們來(lái)看一下Sync是如何獲取重入的讀線程數(shù)量和寫線程數(shù)量的：
static final int SHARED_SHIFT = 16;
static final int SHARED_UNIT = (1 << SHARED_SHIFT);
static final int MAX_COUNT = (1 << SHARED_SHIFT) - 1;
static final int EXCLUSIVE_MASK = (1 << SHARED_SHIFT) - 1;
/** Returns the number of shared holds represented in count */
static int sharedCount(int c) { return c >>> SHARED_SHIFT; }
/** Returns the number of exclusive holds represented in count */
static int exclusiveCount(int c) { return c & EXCLUSIVE_MASK; }
我們來(lái)實(shí)踐一個(gè)叠洗，比如現(xiàn)在的c是589826，則 (589826 >>> 16 = 9)旅东，說(shuō)明有9個(gè)讀可重入數(shù)量灭抑，而(589826 & (1 << 16 - 1)) = 2，說(shuō)明有寫重入的數(shù)量為2抵代。需要注意的一點(diǎn)是腾节，讀鎖可以有多個(gè)線程獲取，而寫鎖只允許一個(gè)線程獲取荤牍，那如何使用16位來(lái)代表多個(gè)讀鎖呢案腺？ReentrantReadWriteLock使用了ThreadLocal來(lái)保存每個(gè)線程的重入數(shù)量，關(guān)于ThreadLocal的分析總結(jié)康吵，可以參考Java中的ThreadLocal和 InheritableThreadLocal劈榨，ReentrantReadWriteLock的做法如下：
/**
* A counter for per-thread read hold counts.
* Maintained as a ThreadLocal; cached in cachedHoldCounter
*/
static final class HoldCounter {
int count = 0;
// Use id, not reference, to avoid garbage retention
final long tid = getThreadId(Thread.currentThread());
}
/**
* ThreadLocal subclass. Easiest to explicitly define for sake
* of deserialization mechanics.
*/
static final class ThreadLocalHoldCounter
extends ThreadLocal<HoldCounter> {
public HoldCounter initialValue() {
return new HoldCounter();
}
}
private transient HoldCounter cachedHoldCounter;
Sync類實(shí)現(xiàn)了一些子類通用了方法，下面重點(diǎn)分析幾個(gè)方法晦嵌。
tryRelease和tryReleaseShared方法
tryRelease方法重寫了AQS的tryRelease方法同辣，而tryRelease這個(gè)方法會(huì)在release方法中使用到，也就是在unlock的時(shí)候用到惭载。下面展示了它的細(xì)節(jié)：
protected final boolean tryRelease(int releases) {
if (!isHeldExclusively())
throw new IllegalMonitorStateException();
int nextc = getState() - releases;
boolean free = exclusiveCount(nextc) == 0;
if (free)
setExclusiveOwnerThread(null);
setState(nextc);
return free;
}
tryRelease很好理解旱函，它的任務(wù)就是去更新state值，它調(diào)用了我們上面分析過(guò)的exclusiveCount方法來(lái)計(jì)算寫重入的數(shù)量棕兼。到這里需要提出的是陡舅，ReentrantReadWriteLock在實(shí)現(xiàn)上實(shí)現(xiàn)了讀鎖和寫鎖抵乓，讀鎖允許多個(gè)線程重入伴挚，使用了AQS的共享模式，而寫鎖只允許一個(gè)線程獲得鎖灾炭，使用了AQS的獨(dú)占模式茎芋，所以這個(gè)tryRelease方法會(huì)在WriteLock的unlock方法中被用到，而ReadLock中的unlock使用的是AQS的releaseShared方法蜈出，而這個(gè)方法會(huì)調(diào)用AQS的tryReleaseShared方法田弥，而這個(gè)方法在Sync被重寫，也就是接下來(lái)分析的方法：
protected final boolean tryReleaseShared(int unused) {
Thread current = Thread.currentThread();
if (firstReader == current) {
// assert firstReaderHoldCount > 0;
if (firstReaderHoldCount == 1)
firstReader = null;
else
firstReaderHoldCount--;
} else {
HoldCounter rh = cachedHoldCounter;
if (rh == null || rh.tid != getThreadId(current))
rh = readHolds.get();
int count = rh.count;
if (count <= 1) {
readHolds.remove();
if (count <= 0)
throw unmatchedUnlockException();
}
--rh.count;
}
for (;;) {
int c = getState();
int nextc = c - SHARED_UNIT;
if (compareAndSetState(c, nextc))
// Releasing the read lock has no effect on readers,
// but it may allow waiting writers to proceed if
// both read and write locks are now free.
return nextc == 0;
}
}
可以很明顯的感覺(jué)得出來(lái)铡原，讀鎖的釋放要比寫鎖的釋放要麻煩很多偷厦，因?yàn)閷戞i只有一個(gè)線程獲得商叹，而讀鎖則有多個(gè)線程獲取。釋放需要獲取到當(dāng)前線程的ThreadLocal變量只泼，然后更新它的重入數(shù)量剖笙，更新state值∏氤可以看到弥咪，因?yàn)槭褂昧薚hreadLocal，使得多個(gè)線程的問(wèn)題變得簡(jiǎn)單起來(lái)十绑，就好像是操作同一個(gè)線程一樣聚至。
tryAcquire和tryAcquireShared方法
ReadLock在調(diào)用lock方法的時(shí)候，會(huì)調(diào)用AQS的releaseShared方法本橙，而releaseShared方法會(huì)調(diào)用AQS的tryReleaseShared方法扳躬，而tryReleaseShared方法在Sync中被重寫了。WriteLock在lock的時(shí)候勋功，會(huì)調(diào)用AQS的acquire方法坦报，而acquire方法會(huì)調(diào)用AQS的tryAcquire方法，而tryAcquire方法在Sync中被重寫了狂鞋，所以接下來(lái)分析一下這兩個(gè)被重寫的方法來(lái)認(rèn)識(shí)一下WriteLock和ReadLock是如何通過(guò)AQS來(lái)lock的片择。
首先是tryAcquire方法：
protected final boolean tryAcquire(int acquires) {
/*
* Walkthrough:
* 1. If read count nonzero or write count nonzero
* and owner is a different thread, fail.
* 2. If count would saturate, fail. (This can only
* happen if count is already nonzero.)
* 3. Otherwise, this thread is eligible for lock if
* it is either a reentrant acquire or
* queue policy allows it. If so, update state
* and set owner.
*/
Thread current = Thread.currentThread();
int c = getState();
int w = exclusiveCount(c);
if (c != 0) {
// (Note: if c != 0 and w == 0 then shared count != 0)
if (w == 0 || current != getExclusiveOwnerThread())
return false;
if (w + exclusiveCount(acquires) > MAX_COUNT)
throw new Error("Maximum lock count exceeded");
// Reentrant acquire
setState(c + acquires);
return true;
}
if (writerShouldBlock() ||
!compareAndSetState(c, c + acquires))
return false;
setExclusiveOwnerThread(current);
return true;
}
這個(gè)方法用于寫鎖上鎖，我們知道骚揍，只有一個(gè)線程可以獲取到寫鎖字管，如果w為0，說(shuō)明已經(jīng)有線程獲得了讀鎖信不，而在有讀線程在讀取數(shù)據(jù)的時(shí)候嘲叔，寫鎖是無(wú)法獲得的，所以w為0直接回失敗抽活，或者w不為0則說(shuō)明了已經(jīng)有線程獲得了寫鎖硫戈，那么因?yàn)橹辉试S有一個(gè)線程獲取到寫鎖，所以如果當(dāng)前線程不是那個(gè)獲得了寫鎖的獨(dú)占鎖的話下硕，也就直接失敗丁逝，否則，如果上面兩條檢測(cè)都通過(guò)了梭姓，也就是說(shuō)霜幼，當(dāng)前沒(méi)有線程獲得讀鎖和寫鎖，那么判斷重入數(shù)量是否超過(guò)了最大值誉尖，如果是則拋出異常罪既，否則上鎖成功。上面的分析都是基于c不為0，也就是說(shuō)已經(jīng)有線程獲得了讀鎖或者寫鎖的情況下分析的琢感，那如果c為0呢丢间？說(shuō)明當(dāng)前環(huán)境下沒(méi)有線程占有鎖，那么接下來(lái)就分公平鎖和非公平鎖了驹针，Sync有兩個(gè)抽象方法需要子類來(lái)實(shí)現(xiàn)為公平鎖還是非公平鎖：
/**
* Returns true if the current thread, when trying to acquire
* the read lock, and otherwise eligible to do so, should block
* because of policy for overtaking other waiting threads.
*/
abstract boolean readerShouldBlock();
/**
* Returns true if the current thread, when trying to acquire
* the write lock, and otherwise eligible to do so, should block
* because of policy for overtaking other waiting threads.
*/
abstract boolean writerShouldBlock();
具體的細(xì)節(jié)到公平鎖和非公平鎖的分析上再講細(xì)節(jié)千劈。上面分析完了WriteLock使用的lock需要的tryAcquire方法，下面來(lái)分析一下ReadLock的lock需要的tryReleaseShared方法：
protected final int tryAcquireShared(int unused) {
/*
* Walkthrough:
* 1. If write lock held by another thread, fail.
* 2. Otherwise, this thread is eligible for
* lock wrt state, so ask if it should block
* because of queue policy. If not, try
* to grant by CASing state and updating count.
* Note that step does not check for reentrant
* acquires, which is postponed to full version
* to avoid having to check hold count in
* the more typical non-reentrant case.
* 3. If step 2 fails either because thread
* apparently not eligible or CAS fails or count
* saturated, chain to version with full retry loop.
*/
Thread current = Thread.currentThread();
int c = getState();
if (exclusiveCount(c) != 0 &&
getExclusiveOwnerThread() != current)
return -1;
int r = sharedCount(c);
if (!readerShouldBlock() &&
r < MAX_COUNT &&
compareAndSetState(c, c + SHARED_UNIT)) {
if (r == 0) {
firstReader = current;
firstReaderHoldCount = 1;
} else if (firstReader == current) {
firstReaderHoldCount++;
} else {
HoldCounter rh = cachedHoldCounter;
if (rh == null || rh.tid != getThreadId(current))
cachedHoldCounter = rh = readHolds.get();
else if (rh.count == 0)
readHolds.set(rh);
rh.count++;
}
return 1;
}
return fullTryAcquireShared(current);
}
同樣比WriteLock的要復(fù)雜很多牌捷，這個(gè)方法會(huì)返回1或者-1代表lock的結(jié)果墙牌，1代表lock成功了，-1代表lock失敗了暗甥，來(lái)分析一下在上面情況下會(huì)失斚脖酢：
1、如果有線程已經(jīng)獲得了寫鎖撤防，那么肯定會(huì)失敗虽风，因?yàn)閷戞i是排斥鎖，不允許其他線程獲得任意類型的鎖
2寄月、如果重入的數(shù)量已經(jīng)超過(guò)了限定辜膝，那么也會(huì)失敗，如果你還想要支持更多的重入數(shù)量漾肮，那么使用AbstractQueuedLongSynchronizer來(lái)代替AQS
而在下面的情況下是會(huì)成功的：
1厂抖、沒(méi)有線程獲得寫鎖
2、獲得寫鎖的線程就是當(dāng)前想要獲得讀鎖的線程
3克懊、重入數(shù)量沒(méi)有超過(guò)上限
總結(jié)起來(lái)就是忱辅，只要有線程獲得了寫鎖，那么其他線程都獲取不到寫鎖谭溉，如果獲得寫鎖的線程想要獲取讀鎖墙懂，那么可以成功。在獲取讀鎖的時(shí)候扮念，多個(gè)線程可以同時(shí)獲得讀鎖损搬，讀鎖是共享鎖，而寫鎖是獨(dú)占鎖柜与。
FairSync和NonFairSync的實(shí)現(xiàn)
這兩個(gè)類僅僅是繼承了父類然后實(shí)現(xiàn)了兩個(gè)抽象方法巧勤，來(lái)表示讀線程是否需要阻塞和寫線程是否需要阻塞，以這樣的方式來(lái)達(dá)到公平鎖和非公平鎖的目的旅挤。
下面是公平鎖的實(shí)現(xiàn)：
final boolean writerShouldBlock() {
return hasQueuedPredecessors();
}
final boolean readerShouldBlock() {
return hasQueuedPredecessors();
}
可以看出踢关，對(duì)于公平鎖來(lái)說(shuō)伞鲫，讀鎖和寫鎖都是查看Sync隊(duì)列中是否有排隊(duì)的線程粘茄，如果沒(méi)有，則可以放行，否則就得排隊(duì)柒瓣。下面是非公平鎖的實(shí)現(xiàn)：
final boolean writerShouldBlock() {
return false; // writers can always barge
}
final boolean readerShouldBlock() {
/* As a heuristic to avoid indefinite writer starvation,
* block if the thread that momentarily appears to be head
* of queue, if one exists, is a waiting writer. This is
* only a probabilistic effect since a new reader will not
* block if there is a waiting writer behind other enabled
* readers that have not yet drained from the queue.
*/
return apparentlyFirstQueuedIsExclusive();
}
final boolean apparentlyFirstQueuedIsExclusive() {
Node h, s;
return (h = head) != null &&
(s = h.next) != null &&
!s.isShared() &&
s.thread != null;
}
在非公平鎖中儒搭，寫鎖的獲取不需要阻塞，而讀鎖的獲取在apparentlyFirstQueuedIsExclusive中判斷是否需要阻塞芙贫。所謂公平鎖和非公平鎖只是希望能對(duì)所有的線程都不區(qū)別對(duì)待搂鲫，但是使用公平鎖的代價(jià)是吞吐量沒(méi)有非公平鎖那么大，所以磺平，如果我們的需求沒(méi)有特別的原因魂仍，應(yīng)該使用非公平鎖。
ReadLock和WriteLock
上面介紹了Sync類拣挪，現(xiàn)在來(lái)分析一下ReadLock和WriteLock是如何通過(guò)Sync提高的方法來(lái)實(shí)現(xiàn)lock和unlock的擦酌。首先是ReadLock。它的lock和unlock方法如下：
public void lock() {
sync.acquireShared(1);
}
public void unlock() {
sync.releaseShared(1);
}
而WriteLock的lock和unlock方法如下：
public void lock() {
sync.acquire(1);
}
public void unlock() {
sync.release(1);
}
如果想要獲取更多關(guān)于AQS的相關(guān)知識(shí)菠劝，可以去閱讀AQS的源代碼赊舶，或者參考Java同步框架AbstractQueuedSynchronizer，上文中也對(duì)lock和unlock的流程有所分析赶诊，再次也不做贅述笼平。
可重入鎖使用示例
最后，在分析了ReentrantLock和ReentrantReadWriteLock之后舔痪，來(lái)看一下如何使用它們寓调。
ReentrantLock使用示例
/**
* how to use ReentrantLock lock
*/
class LockX {
private final Lock LOCK = new ReentrantLock(); // non-fair lock
public void lockMethod() {
LOCK.lock();
try {
doBiz();
} catch (Exception e) {
e.printStackTrace();
} finally {
LOCK.unlock();
}
}
public void doBiz() {
}
}
你需要注意的是你應(yīng)該總是在try塊中執(zhí)行你的業(yè)務(wù)代碼，然后在finally中unlock掉锄码。
ReentrantReadWriteLock使用示例
abstract class CachedData {
Object data;
volatile boolean cacheValid;
final ReentrantReadWriteLock rwl = new ReentrantReadWriteLock();
void processCachedData() {
rwl.readLock().lock();
if (!cacheValid) {
// Must release read lock before acquiring write lock
rwl.readLock().unlock();
rwl.writeLock().lock();
try {
// Recheck state because another thread might have
// acquired write lock and changed state before we did.
if (!cacheValid) {
data = loadData();
cacheValid = true;
}
// Downgrade by acquiring read lock before releasing write lock
rwl.readLock().lock();
} finally {
rwl.writeLock().unlock(); // Unlock write, still hold read
}
}
try {
consumeData(data);
} finally {
rwl.readLock().unlock();
}
}
abstract Object loadData();
abstract void consumeData(Object data);
}
別忘了在lock之后要unlock捶牢，否則如果一個(gè)寫鎖被獲取之后沒(méi)有釋放的話，就不可能有鎖獲得鎖了除非它自己本身巍耗。通用的做法是在try 塊中進(jìn)行業(yè)務(wù)處理秋麸，然后在finally中釋放鎖。Lock接口的使用相比于synchronized的使用要復(fù)雜很多炬太，所以在大部分情況下灸蟆，你應(yīng)該使用synchronized來(lái)做并發(fā)控制，而不是Lock亲族，但是如果想要做更加靈活的鎖控制炒考，你就可以選擇使用Lock接口的具體實(shí)現(xiàn)類來(lái)應(yīng)用，或者繼承AQS來(lái)實(shí)現(xiàn)自己的同步器霎迫。
