1、重量級(jí)鎖

內(nèi)置鎖是JVM提供的最便捷的線(xiàn)程同步工具，利用synchronized關(guān)鍵字來(lái)修飾同步代碼塊，我們稱(chēng)這種鎖為java的內(nèi)置鎖（intrinsic lock）或者監(jiān)視器鎖（monitor lock）。

1.1 監(jiān)視器模型

首先要明確的一點(diǎn)是，監(jiān)視器模型不是Java特有的，它是操作系統(tǒng)層次的概念，是為了實(shí)現(xiàn)線(xiàn)程同步而采取的技術(shù)手段，任何編程語(yǔ)言的并發(fā)設(shè)計(jì)中都可以出現(xiàn)這個(gè)概念。

JVM會(huì)為每個(gè)對(duì)象分配一個(gè)monitor，而同時(shí)只能有一個(gè)線(xiàn)程可以獲得該對(duì)象monitor的所有權(quán)。在線(xiàn)程進(jìn)入時(shí)通過(guò)monitorenter嘗試取得對(duì)象monitor所有權(quán)，退出時(shí)通過(guò)monitorexit釋放對(duì)象monitor所有權(quán)。
monitorenter與monitorexit在編譯后對(duì)稱(chēng)插入代碼。

• monitorenter: 被插入到同步代碼塊之前。
• monitorexit: 被插到同步代碼塊之后或異常處。

監(jiān)視器可以看做是經(jīng)過(guò)特殊布置的建筑，這個(gè)建筑有一個(gè)特殊的房間，該房間通常包含一些數(shù)據(jù)和代碼，但是一次只能一個(gè)消費(fèi)者使用此房間。

1.png

當(dāng)一個(gè)消費(fèi)者(線(xiàn)程)使用了這個(gè)房間，首先他必須到一個(gè)大廳(Entry Set)等待，調(diào)度程序?qū)⒒谀承?biāo)準(zhǔn)(e.g. FIFO)將從大廳中選擇一個(gè)消費(fèi)者(線(xiàn)程)，進(jìn)入特殊房間，如果這個(gè)線(xiàn)程因?yàn)槟承┰虮弧皰炱稹?，它將被調(diào)度程序安排到“等待房間”，并且一段時(shí)間之后會(huì)被重新分配到特殊房間，按照上面的線(xiàn)路，這個(gè)建筑物包含三個(gè)房間，分別是“特殊房間”、“大廳”以及“等待房間”。

2.png

簡(jiǎn)單來(lái)說(shuō)，監(jiān)視器用來(lái)監(jiān)視線(xiàn)程進(jìn)入這個(gè)特別房間，它確保同一時(shí)間只能有一個(gè)線(xiàn)程可以訪(fǎng)問(wèn)特殊房間中的數(shù)據(jù)和代碼。

那么，鎖和監(jiān)視器有什么區(qū)別？

一言以蔽之，鎖為實(shí)現(xiàn)監(jiān)視器提供必要的支持的，監(jiān)視器是比鎖更高層次的抽象。

鎖是存在于對(duì)象內(nèi)部的數(shù)據(jù)結(jié)構(gòu)，監(jiān)視器是一個(gè)獨(dú)立的結(jié)構(gòu)，但是和對(duì)象關(guān)聯(lián)。另外，監(jiān)視器是操控線(xiàn)程的，它會(huì)維持一個(gè)代碼數(shù)據(jù)區(qū)和線(xiàn)程隊(duì)列等，保證同一時(shí)刻只有一個(gè)線(xiàn)程訪(fǎng)問(wèn)代碼數(shù)據(jù)區(qū)。

1.2 重量級(jí)鎖的局限性

