天天看點

Java并發之AQS詳解

談到并發,不得不談ReentrantLock;而談到ReentrantLock,不得不談AbstractQueuedSynchronized(AQS)!

類如其名,抽象的隊列式的同步器,AQS定義了一套多線程通路共享資源的同步器架構,許多同步類實作都依賴于它,如常用的ReentrantLock/Semaphore/CountDownLatch...。

以下是本文的目錄大綱:

概述

架構

源碼詳解

簡單應用

若有不正之處,請諒解和批評指正,不勝感激。

Java并發之AQS詳解

它維護了一個volatile int state(代表共享資源)和一個FIFO線程等待隊列(多線程争用資源被阻塞時會進入此隊列)。這裡volatile是核心關鍵詞,具體volatile的語義,在此不述。state的通路方式有三種:

getState()

setState()

compareAndSetState()

AQS定義兩種資源共享方式:Exclusive(獨占,隻有一個線程能執行,如ReentrantLock)和Share(共享,多個線程可同時執行,如Semaphore/CountDownLatch)。

不同的自定義同步器争用共享資源的方式也不同。自定義同步器在實作時隻需要實作共享資源state的擷取與釋放方式即可,至于具體線程等待隊列的維護(如擷取資源失敗入隊/喚醒出隊等),AQS已經在頂層實作好了。自定義同步器實作時主要實作以下幾種方法:

isHeldExclusively():該線程是否正在獨占資源。隻有用到condition才需要去實作它。

tryAcquire(int):獨占方式。嘗試擷取資源,成功則傳回true,失敗則傳回false。

tryRelease(int):獨占方式。嘗試釋放資源,成功則傳回true,失敗則傳回false。

tryAcquireShared(int):共享方式。嘗試擷取資源。負數表示失敗;0表示成功,但沒有剩餘可用資源;正數表示成功,且有剩餘資源。

tryReleaseShared(int):共享方式。嘗試釋放資源,成功則傳回true,失敗則傳回false。

以ReentrantLock為例,state初始化為0,表示未鎖定狀态。A線程lock()時,會調用tryAcquire()獨占該鎖并将state+1。此後,其他線程再tryAcquire()時就會失敗,直到A線程unlock()到state=0(即釋放鎖)為止,其它線程才有機會擷取該鎖。當然,釋放鎖之前,A線程自己是可以重複擷取此鎖的(state會累加),這就是可重入的概念。但要注意,擷取多少次就要釋放多麼次,這樣才能保證state是能回到零态的。

再以CountDownLatch以例,任務分為N個子線程去執行,state也初始化為N(注意N要與線程個數一緻)。這N個子線程是并行執行的,每個子線程執行完後countDown()一次,state會CAS減1。等到所有子線程都執行完後(即state=0),會unpark()主調用線程,然後主調用線程就會從await()函數傳回,繼續後餘動作。

一般來說,自定義同步器要麼是獨占方法,要麼是共享方式,他們也隻需實作tryAcquire-tryRelease、tryAcquireShared-tryReleaseShared中的一種即可。但AQS也支援自定義同步器同時實作獨占和共享兩種方式,如ReentrantReadWriteLock。

本節開始講解AQS的源碼實作。依照acquire-release、acquireShared-releaseShared的次序來。

此方法是獨占模式下線程擷取共享資源的頂層入口。如果擷取到資源,線程直接傳回,否則進入等待隊列,直到擷取到資源為止,且整個過程忽略中斷的影響。這也正是lock()的語義,當然不僅僅隻限于lock()。擷取到資源後,線程就可以去執行其臨界區代碼了。下面是acquire()的源碼:

函數流程如下:

tryAcquire()嘗試直接去擷取資源,如果成功則直接傳回;

addWaiter()将該線程加入等待隊列的尾部,并标記為獨占模式;

acquireQueued()使線程在等待隊列中擷取資源,一直擷取到資源後才傳回。如果在整個等待過程中被中斷過,則傳回true,否則傳回false。

如果線程在等待過程中被中斷過,它是不響應的。隻是擷取資源後才再進行自我中斷selfInterrupt(),将中斷補上。

這時單憑這4個抽象的函數來看流程還有點朦胧,不要緊,看完接下來的分析後,你就會明白了。就像《大話西遊》裡唐僧說的:等你明白了舍生取義的道理,你自然會回來和我唱這首歌的。

