首頁(yè)技術(shù)文章正文

java之synchronized的實(shí)現(xiàn)原理

更新時(shí)間:2018-07-25 來(lái)源:黑馬程序員JavaEE培訓(xùn)學(xué)院 瀏覽量:

目前在Java中存在兩種鎖機(jī)制:synchronized和Lock, Lock接口及其實(shí)現(xiàn)類是JDK5增加的內(nèi)容,其作者是大名鼎鼎的并發(fā)專家Doug Lea。本文并不比較synchronized與Lock孰優(yōu)孰劣,只是介紹二者的實(shí)現(xiàn)原理。

數(shù)據(jù)同步需要依賴鎖,那鎖的同步又依賴誰(shuí)?synchronized給出的答案是在軟件層面依賴JVM,而Lock給出的方案是在硬件層面依賴特殊的CPU指令,大家可能會(huì)進(jìn)一步追問(wèn):JVM底層又是如何實(shí)現(xiàn)synchronized的?

本文所指說(shuō)的JVM是指Hotspot的6u23版本,下面首先介紹synchronized的實(shí)現(xiàn):synrhronized關(guān)鍵字簡(jiǎn)潔、清晰、語(yǔ)義明確,因此即使有了Lock接口,使用的還是非常廣泛。其應(yīng)用層的語(yǔ)義是可以把任何一個(gè)非null對(duì)象作為”鎖”, 當(dāng)synchronized作用在方法上時(shí),鎖住的便是對(duì)象實(shí)例(this);當(dāng)作用在靜態(tài)方法時(shí)鎖住的便是對(duì)象對(duì)應(yīng)的Class實(shí)例,因?yàn)镃lass數(shù)據(jù)存在于永久代,因此靜態(tài)方法鎖相當(dāng)于該類的一個(gè)全局鎖;當(dāng)synchronized作用于某一個(gè)對(duì)象實(shí)例時(shí),鎖住的便是對(duì)應(yīng)的代碼塊。在HotSpot JVM實(shí)現(xiàn)中,鎖有個(gè)專門(mén)的名字:對(duì)象監(jiān)視器。

1、線程狀態(tài)及狀態(tài)轉(zhuǎn)換

當(dāng)多個(gè)線程同時(shí)請(qǐng)求某個(gè)對(duì)象監(jiān)視器時(shí),對(duì)象監(jiān)視器會(huì)設(shè)置幾種狀態(tài)用來(lái)區(qū)分請(qǐng)求的線程:

Contention List:所有請(qǐng)求鎖的線程將被首先放置到該競(jìng)爭(zhēng)隊(duì)列

Entry List:Contention List中那些有資格成為候選人的線程被移到Entry List

Wait Set:那些調(diào)用wait方法被阻塞的線程被放置到Wait Set

OnDeck:任何時(shí)刻最多只能有一個(gè)線程正在競(jìng)爭(zhēng)鎖,該線程稱為OnDeck

Owner:獲得鎖的線程稱為Owner

!Owner:釋放鎖的線程

新請(qǐng)求鎖的線程將首先被加入到ConetentionList中,當(dāng)某個(gè)擁有鎖的線程(Owner狀態(tài))調(diào)用unlock之后,如果發(fā)現(xiàn)EntryList為空則從ContentionList中移動(dòng)線程到EntryList, 下面說(shuō)明下ContentionList和EntryList的實(shí)現(xiàn)方式:

1.1 ContentionList虛擬隊(duì)列

ContentionList并不是一個(gè)真正的Queue,而只是一個(gè)虛擬隊(duì)列,原因在于ContentionList是由Node及其next指針邏輯構(gòu)成,并不存在一個(gè)Queue的數(shù)據(jù)結(jié)構(gòu)。ContentionList是一個(gè)后進(jìn)先出(LIFO)的隊(duì)列,每次新加入Node時(shí)都會(huì)在隊(duì)頭進(jìn)行,通過(guò)CAS改變第一個(gè)節(jié)點(diǎn)的的指針為新增節(jié)點(diǎn),同時(shí)設(shè)置新增節(jié)點(diǎn)的next指向后續(xù)節(jié)點(diǎn),而取得操作則發(fā)生在隊(duì)尾。顯然,該結(jié)構(gòu)其實(shí)是個(gè)Lock-Free(無(wú)鎖)的隊(duì)列。

因?yàn)橹挥蠴wner線程才能從隊(duì)尾取元素,也即線程出列操作無(wú)爭(zhēng)用,當(dāng)然也就避免了CAS的ABA問(wèn)題。

1.2 EntryList

EntryList與ContentionList邏輯上同屬等待隊(duì)列,ContentionList會(huì)被線程并發(fā)訪問(wèn),為了降低對(duì)ContentionList隊(duì)尾的爭(zhēng)用,而建立EntryList。 Owner線程在unlock時(shí)會(huì)從ContentionList中遷移線程到EntryList,并會(huì)指定EntryList中的某個(gè)線程(一般為Head)為Ready(OnDeck)線程。Owner線程并不是把鎖傳遞給OnDeck線程,只是把競(jìng)爭(zhēng)鎖的權(quán)利交給OnDeck,OnDeck線程需要重新競(jìng)爭(zhēng)鎖。這樣做雖然犧牲了一定的公平性,但極大的提高了整體吞吐量,在Hotspot中把OnDeck的選擇行為稱之為“競(jìng)爭(zhēng)切換”。