java的線(xiàn)程是映射到操作系統(tǒng)原生線(xiàn)程之上的，如果要阻塞或喚醒一個(gè)線(xiàn)程就需要操作系統(tǒng)介入，需要在戶(hù)態(tài)與核心態(tài)之間切換，這種切換會(huì)消耗大量的系統(tǒng)資源，因?yàn)橛脩?hù)態(tài)與內(nèi)核態(tài)都有各自專(zhuān)用的內(nèi)存空間，專(zhuān)用的寄存器等，用戶(hù)態(tài)切換至內(nèi)核態(tài)需要傳遞給許多變量、參數(shù)給內(nèi)核，內(nèi)核也需要保護(hù)好用戶(hù)態(tài)在切換時(shí)的一些寄存器值、變量等，以便內(nèi)核態(tài)調(diào)用結(jié)束后切換回用戶(hù)態(tài)繼續(xù)工作。

如果線(xiàn)程狀態(tài)切換是一個(gè)高頻操作時(shí)，這將會(huì)消耗很多CPU處理時(shí)間；此外，獲取鎖掛起操作消耗的時(shí)間往往比用戶(hù)代碼執(zhí)行的時(shí)間還要長(zhǎng)，這種同步策略顯然非常糟糕的。

synchronized會(huì)導(dǎo)致?tīng)?zhēng)用不到鎖的線(xiàn)程進(jìn)入阻塞狀態(tài)，所以被稱(chēng)為“重量級(jí)鎖”。

jvm的研究人員在花費(fèi)了大量的精力去實(shí)現(xiàn)各種鎖優(yōu)化技術(shù)，如適應(yīng)性自旋（Adaptive Spinning）、鎖削除（Lock Elimination）、鎖粗化（Lock Coarsening）、輕量級(jí)鎖（Lightweight Locking）、偏向鎖（Biased Locking）等，這些技術(shù)都是為了在線(xiàn)程之間更高效地共享數(shù)據(jù)，以及解決競(jìng)爭(zhēng)問(wèn)題，從而提高程序的執(zhí)行效率。

2、自旋鎖

2.1 實(shí)現(xiàn)原理

重量級(jí)鎖的成本非常高，而且不容易優(yōu)化。同時(shí)，虛擬機(jī)的開(kāi)發(fā)團(tuán)隊(duì)也注意到在許多應(yīng)用上，共享數(shù)據(jù)的鎖定狀態(tài)只會(huì)持續(xù)很短的一段時(shí)間，為了這段時(shí)間去掛起和恢復(fù)線(xiàn)程并不值得。如果物理機(jī)器有一個(gè)以上的處理器，能讓兩個(gè)或以上的線(xiàn)程同時(shí)并行執(zhí)行，我們就可以讓后面請(qǐng)求鎖的那個(gè)線(xiàn)程“稍等一會(huì)”，但不放棄處理器的執(zhí)行時(shí)間，看看持有鎖的線(xiàn)程是否很快就會(huì)釋放鎖。為了讓線(xiàn)程等待，我們只須讓線(xiàn)程執(zhí)行一個(gè)忙循環(huán)（自旋），這項(xiàng)技術(shù)就是所謂的自旋鎖。

那么，對(duì)于競(jìng)爭(zhēng)這些鎖的而言，因?yàn)殒i阻塞造成線(xiàn)程切換的時(shí)間與鎖持有的時(shí)間相當(dāng)，減少線(xiàn)程阻塞造成的線(xiàn)程切換，能得到較大的性能提升。具體如下：

• 當(dāng)前線(xiàn)程競(jìng)爭(zhēng)鎖失敗時(shí)，打算阻塞自己
• 不直接阻塞自己，而是自旋（空等待，比如一個(gè)空的有限for循環(huán)）一會(huì)
• 在自旋的同時(shí)重新競(jìng)爭(zhēng)鎖
• 如果自旋結(jié)束前獲得了鎖，那么鎖獲取成功；否則，自旋結(jié)束后阻塞自己

如果在自旋的時(shí)間內(nèi)，鎖就被舊owner釋放了，那么當(dāng)前線(xiàn)程就不需要阻塞自己（也不需要在未來(lái)鎖釋放時(shí)恢復(fù)），減少了一次線(xiàn)程切換。