此方法嘗試去擷取獨占資源。如果擷取成功,則直接傳回true,否則直接傳回false。這也正是tryLock()的語義,還是那句話,當然不僅僅隻限于tryLock()。如下是tryAcquire()的源碼:

什麼?直接throw異常?說好的功能呢?好吧,還記得概述裡講的AQS隻是一個架構,具體資源的擷取/釋放方式交由自定義同步器去實作嗎?就是這裡了!!!AQS這裡隻定義了一個接口,具體資源的擷取交由自定義同步器去實作了(通過state的get/set/CAS)!!!至于能不能重入,能不能加塞,那就看具體的自定義同步器怎麼去設計了!!!當然,自定義同步器在進行資源通路時要考慮線程安全的影響。

這裡之是以沒有定義成abstract,是因為獨占模式下隻用實作tryAcquire-tryRelease,而共享模式下隻用實作tryAcquireShared-tryReleaseShared。如果都定義成abstract,那麼每個模式也要去實作另一模式下的接口。說到底,Doug Lea還是站在咱們開發者的角度,盡量減少不必要的工作量。

此方法用于将目前線程加入到等待隊列的隊尾,并傳回目前線程所在的結點。還是上源碼吧:

 不用再說了,直接看注釋吧。

此方法用于将node加入隊尾。源碼如下:

如果你看過AtomicInteger.getAndIncrement()函數源碼,那麼相信你一眼便看出這段代碼的精華。CAS自旋volatile變量,是一種很經典的用法。還不太了解的,自己去百度一下吧。

OK,通過tryAcquire()和addWaiter(),該線程擷取資源失敗,已經被放入等待隊列尾部了。聰明的你立刻應該能想到該線程下一部該幹什麼了吧:進入等待狀态休息,直到其他線程徹底釋放資源後喚醒自己,自己再拿到資源,然後就可以去幹自己想幹的事了。沒錯,就是這樣!是不是跟醫院排隊拿号有點相似~~acquireQueued()就是幹這件事:在等待隊列中排隊拿号(中間沒其它事幹可以休息),直到拿到号後再傳回。這個函數非常關鍵,還是上源碼吧:

到這裡了,我們先不急着總結acquireQueued()的函數流程,先看看shouldParkAfterFailedAcquire()和parkAndCheckInterrupt()具體幹些什麼。

此方法主要用于檢查狀态,看看自己是否真的可以去休息了(進入waiting狀态,如果線程狀态轉換不熟,可以參考本人上一篇寫的Thread詳解),萬一隊列前邊的線程都放棄了隻是瞎站着,那也說不定,對吧!

整個流程中,如果前驅結點的狀态不是SIGNAL,那麼自己就不能安心去休息,需要去找個安心的休息點,同時可以再嘗試下看有沒有機會輪到自己拿号。

如果線程找好安全休息點後,那就可以安心去休息了。此方法就是讓線程去休息,真正進入等待狀态。

park()會讓目前線程進入waiting狀态。在此狀态下,有兩種途徑可以喚醒該線程:1)被unpark();2)被interrupt()。(再說一句,如果線程狀态轉換不熟,可以參考本人寫的Thread詳解)。需要注意的是,Thread.interrupted()會清除目前線程的中斷标記位。 

OK,看了shouldParkAfterFailedAcquire()和parkAndCheckInterrupt(),現在讓我們再回到acquireQueued(),總結下該函數的具體流程:

結點進入隊尾後,檢查狀态,找到安全休息點;

調用park()進入waiting狀态,等待unpark()或interrupt()喚醒自己;

被喚醒後,看自己是不是有資格能拿到号。如果拿到,head指向目前結點,并傳回從入隊到拿到号的整個過程中是否被中斷過;如果沒拿到,繼續流程1。

acquireQueued()分析完之後,我們接下來再回到acquire()!再貼上它的源碼吧:

再來總結下它的流程吧:

調用自定義同步器的tryAcquire()嘗試直接去擷取資源,如果成功則直接傳回;

沒成功,則addWaiter()将該線程加入等待隊列的尾部,并标記為獨占模式;

