一、前言

在 多線程知識(shí)梳理(2) - synchronized 基本使用 中，我們介紹了使用重量鎖來(lái)實(shí)現(xiàn)的synchronized。今天，我們就來(lái)一起學(xué)習(xí)一下在JDK 1.6之后，對(duì)synchronized所采取的一系列優(yōu)化措施。

二、對(duì)象頭 & Monitor Record

在介紹優(yōu)化方法之前，我們需要介紹兩個(gè)重要的概念Java對(duì)象頭和Monitor：

2.1 對(duì)象頭

在 Java&Android 基礎(chǔ)知識(shí)梳理(3) - 內(nèi)存區(qū)域 中介紹內(nèi)存區(qū)域的時(shí)候，對(duì)于一個(gè)Java對(duì)象所占的內(nèi)存區(qū)域是這么介紹的：

2.2 Monitor Record

Monitor是線程私有的數(shù)據(jù)結(jié)構(gòu)，由于一個(gè)線程可能進(jìn)入多個(gè)不同的同步方法，這些方法有可能會(huì)關(guān)聯(lián)到不同的Monitor，因此每一個(gè)線程都有一個(gè)可用的Monitor列表，同時(shí)還有一個(gè)全局的可用列表，Monitor數(shù)據(jù)結(jié)構(gòu)包括以下成員變量：

• Owner：初始時(shí)為空表示當(dāng)前沒(méi)有任何線程擁有該Monitor，當(dāng)線程成功擁有該鎖后保存線程唯一標(biāo)識(shí)，當(dāng)鎖被釋放時(shí)又設(shè)置為空。
• EntryQ：關(guān)聯(lián)一個(gè)系統(tǒng)互斥鎖，阻塞所有試圖獲得Monitor但是最終失敗了的線程。
• RcThis：表示blocked或waiting在該Monitor上的所有線程的個(gè)數(shù)。
• Nest：用來(lái)實(shí)現(xiàn)重入鎖的計(jì)數(shù)。
• HashCode：保存從對(duì)象頭拷貝過(guò)來(lái)的HashCode值。
• Candidate：用來(lái)避免不必要的阻塞或等待線程喚醒，因?yàn)槊恳淮沃挥幸粋€(gè)線程能夠成功擁有鎖，如果每次前一個(gè)釋放鎖的線程喚醒所有正在阻塞或等待的線程，會(huì)引起不必要的上下文切換（從阻塞到就緒然后因?yàn)楦?jìng)爭(zhēng)鎖失敗又被阻塞）從而導(dǎo)致性能嚴(yán)重下降。Candidate只有兩種可能的值：0表示沒(méi)有需要喚醒的線程，1表示要喚醒一個(gè)繼任線程來(lái)競(jìng)爭(zhēng)鎖。

三、實(shí)現(xiàn)優(yōu)化

在JDK 1.6之后，它對(duì)于鎖進(jìn)行了一系列的優(yōu)化措施，主要包括：自適應(yīng)自旋鎖、鎖消除和鎖粗化。

3.1 自旋鎖

由于線程的阻塞和喚醒需要CPU從用戶態(tài)轉(zhuǎn)換成核心態(tài)，而頻繁的阻塞和喚醒對(duì)CPU來(lái)說(shuō)是一件負(fù)擔(dān)很重的工作。

因此，我們?cè)诎l(fā)現(xiàn)鎖已經(jīng)被其它線程占有時(shí)，并不直接讓當(dāng)前線程進(jìn)入阻塞狀態(tài)，而是讓線程執(zhí)行一段無(wú)意義的循環(huán)，待循環(huán)結(jié)束后，如何仍然無(wú)法獲取到鎖，那么才進(jìn)入阻塞狀態(tài)。

決定自旋鎖性能的關(guān)鍵在于自旋次數(shù)的選擇，在JDK 1.6之后，引入了自適應(yīng)自旋鎖，它會(huì)根據(jù)前一次在同一個(gè)鎖上的自旋時(shí)間及鎖的擁有者的狀態(tài)來(lái)決定新的自旋次數(shù)。

3.2 鎖消除