“鎖的持有時(shí)間比較短”這一條件可以放寬。實(shí)際上，只要鎖競(jìng)爭(zhēng)的時(shí)間比較短（比如線(xiàn)程1快釋放鎖的時(shí)候，線(xiàn)程2才會(huì)來(lái)競(jìng)爭(zhēng)鎖），就能夠提高自旋獲得鎖的概率。這通常發(fā)生在鎖持有時(shí)間長(zhǎng)，但競(jìng)爭(zhēng)不激烈的場(chǎng)景中。

2.2 自適應(yīng)自旋

自旋鎖在JDK 1.4.2中就已經(jīng)引入，只不過(guò)默認(rèn)是關(guān)閉的，可以使用-XX:+UseSpinning參數(shù)來(lái)開(kāi)啟，在JDK 1.6中就已經(jīng)改為默認(rèn)開(kāi)啟了。

但是，自旋等待不能代替阻塞。

首先，單核處理器上，不存在實(shí)際的并行，當(dāng)前線(xiàn)程不阻塞自己的話(huà)，舊owner就不能執(zhí)行，鎖永遠(yuǎn)不會(huì)釋放，此時(shí)不管自旋多久都是浪費(fèi)；進(jìn)而，如果線(xiàn)程多而處理器少，自旋也會(huì)造成不少無(wú)謂的浪費(fèi)。

其次，自旋鎖要占用CPU，如果是計(jì)算密集型任務(wù)，這一優(yōu)化通常得不償失，減少鎖的使用是更好的選擇。

如果鎖競(jìng)爭(zhēng)的時(shí)間比較長(zhǎng)，那么自旋通常不能獲得鎖，白白浪費(fèi)了自旋占用的CPU時(shí)間。因此自旋等待的時(shí)間必須要有一定的限度，如果自旋超過(guò)了限定的次數(shù)仍然沒(méi)有成功獲得鎖，就應(yīng)當(dāng)使用傳統(tǒng)的方式去掛起線(xiàn)程了。自旋次數(shù)的默認(rèn)值是10次，用戶(hù)可以使用參數(shù)-XX:PreBlockSpin來(lái)更改（JDK1.7后，去掉此參數(shù)，由jvm控制）；

在JDK 1.6中引入了自適應(yīng)的自旋鎖。自適應(yīng)意味著自旋的時(shí)間不再固定了，而是由前一次在同一個(gè)鎖上的自旋時(shí)間及鎖的擁有者的狀態(tài)來(lái)決定。如果在同一個(gè)鎖對(duì)象上，自旋等待剛剛成功獲得過(guò)鎖，并且持有鎖的線(xiàn)程正在運(yùn)行中，那么虛擬機(jī)就會(huì)認(rèn)為這次自旋也很有可能再次成功，進(jìn)而它將允許自旋等待持續(xù)相對(duì)更長(zhǎng)的時(shí)間，比如100個(gè)循環(huán)。另一方面，如果對(duì)于某個(gè)鎖，自旋很少成功獲得過(guò)，那在以后要獲取這個(gè)鎖時(shí)將可能省略掉自旋過(guò)程，以避免浪費(fèi)處理器資源。

然而，自適應(yīng)自旋也沒(méi)能徹底解決該問(wèn)題，如果默認(rèn)的自旋次數(shù)設(shè)置不合理（過(guò)高或過(guò)低），那么自適應(yīng)的過(guò)程將很難收斂到合適的值。

3、輕量級(jí)鎖