acquireQueued()使線程在等待隊列中休息,有機會時(輪到自己,會被unpark())會去嘗試擷取資源。擷取到資源後才傳回。如果在整個等待過程中被中斷過,則傳回true,否則傳回false。

由于此函數是重中之重,我再用流程圖總結一下:

Java并發之AQS詳解

至此,acquire()的流程終于算是告一段落了。這也就是ReentrantLock.lock()的流程,不信你去看其lock()源碼吧,整個函數就是一條acquire(1)!!!

上一小節已經把acquire()說完了,這一小節就來講講它的反操作release()吧。此方法是獨占模式下線程釋放共享資源的頂層入口。它會釋放指定量的資源,如果徹底釋放了(即state=0),它會喚醒等待隊列裡的其他線程來擷取資源。這也正是unlock()的語義,當然不僅僅隻限于unlock()。下面是release()的源碼:

邏輯并不複雜。它調用tryRelease()來釋放資源。有一點需要注意的是,它是根據tryRelease()的傳回值來判斷該線程是否已經完成釋放掉資源了!是以自定義同步器在設計tryRelease()的時候要明确這一點!!

此方法嘗試去釋放指定量的資源。下面是tryRelease()的源碼:

跟tryAcquire()一樣,這個方法是需要獨占模式的自定義同步器去實作的。正常來說,tryRelease()都會成功的,因為這是獨占模式,該線程來釋放資源,那麼它肯定已經拿到獨占資源了,直接減掉相應量的資源即可(state-=arg),也不需要考慮線程安全的問題。但要注意它的傳回值,上面已經提到了,release()是根據tryRelease()的傳回值來判斷該線程是否已經完成釋放掉資源了!是以自義定同步器在實作時,如果已經徹底釋放資源(state=0),要傳回true,否則傳回false。

此方法用于喚醒等待隊列中下一個線程。下面是源碼:

這個函數并不複雜。一句話概括:用unpark()喚醒等待隊列中最前邊的那個未放棄線程,這裡我們也用s來表示吧。此時,再和acquireQueued()聯系起來,s被喚醒後,進入if (p == head && tryAcquire(arg))的判斷(即使p!=head也沒關系,它會再進入shouldParkAfterFailedAcquire()尋找一個安全點。這裡既然s已經是等待隊列中最前邊的那個未放棄線程了,那麼通過shouldParkAfterFailedAcquire()的調整,s也必然會跑到head的next結點,下一次自旋p==head就成立啦),然後s把自己設定成head标杆結點,表示自己已經擷取到資源了,acquire()也傳回了!!And then, DO what you WANT!

release()是獨占模式下線程釋放共享資源的頂層入口。它會釋放指定量的資源,如果徹底釋放了(即state=0),它會喚醒等待隊列裡的其他線程來擷取資源。

此方法是共享模式下線程擷取共享資源的頂層入口。它會擷取指定量的資源,擷取成功則直接傳回,擷取失敗則進入等待隊列,直到擷取到資源為止,整個過程忽略中斷。下面是acquireShared()的源碼:

這裡tryAcquireShared()依然需要自定義同步器去實作。但是AQS已經把其傳回值的語義定義好了:負值代表擷取失敗;0代表擷取成功,但沒有剩餘資源;正數表示擷取成功,還有剩餘資源,其他線程還可以去擷取。是以這裡acquireShared()的流程就是:

tryAcquireShared()嘗試擷取資源,成功則直接傳回;

失敗則通過doAcquireShared()進入等待隊列,直到擷取到資源為止才傳回。

此方法用于将目前線程加入等待隊列尾部休息,直到其他線程釋放資源喚醒自己,自己成功拿到相應量的資源後才傳回。下面是doAcquireShared()的源碼:

有木有覺得跟acquireQueued()很相似?對,其實流程并沒有太大差別。隻不過這裡将補中斷的selfInterrupt()放到doAcquireShared()裡了,而獨占模式是放到acquireQueued()之外,其實都一樣,不知道Doug Lea是怎麼想的。