OnDeck線程獲得鎖后即變?yōu)閛wner線程,無(wú)法獲得鎖則會(huì)依然留在EntryList中,考慮到公平性,在EntryList中的位置不發(fā)生變化(依然在隊(duì)頭)。如果Owner線程被wait方法阻塞,則轉(zhuǎn)移到WaitSet隊(duì)列;如果在某個(gè)時(shí)刻被notify/notifyAll喚醒,則再次轉(zhuǎn)移到EntryList。

2、自旋鎖

那些處于ContetionList、EntryList、WaitSet中的線程均處于阻塞狀態(tài),阻塞操作由操作系統(tǒng)完成(在Linxu下通過(guò)pthread_mutex_lock函數(shù))。線程被阻塞后便進(jìn)入內(nèi)核(Linux)調(diào)度狀態(tài),這個(gè)會(huì)導(dǎo)致系統(tǒng)在用戶態(tài)與內(nèi)核態(tài)之間來(lái)回切換,嚴(yán)重影響鎖的性能。

緩解上述問(wèn)題的辦法便是自旋,其原理是:當(dāng)發(fā)生爭(zhēng)用時(shí),若Owner線程能在很短的時(shí)間內(nèi)釋放鎖, 則那些正在爭(zhēng)用線程可以稍微等一等(自旋),在Owner線程釋放鎖后,爭(zhēng)用線程可能會(huì)立即得到鎖,從而避免了系統(tǒng)阻塞。但Owner運(yùn)行的時(shí)間可能會(huì)超出了臨界值,爭(zhēng)用線程自旋一段時(shí)間后還是無(wú)法獲得鎖,這時(shí)爭(zhēng)用線程則會(huì)停止自旋進(jìn)入阻塞狀態(tài)(后退)?;舅悸肪褪亲孕怀晒υ僮枞?,盡量降低阻塞的可能性,這對(duì)那些執(zhí)行時(shí)間很短的代碼塊來(lái)說(shuō)有非常重要的性能提高。 自旋鎖有個(gè)更貼切的名字:自旋-指數(shù)后退鎖,也即復(fù)合鎖。很顯然,自旋在多處理器上才有意義。

還有個(gè)問(wèn)題是,線程自旋時(shí)做些啥?其實(shí)啥都不做,可以執(zhí)行幾次for循環(huán),可以執(zhí)行幾條空的匯編指令,目的是占著CPU不放,等待獲取鎖的機(jī)會(huì)。所以說(shuō),自旋是把雙刃劍,如果旋的時(shí)間過(guò)長(zhǎng)會(huì)影響整體性能,時(shí)間過(guò)短又達(dá)不到延遲阻塞的目的。顯然,自旋的周期選擇顯得非常重要,但這與操作系統(tǒng)、硬件體系、系統(tǒng)的負(fù)載等諸多場(chǎng)景相關(guān),很難選擇,如果選擇不當(dāng),不但性能得不到提高,可能還會(huì)下降,因此大家普遍認(rèn)為自旋鎖不具有擴(kuò)展性。

對(duì)自旋鎖周期的選擇上,HotSpot認(rèn)為最佳時(shí)間應(yīng)是一個(gè)線程上下文切換的時(shí)間,但目前并沒(méi)有做到。經(jīng)過(guò)調(diào)查,目前只是通過(guò)匯編暫停了幾個(gè)CPU周期,除了自旋周期選擇,HotSpot還進(jìn)行許多其他的自旋優(yōu)化策略,具體如下:

* 如果平均負(fù)載小于CPUs則一直自旋

* 如果有超過(guò)(CPUs/2)個(gè)線程正在自旋,則后來(lái)線程直接阻塞

* 如果正在自旋的線程發(fā)現(xiàn)Owner發(fā)生了變化則延遲自旋時(shí)間(自旋計(jì)數(shù))或進(jìn)入阻塞

* 如果CPU處于節(jié)電模式則停止自旋

* 自旋時(shí)間的最壞情況是CPU的存儲(chǔ)延遲(CPU A存儲(chǔ)了一個(gè)數(shù)據(jù),到CPU B得知這個(gè)數(shù)據(jù)直接的時(shí)間差)

* 自旋時(shí)會(huì)適當(dāng)放棄線程優(yōu)先級(jí)之間的差異

那synchronized實(shí)現(xiàn)何時(shí)使用了自旋鎖? 答案是在線程進(jìn)入ContentionList時(shí),也即第一步操作前。線程在進(jìn)入等待隊(duì)列時(shí)首先進(jìn)行自旋嘗試獲得鎖,如果不成功再進(jìn)入等待隊(duì)列。這對(duì)那些已經(jīng)在等待隊(duì)列中的線程來(lái)說(shuō),稍微顯得不公平。還有一個(gè)不公平的地方是自旋線程可能會(huì)搶占了Ready線程的鎖。自旋鎖由每個(gè)監(jiān)視對(duì)象維護(hù),每個(gè)監(jiān)視對(duì)象一個(gè)。