自旋鎖的目標(biāo)是降低線(xiàn)程切換的成本。如果鎖競(jìng)爭(zhēng)激烈，我們不得不依賴(lài)于重量級(jí)鎖，讓競(jìng)爭(zhēng)失敗的線(xiàn)程阻塞；如果完全沒(méi)有實(shí)際的鎖競(jìng)爭(zhēng)，那么申請(qǐng)重量級(jí)鎖都是浪費(fèi)的。輕量級(jí)鎖的目標(biāo)是，減少無(wú)實(shí)際競(jìng)爭(zhēng)情況下，使用重量級(jí)鎖產(chǎn)生的性能消耗，包括系統(tǒng)調(diào)用引起的內(nèi)核態(tài)與用戶(hù)態(tài)切換、線(xiàn)程阻塞造成的線(xiàn)程切換等。

顧名思義，輕量級(jí)鎖是相對(duì)于重量級(jí)鎖而言的。使用輕量級(jí)鎖時(shí)，不需要申請(qǐng)互斥量，僅僅將Mark Word中的部分字節(jié)CAS更新指向線(xiàn)程棧中的Lock Record，如果更新成功，則輕量級(jí)鎖獲取成功，記錄鎖狀態(tài)為輕量級(jí)鎖；否則，說(shuō)明已經(jīng)有線(xiàn)程獲得了輕量級(jí)鎖，目前發(fā)生了鎖競(jìng)爭(zhēng)（不適合繼續(xù)使用輕量級(jí)鎖），接下來(lái)膨脹為重量級(jí)鎖。

當(dāng)然，由于輕量級(jí)鎖天然瞄準(zhǔn)不存在鎖競(jìng)爭(zhēng)的場(chǎng)景，如果存在鎖競(jìng)爭(zhēng)但不激烈，仍然可以用自旋鎖優(yōu)化，自旋失敗后再膨脹為重量級(jí)鎖。

4、偏向鎖

在沒(méi)有實(shí)際競(jìng)爭(zhēng)的情況下，還能夠針對(duì)部分場(chǎng)景繼續(xù)優(yōu)化。如果不僅僅沒(méi)有實(shí)際競(jìng)爭(zhēng)，自始至終，使用鎖的線(xiàn)程都只有一個(gè)，那么，維護(hù)輕量級(jí)鎖都是浪費(fèi)的。偏向鎖的目標(biāo)是，減少無(wú)競(jìng)爭(zhēng)且只有一個(gè)線(xiàn)程使用鎖的情況下，使用輕量級(jí)鎖產(chǎn)生的性能消耗。輕量級(jí)鎖每次申請(qǐng)、釋放鎖都至少需要一次CAS，但偏向鎖只有初始化時(shí)需要一次CAS。

“偏向”的意思是，偏向鎖假定將來(lái)只有第一個(gè)申請(qǐng)鎖的線(xiàn)程會(huì)使用鎖（不會(huì)有任何線(xiàn)程再來(lái)申請(qǐng)鎖），因此，只需要在Mark Word中CAS記錄owner（本質(zhì)上也是更新，但初始值為空），如果記錄成功，則偏向鎖獲取成功，記錄鎖狀態(tài)為偏向鎖，以后當(dāng)前線(xiàn)程等于owner就可以零成本的直接獲得鎖；否則，說(shuō)明有其他線(xiàn)程競(jìng)爭(zhēng)，膨脹為輕量級(jí)鎖。需要注意的是，撤銷(xiāo)偏向鎖的時(shí)候會(huì)會(huì)導(dǎo)致進(jìn)入安全點(diǎn)，安全點(diǎn)會(huì)導(dǎo)致STW，導(dǎo)致性能下降。

偏向鎖無(wú)法使用自旋鎖優(yōu)化，因?yàn)橐坏┯衅渌€(xiàn)程申請(qǐng)鎖，就破壞了偏向鎖的假定。

偏向鎖可以提高帶有同步但無(wú)競(jìng)爭(zhēng)的程序性能，但是它并不一定總是對(duì)程序運(yùn)行有利，如果程序中大多數(shù)的鎖都總是被多個(gè)不同的線(xiàn)程訪(fǎng)問(wèn)，那偏向模式就是多余的。在具體問(wèn)題具體分析的前提下，有時(shí)候使用參數(shù)-XX:-UseBiasedLocking來(lái)禁止偏向鎖優(yōu)化反而可以提升性能。