跟獨占模式比,還有一點需要注意的是,這裡隻有線程是head.next時(“老二”),才會去嘗試擷取資源,有剩餘的話還會喚醒之後的隊友。那麼問題就來了,假如老大用完後釋放了5個資源,而老二需要6個,老三需要1個,老四需要2個。因為老大先喚醒老二,老二一看資源不夠自己用繼續park(),也更不會去喚醒老三和老四了。獨占模式,同一時刻隻有一個線程去執行,這樣做未嘗不可;但共享模式下,多個線程是可以同時執行的,現在因為老二的資源需求量大,而把後面量小的老三和老四也都卡住了。

此方法在setHead()的基礎上多了一步,就是自己蘇醒的同時,如果條件符合(比如還有剩餘資源),還會去喚醒後繼結點,畢竟是共享模式!

doReleaseShared()我們留着下一小節的releaseShared()裡來講。

OK,至此,acquireShared()也要告一段落了。讓我們再梳理一下它的流程:

失敗則通過doAcquireShared()進入等待隊列park(),直到被unpark()/interrupt()并成功擷取到資源才傳回。整個等待過程也是忽略中斷的。

  其實跟acquire()的流程大同小異,隻不過多了個自己拿到資源後,還會去喚醒後繼隊友的操作(這才是共享嘛)。

上一小節已經把acquireShared()說完了,這一小節就來講講它的反操作releaseShared()吧。此方法是共享模式下線程釋放共享資源的頂層入口。它會釋放指定量的資源,如果徹底釋放了(即state=0),它會喚醒等待隊列裡的其他線程來擷取資源。下面是releaseShared()的源碼:

此方法的流程也比較簡單,一句話:釋放掉資源後,喚醒後繼。跟獨占模式下的release()相似,但有一點稍微需要注意:獨占模式下的tryRelease()在完全釋放掉資源(state=0)後,才會傳回true去喚醒其他線程,這主要是基于可重入的考量;而共享模式下的releaseShared()則沒有這種要求,一是共享的實質--多線程可并發執行;二是共享模式基本也不會重入吧(至少我還沒見過),是以自定義同步器可以根據需要決定傳回值。

此方法主要用于喚醒後繼。下面是它的源碼:

本節我們詳解了獨占和共享兩種模式下擷取-釋放資源(acquire-release、acquireShared-releaseShared)的源碼,相信大家都有一定認識了。值得注意的是,acquire()和acquireSahred()兩種方法下,線程在等待隊列中都是忽略中斷的。AQS也支援響應中斷的,acquireInterruptibly()/acquireSharedInterruptibly()即是,這裡相應的源碼跟acquire()和acquireSahred()差不多,這裡就不再詳解了。

通過前邊幾個章節的學習,相信大家已經基本了解AQS的原理了。這裡再将“架構”一節中的一段話複制過來:

  OK,下面我們就以AQS源碼裡的Mutex為例,講一下AQS的簡單應用。

Mutex是一個不可重入的互斥鎖實作。鎖資源(AQS裡的state)隻有兩種狀态:0表示未鎖定,1表示鎖定。下邊是Mutex的核心源碼:

同步類在實作時一般都将自定義同步器(sync)定義為内部類,供自己使用;而同步類自己(Mutex)則實作某個接口,對外服務。當然,接口的實作要直接依賴sync,它們在語義上也存在某種對應關系!!而sync隻用實作資源state的擷取-釋放方式tryAcquire-tryRelelase,至于線程的排隊、等待、喚醒等,上層的AQS都已經實作好了,我們不用關心。

除了Mutex,ReentrantLock/CountDownLatch/Semphore這些同步類的實作方式都差不多,不同的地方就在擷取-釋放資源的方式tryAcquire-tryRelelase。掌握了這點,AQS的核心便被攻破了!

OK,至此,整個AQS的講解也要落下帷幕了。希望本文能夠對學習Java并發程式設計的同學有所借鑒,中間寫的有不對的地方,也歡迎讨論和指正~

原文連結:http://www.cnblogs.com/waterystone/p/4920797.html

♥ 作者:明志健緻遠

♠ 出處:http://www.cnblogs.com/study-everyday/

♦ 本文版權歸作者和部落格園共有,歡迎轉載,但未經作者同意必須保留此段聲明,且在文章頁面明顯位置給出原文連接配接,否則保留追究法律責任的權利。

♣ 本部落格大多為學習筆記或讀書筆記,本文如對您有幫助,還請多推薦下此文,如有錯誤歡迎指正,互相學習,共同進步。

繼續閱讀