3、偏向鎖

在JVM1.6中引入了偏向鎖,偏向鎖主要解決無(wú)競(jìng)爭(zhēng)下的鎖性能問(wèn)題, 首先我們看下無(wú)競(jìng)爭(zhēng)下鎖存在什么問(wèn)題:

現(xiàn)在幾乎所有的鎖都是可重入的,也即已經(jīng)獲得鎖的線程可以多次鎖住/解鎖監(jiān)視對(duì)象,按照之前的HotSpot設(shè)計(jì),每次加鎖/解鎖都會(huì)涉及到一些CAS操作(比如對(duì)等待隊(duì)列的CAS操作),CAS操作會(huì)延遲本地調(diào)用,因此偏向鎖的想法是一旦線程第一次獲得了監(jiān)視對(duì)象,之后讓監(jiān)視對(duì)象“偏向”這個(gè)線程,之后的多次調(diào)用則可以避免CAS操作,說(shuō)白了就是置個(gè)變量,如果發(fā)現(xiàn)為true則無(wú)需再走各種加鎖/解鎖流程。 但還有很多概念需要解釋、很多引入的問(wèn)題需要解決:

3.1 CAS及SMP架構(gòu)

CAS為什么會(huì)引入本地延遲?這要從SMP(對(duì)稱多處理器)架構(gòu)說(shuō)起

其意思是所有的CPU會(huì)共享一條系統(tǒng)總線(BUS),靠此總線連接主存。每個(gè)核都有自己的一級(jí)緩存,各核相對(duì)于BUS對(duì)稱分布,因此這種結(jié)構(gòu)稱為“對(duì)稱多處理器”。

而CAS的全稱為Compare-And-Swap,是一條CPU的原子指令,其作用是讓CPU比較后原子地更新某個(gè)位置的值,經(jīng)過(guò)調(diào)查發(fā)現(xiàn),其實(shí)現(xiàn)方式是基于硬件平臺(tái)的匯編指令,就是說(shuō)CAS是靠硬件實(shí)現(xiàn)的,JVM只是封裝了匯編調(diào)用,那些AtomicInteger類便是使用了這些封裝后的接口。

Core1和Core2可能會(huì)同時(shí)把主存中某個(gè)位置的值Load到自己的L1 Cache中,當(dāng)Core1在自己的L1 Cache中修改這個(gè)位置的值時(shí),會(huì)通過(guò)總線,使Core2中L1 Cache對(duì)應(yīng)的值“失效”,而Core2一旦發(fā)現(xiàn)自己L1 Cache中的值失效(稱為Cache命中缺失)則會(huì)通過(guò)總線從內(nèi)存中加載該地址最新的值,大家通過(guò)總線的來(lái)回通信稱為“Cache一致性流量”,因?yàn)榭偩€被設(shè)計(jì)為固定的“通信能力”,如果Cache一致性流量過(guò)大,總線將成為瓶頸。而當(dāng)Core1和Core2中的值再次一致時(shí),稱為“Cache一致性”,從這個(gè)層面來(lái)說(shuō),鎖設(shè)計(jì)的終極目標(biāo)便是減少Cache一致性流量。

而CAS恰好會(huì)導(dǎo)致Cache一致性流量,如果有很多線程都共享同一個(gè)對(duì)象,當(dāng)某個(gè)Core CAS成功時(shí)必然會(huì)引起總線風(fēng)暴,這就是所謂的本地延遲,本質(zhì)上偏向鎖就是為了消除CAS,降低Cache一致性流量。

3.2 偏向解除

偏向鎖引入的一個(gè)重要問(wèn)題是,在多爭(zhēng)用的場(chǎng)景下,如果另外一個(gè)線程爭(zhēng)用偏向?qū)ο?,擁有者需要釋放偏向鎖,而釋放的過(guò)程會(huì)帶來(lái)一些性能開(kāi)銷,但總體說(shuō)來(lái)偏向鎖帶來(lái)的好處還是大于CAS代價(jià)的。

4、總結(jié)

關(guān)于鎖,JVM中還引入了一些其他技術(shù)比如鎖膨脹等,這些與自旋鎖、偏向鎖相比影響不是很大,這里就不做介紹。

通過(guò)上面的介紹可以看出,synchronized的底層實(shí)現(xiàn)主要依靠Lock-Free的隊(duì)列,基本思路是自旋后阻塞,競(jìng)爭(zhēng)切換后繼續(xù)競(jìng)爭(zhēng)鎖,稍微犧牲了公平性,但獲得了高吞吐量。

本文版權(quán)歸黑馬程序員JavaEE學(xué)院所有,歡迎轉(zhuǎn)載,轉(zhuǎn)載請(qǐng)注明作者出處。謝謝!

作者:黑馬程序員JavaEE培訓(xùn)學(xué)院

首發(fā):http://java.itheima.com/

分享到:
在線咨詢 我要報(bào)名
和我們?cè)诰€交談!