5、鎖剔除與鎖粗化

鎖削除是指虛擬機(jī)即時(shí)編譯器在運(yùn)行時(shí)，對(duì)一些代碼上要求同步，但是被檢測(cè)到不可能存在共享數(shù)據(jù)競(jìng)爭(zhēng)的鎖進(jìn)行削除。鎖削除的主要判定依據(jù)來(lái)源于逃逸分析的數(shù)據(jù)支持，如果判斷到一段代碼中，在堆上的所有數(shù)據(jù)都不會(huì)逃逸出去被其他線(xiàn)程訪(fǎng)問(wèn)到，那就可以把它們當(dāng)作棧上數(shù)據(jù)對(duì)待，認(rèn)為它們是線(xiàn)程私有的，同步加鎖自然就無(wú)須進(jìn)行。

但是程序員自己應(yīng)該是很清楚的，怎么會(huì)在明知道不存在數(shù)據(jù)爭(zhēng)用的情況下要求同步呢？答案是有許多同步措施并不是程序員自己加入的，同步的代碼在Java程序中的普遍程度也許超過(guò)了我們的想象。

我們來(lái)看看下面的例子，這段非常簡(jiǎn)單的代碼僅僅是輸出三個(gè)字符串相加的結(jié)果，無(wú)論是源碼字面上還是程序語(yǔ)義上都沒(méi)有同步。

    public String concatString(String s1, String s2, String s3) {

        return s1 + s2 + s3;

    }

我們也知道，由于String是一個(gè)不可變的類(lèi)，對(duì)字符串的連接操作總是通過(guò)生成新的String對(duì)象來(lái)進(jìn)行的，因此Javac編譯器會(huì)對(duì)String連接做自動(dòng)優(yōu)化。在JDK 1.5之前，會(huì)轉(zhuǎn)化為StringBuffer對(duì)象的連續(xù)append()操作，在JDK 1.5及以后的版本中，會(huì)轉(zhuǎn)化為StringBuilder對(duì)象的連續(xù)append()操作。

    public String concatString(String s1, String s2, String s3) {
        StringBuffer sb = new StringBuffer();
        sb.append(s1);
        sb.append(s2);
        sb.append(s3);
        return sb.toString();
    }

現(xiàn)在大家還認(rèn)為這段代碼沒(méi)有涉及同步嗎？每個(gè)StringBuffer.append()方法中都有一個(gè)同步塊，鎖就是sb對(duì)象。虛擬機(jī)觀(guān)察變量sb，很快就會(huì)發(fā)現(xiàn)它的動(dòng)態(tài)作用域被限制在concatString()方法內(nèi)部。也就是sb的所有引用永遠(yuǎn)不會(huì)“逃逸”到concatString()方法之外，其他線(xiàn)程無(wú)法訪(fǎng)問(wèn)到它，所以這里雖然有鎖，但是可以被安全地削除掉，在即時(shí)編譯之后，這段代碼就會(huì)忽略掉所有的同步而直接執(zhí)行了。

原則上，我們?cè)诰帉?xiě)代碼的時(shí)候，總是推薦將同步塊的作用范圍限制得盡量小——只在共享數(shù)據(jù)的實(shí)際作用域中才進(jìn)行同步，這樣是為了使得需要同步的操作數(shù)量盡可能變小，如果存在鎖競(jìng)爭(zhēng)，那等待鎖的線(xiàn)程也能盡快地拿到鎖。

大部分情況下，上面的原則都是正確的，但是如果一系列的連續(xù)操作都對(duì)同一個(gè)對(duì)象反復(fù)加鎖和解鎖，甚至加鎖操作是出現(xiàn)在循環(huán)體中的，那即使沒(méi)有線(xiàn)程競(jìng)爭(zhēng)，頻繁地進(jìn)行互斥同步操作也會(huì)導(dǎo)致不必要的性能損耗。