當(dāng)JVM檢測(cè)到不可能存在共享數(shù)據(jù)競(jìng)爭(zhēng)，會(huì)對(duì)同步鎖進(jìn)行鎖消除。

3.3 鎖粗化

在使用同步鎖的時(shí)候，需要讓同步塊的作用范圍盡可能地小，僅在共享數(shù)據(jù)的實(shí)際作用域中才進(jìn)行同步，這樣做的目的是為了使需要同步的操作數(shù)量盡可能縮小，如果存在鎖競(jìng)爭(zhēng)，那么等待鎖的線程也能盡快拿到鎖。

然而，如果一系列連續(xù)加鎖解鎖操作，可能會(huì)導(dǎo)致不必要的性能損耗，所以有時(shí)可以將多個(gè)連續(xù)的加鎖、解鎖操作連接在一起，擴(kuò)展成一個(gè)范圍更大的鎖。

四、狀態(tài)優(yōu)化

在JDK 1.6之前，鎖只有兩種狀態(tài)：無(wú)鎖狀態(tài)和重量級(jí)鎖狀態(tài)，而在這之后增加為四種狀態(tài)：無(wú)鎖狀態(tài)、偏向鎖狀態(tài)、輕量級(jí)鎖狀態(tài)、重量級(jí)鎖狀態(tài)，這種改進(jìn)基于兩點(diǎn)考慮：

• 無(wú)鎖狀態(tài)和重量級(jí)鎖狀態(tài)之間的切換是依賴于底層操作系統(tǒng)的Mutex Lock實(shí)現(xiàn)，操作系統(tǒng)實(shí)現(xiàn)線程之間的切換需要從用戶態(tài)切換到內(nèi)核態(tài)，切換成本很高。
• 實(shí)驗(yàn)研究發(fā)現(xiàn)，對(duì)于絕大部分的鎖，在整個(gè)生命周期內(nèi)都是不存在競(jìng)爭(zhēng)的。

需要注意，對(duì)于鎖的這四種狀態(tài)，它們會(huì)隨著競(jìng)爭(zhēng)的激烈而逐漸升級(jí)，但是它只允許鎖升級(jí)，不允許鎖降級(jí)。

無(wú)鎖狀態(tài)和重量級(jí)鎖狀態(tài)都比較好理解，下面我們主要介紹新增的兩種鎖狀態(tài)：偏向鎖狀態(tài)和輕量級(jí)鎖狀態(tài)。

整個(gè)轉(zhuǎn)換的流程圖如下所示，在后面的介紹中可以參考：

4.1 偏向鎖狀態(tài)

引入偏向鎖的目的是：在無(wú)多線程競(jìng)爭(zhēng)的情況下，盡量減少不必要的輕量級(jí)鎖執(zhí)行路徑，它的理想情況下是在無(wú)競(jìng)爭(zhēng)時(shí)把整個(gè)同步都去掉，連CAS操作都省略。

偏向鎖的意思是這個(gè)鎖會(huì)偏向于第一個(gè)獲得它的線程，如果在接下來(lái)的執(zhí)行過(guò)程中，該鎖沒(méi)有被其它線程獲取，則持有偏向鎖的線程將永遠(yuǎn)不需要再進(jìn)行同步。

4.1.1 獲取偏向鎖

(a) 前提條件

獲取偏向鎖的前提條件是synchronized所修飾的對(duì)象處于可偏向狀態(tài)

• 鎖狀態(tài)為01
• 偏向鎖狀態(tài)為1

(b) 獲取過(guò)程

當(dāng)滿足前提條件時(shí)，再去判斷對(duì)象的Mark Word中的線程ID是否指向當(dāng)前線程

• 如果不指向當(dāng)前線程，那么通過(guò)CAS操作競(jìng)爭(zhēng)鎖
  • 競(jìng)爭(zhēng)成功：將Mark Word的線程ID替換為當(dāng)前線程ID，接著執(zhí)行同步代碼塊
  • 競(jìng)爭(zhēng)失敗：證明存在多線程競(jìng)爭(zhēng)的情況，當(dāng)?shù)竭_(dá)全局安全點(diǎn)，獲得偏向鎖的線程被掛起，偏向鎖升級(jí)為輕量級(jí)鎖，然后被阻塞在安全點(diǎn)的線程繼續(xù)往下執(zhí)行同步代碼塊