上面代碼中連續(xù)的append()方法就屬于這類(lèi)情況。如果虛擬機(jī)探測(cè)到有這樣一串零碎的操作都對(duì)同一個(gè)對(duì)象加鎖，將會(huì)把加鎖同步的范圍擴(kuò)展到整個(gè)操作序列的外部，就是擴(kuò)展到第一個(gè)append()操作之前直至最后一個(gè)append()操作之后，這樣只需要加鎖一次就可以了。即為鎖粗化。

6、鎖的分配和膨脹過(guò)程

6.1 對(duì)象頭

鎖的實(shí)現(xiàn)與對(duì)象頭密切相關(guān)。

HotSpot虛擬機(jī)中，對(duì)象在內(nèi)存中存儲(chǔ)的布局可以分為三塊區(qū)域：

• 對(duì)象頭（Header）
• 實(shí)例數(shù)據(jù)（Instance Data）
• 對(duì)齊填充（Padding）

HotSpot虛擬機(jī)的對(duì)象頭包括兩部分信息。

第一部分用于存儲(chǔ)對(duì)象自身的運(yùn)行時(shí)數(shù)據(jù)， 如哈希碼（HashCode）、GC分代年齡、鎖狀態(tài)標(biāo)志、線(xiàn)程持有的鎖、偏向線(xiàn)程ID、偏向時(shí)間戳等等，這部分?jǐn)?shù)據(jù)的長(zhǎng)度在32位和64位的虛擬機(jī)（暫不考慮開(kāi)啟壓縮指針的場(chǎng)景）中分別為32個(gè)和64個(gè)Bits，官方稱(chēng)它為“Mark Word”。

對(duì)象需要存儲(chǔ)的運(yùn)行時(shí)數(shù)據(jù)很多，其實(shí)已經(jīng)超出了32、64位Bitmap結(jié)構(gòu)所能記錄的限度，但是對(duì)象頭信息是與對(duì)象自身定義的數(shù)據(jù)無(wú)關(guān)的額外存儲(chǔ)成本，考慮到虛擬機(jī)的空間效率，Mark Word被設(shè)計(jì)成一個(gè)非固定的數(shù)據(jù)結(jié)構(gòu)以便在極小的空間內(nèi)存儲(chǔ)盡量多的信息，它會(huì)根據(jù)對(duì)象的狀態(tài)復(fù)用自己的存儲(chǔ)空間。例如在32位的HotSpot虛擬機(jī) 中對(duì)象未被鎖定的狀態(tài)下，Mark Word的32個(gè)Bits空間中的25Bits用于存儲(chǔ)對(duì)象哈希碼（HashCode），4Bits用于存儲(chǔ)對(duì)象分代年齡，2Bits用于存儲(chǔ)鎖標(biāo)志 位，1Bit固定為0，在其他狀態(tài)（輕量級(jí)鎖定、重量級(jí)鎖定、GC標(biāo)記、可偏向）下對(duì)象的存儲(chǔ)內(nèi)容如下表所示。

3.png

對(duì)象頭的另外一部分是類(lèi)型指針，即是對(duì)象指向它的類(lèi)的元數(shù)據(jù)的指針，虛擬機(jī)通過(guò)這個(gè)指針來(lái)確定這個(gè)對(duì)象是哪個(gè)類(lèi)的實(shí)例。并不是所有的虛擬機(jī)實(shí)現(xiàn)都必須在對(duì)象數(shù)據(jù)上保留類(lèi)型指針，換句話(huà)說(shuō)查找對(duì)象的元數(shù)據(jù)信息并不一定要經(jīng)過(guò)對(duì)象本身。另外，如果對(duì)象是一個(gè)Java數(shù)組，那在對(duì)象頭中還必須有一塊用于記錄數(shù)組長(zhǎng)度的數(shù)據(jù)，因?yàn)樘摂M機(jī)可以通過(guò)普通Java對(duì)象的元數(shù)據(jù)信息確定Java對(duì)象的大小，但是從數(shù)組的元數(shù)據(jù)中無(wú)法確定數(shù)組的大小。

這里要特別關(guān)注的是鎖標(biāo)志位，鎖標(biāo)志位與是否偏向鎖對(duì)應(yīng)到唯一的鎖狀態(tài)。

鎖的狀態(tài)總共有四種：

• 無(wú)鎖狀態(tài)
• 偏向鎖
• 輕量級(jí)鎖
• 重量級(jí)鎖

隨著鎖的競(jìng)爭(zhēng)，鎖可以從偏向鎖升級(jí)到輕量級(jí)鎖，再升級(jí)的重量級(jí)鎖，但是鎖的升級(jí)是單向的，也就是說(shuō)只能從低到高升級(jí)，不會(huì)出現(xiàn)鎖的降級(jí)。

6.2 偏向鎖實(shí)現(xiàn)原理

偏向鎖獲取過(guò)程：

• 訪(fǎng)問(wèn)Mark Word中偏向鎖的標(biāo)識(shí)是否設(shè)置成1，鎖標(biāo)志位是否為01——確認(rèn)為可偏向狀態(tài)。
• 如果為可偏向狀態(tài)，則測(cè)試線(xiàn)程ID是否指向當(dāng)前線(xiàn)程，如果是，進(jìn)入步驟（5），否則進(jìn)入步驟（3）。
• 如果線(xiàn)程ID并未指向當(dāng)前線(xiàn)程，則通過(guò)CAS操作競(jìng)爭(zhēng)鎖。如果競(jìng)爭(zhēng)成功，則將Mark Word中線(xiàn)程ID設(shè)置為當(dāng)前線(xiàn)程ID，然后執(zhí)行（5）；如果競(jìng)爭(zhēng)失敗，執(zhí)行（4）。
• 如果CAS獲取偏向鎖失敗，則表示有競(jìng)爭(zhēng)。當(dāng)?shù)竭_(dá)全局安全點(diǎn)（safepoint）時(shí)獲得偏向鎖的線(xiàn)程被掛起，偏向鎖升級(jí)為輕量級(jí)鎖，然后被阻塞在安全點(diǎn)的線(xiàn)程繼續(xù)往下執(zhí)行同步代碼。
• 執(zhí)行同步代碼。

偏向鎖的撤銷(xiāo)在上述第四步驟中有提到。偏向鎖只有遇到其他線(xiàn)程嘗試競(jìng)爭(zhēng)偏向鎖時(shí)，持有偏向鎖的線(xiàn)程才會(huì)釋放鎖，線(xiàn)程不會(huì)主動(dòng)去釋放偏向鎖。偏向鎖的撤銷(xiāo)，需要等待全局安全點(diǎn)（在這個(gè)時(shí)間點(diǎn)上沒(méi)有字節(jié)碼正在執(zhí)行），它會(huì)首先暫停擁有偏向鎖的線(xiàn)程，判斷鎖對(duì)象是否處于被鎖定狀態(tài)，撤銷(xiāo)偏向鎖后恢復(fù)到未鎖定（標(biāo)志位為“01”）或輕量級(jí)鎖（標(biāo)志位為“00”）的狀態(tài)。

6.3 輕量級(jí)鎖實(shí)現(xiàn)原理

輕量級(jí)鎖獲取過(guò)程：