• 如果指向當(dāng)前線程，那么執(zhí)行同步代碼塊

4.1.2 釋放偏向鎖

(a) 前提條件

釋放偏向鎖的前提條件是其它的線程在競(jìng)爭(zhēng)偏向鎖的過(guò)程中出現(xiàn)了失敗的情況，并且偏向鎖的釋放需要等待到達(dá)全局安全點(diǎn)。

(b) 釋放過(guò)程

當(dāng)滿足釋放偏向鎖的前提條件時(shí)，首先會(huì)暫停擁有偏向鎖的線程，接著判斷鎖對(duì)象是否處于被鎖定的狀態(tài)，決定鎖標(biāo)志位下一步的狀態(tài)：

• 如果未被鎖定，那么將鎖標(biāo)志至為01，偏向鎖狀態(tài)置為0，表示它處于無(wú)鎖，且不可偏向狀態(tài)。
• 如果已經(jīng)被鎖定，那么將鎖標(biāo)志置為00，表示它處于被輕量級(jí)鎖定的狀態(tài)。

4.2 輕量級(jí)鎖狀態(tài)

引入輕量級(jí)鎖的目的是：在無(wú)多線程競(jìng)爭(zhēng)的情況下，減少傳統(tǒng)的重量級(jí)鎖使用操作系統(tǒng)互斥量產(chǎn)生的性能消耗。

4.2.1 獲取輕量級(jí)鎖

(a) 前提條件

獲取輕量級(jí)鎖的前提條件時(shí)當(dāng)前對(duì)象處于無(wú)鎖狀態(tài)，

• 鎖狀態(tài)標(biāo)志位為01
• 偏向鎖標(biāo)志位為0

(b) 獲取過(guò)程

JVM首先將在當(dāng)前線程的棧幀中建立一個(gè)名為鎖記錄（Lock Record）的空間，用于存儲(chǔ)對(duì)象目前的Mark Word的拷貝，之后JVM利用CAS操作嘗試將對(duì)象的Mark Word更新為指向Lock Record的指針：

• 操作成功：將鎖標(biāo)志置為00，表示處于鎖定的狀態(tài)，之后執(zhí)行同步操作。
• 操作失敗：那么檢查對(duì)象的Mark Word是否指向當(dāng)前線程的棧針
• 如果是，則直接執(zhí)行同步代碼塊
• 如果不是，說(shuō)明該鎖對(duì)象已經(jīng)被其他線程搶占了，此時(shí)輕量級(jí)鎖升級(jí)為重量鎖，鎖標(biāo)志位變?yōu)?code>10，后面等待的線程將會(huì)進(jìn)入阻塞狀態(tài)。

4.2.2 釋放輕量級(jí)鎖

(a) 釋放過(guò)程

輕量級(jí)鎖的釋放也是通過(guò)CAS操作來(lái)進(jìn)行的：

• 取出在獲取輕量級(jí)鎖時(shí)，保存在Displaced Mark Word中的數(shù)據(jù)。
• 用CAS操作將取出的數(shù)據(jù)替換到當(dāng)前對(duì)象的Mark Word中：
• 如果成功，則說(shuō)明釋放鎖成功
• 如果失敗，說(shuō)明有其它線程嘗試獲取該鎖，那么需要在釋放鎖的同時(shí)，喚醒需要被喚醒的線程

對(duì)于輕量級(jí)鎖，它性能提升的依據(jù)是默認(rèn)"對(duì)于絕大部分的鎖，在整個(gè)生命周期內(nèi)是不會(huì)存在競(jìng)爭(zhēng)的"，如果不符合這種情況，那么除了互斥的開(kāi)銷外，還有額外的CAS操作，這樣輕量級(jí)鎖比重量級(jí)鎖更慢。

五、參考文章

Java 并發(fā)編程：Synchronized 底層優(yōu)化（偏向鎖、輕量級(jí)鎖）
死磕 Java 并發(fā) -----深入分析 synchronized 的實(shí)現(xiàn)原理
深入理解 Java 鎖與線程阻塞