• 在代碼進(jìn)入同步塊的時(shí)候，如果同步對(duì)象鎖狀態(tài)為無(wú)鎖狀態(tài)（鎖標(biāo)志位為“01”狀態(tài)，是否為偏向鎖為“0”），虛擬機(jī)首先將在當(dāng)前線(xiàn)程的棧幀中建立一個(gè)名為鎖記錄（Lock Record）的空間，用于存儲(chǔ)鎖對(duì)象目前的Mark Word的拷貝，官方稱(chēng)之為 Displaced Mark Word。這時(shí)候線(xiàn)程堆棧與對(duì)象頭的狀態(tài)如下圖所示。

4.png

• 拷貝對(duì)象頭中的Mark Word復(fù)制到鎖記錄中。

• 拷貝成功后，虛擬機(jī)將使用CAS操作嘗試將對(duì)象的Mark Word更新為指向Lock Record的指針，并將Lock record里的owner指針指向object mark word。如果更新成功，則執(zhí)行步驟（4），否則執(zhí)行步驟（5）。

• 如果這個(gè)更新動(dòng)作成功了，那么這個(gè)線(xiàn)程就擁有了該對(duì)象的鎖，并且對(duì)象Mark Word的鎖標(biāo)志位設(shè)置為“00”，即表示此對(duì)象處于輕量級(jí)鎖定狀態(tài)，這時(shí)候線(xiàn)程堆棧與對(duì)象頭的狀態(tài)如下圖所示。

5.png

• 如果這個(gè)更新操作失敗了，虛擬機(jī)首先會(huì)檢查對(duì)象的Mark Word是否指向當(dāng)前線(xiàn)程的棧幀，如果是就說(shuō)明當(dāng)前線(xiàn)程已經(jīng)擁有了這個(gè)對(duì)象的鎖，那就可以直接進(jìn)入同步塊繼續(xù)執(zhí)行。否則說(shuō)明多個(gè)線(xiàn)程競(jìng)爭(zhēng)鎖，輕量級(jí)鎖就要膨脹為重量級(jí)鎖，鎖標(biāo)志的狀態(tài)值變?yōu)椤?0”，Mark Word中存儲(chǔ)的就是指向重量級(jí)鎖（互斥量）的指針，后面等待鎖的線(xiàn)程也要進(jìn)入阻塞狀態(tài)。 而當(dāng)前線(xiàn)程便嘗試使用自旋來(lái)獲取鎖，自旋就是為了不讓線(xiàn)程阻塞，而采用循環(huán)去獲取鎖的過(guò)程。

上面描述的是輕量級(jí)鎖的加鎖過(guò)程，它的解鎖過(guò)程也是通過(guò)CAS操作來(lái)進(jìn)行的，如果對(duì)象的Mark Word仍然指向著線(xiàn)程的鎖記錄，那就用CAS操作把對(duì)象當(dāng)前的Mark Word和線(xiàn)程中復(fù)制的Displaced Mark Word替換回來(lái)，如果替換成功，整個(gè)同步過(guò)程就完成了。如果替換失敗，說(shuō)明有其他線(xiàn)程嘗試過(guò)獲取該鎖，那就要在釋放鎖的同時(shí)，喚醒被掛起的線(xiàn)程。

輕量級(jí)鎖能提升程序同步性能的依據(jù)是“對(duì)于絕大部分的鎖，在整個(gè)同步周期內(nèi)都是不存在競(jìng)爭(zhēng)的”，這是一個(gè)經(jīng)驗(yàn)數(shù)據(jù)。如果沒(méi)有競(jìng)爭(zhēng)，輕量級(jí)鎖使用CAS操作避免了使用互斥量的開(kāi)銷(xiāo)，但如果存在鎖競(jìng)爭(zhēng)，除了互斥量的開(kāi)銷(xiāo)外，還額外發(fā)生了CAS操作，因此在有競(jìng)爭(zhēng)的情況下，輕量級(jí)鎖會(huì)比傳統(tǒng)的重量級(jí)鎖更慢。

6.4 重量級(jí)鎖、輕量級(jí)鎖和偏向鎖之間轉(zhuǎn)換

詳細(xì)版：

6.png

簡(jiǎn)化版：

7.png