前言

線程安全問題的主要誘因有兩點(diǎn)，一是存在共享數(shù)據(jù)(也稱臨界資源)，二是存在多條線程共同操作共享數(shù)據(jù)。

因此為了解決這個(gè)問題，我們可能需要這樣一個(gè)方案，當(dāng)存在多個(gè)線程操作共享數(shù)據(jù)時(shí)，需要保證同一時(shí)刻有且只有一個(gè)線程在操作共享數(shù)據(jù)，其他線程必須等到該線程處理完數(shù)據(jù)后再進(jìn)行，這種方式有個(gè)高尚的名稱叫互斥鎖，即能達(dá)到互斥訪問目的的鎖，也就是說當(dāng)一個(gè)共享數(shù)據(jù)被當(dāng)前正在訪問的線程加上互斥鎖后，在同一個(gè)時(shí)刻，其他線程只能處于等待的狀態(tài)，直到當(dāng)前線程處理完畢釋放該鎖。

在 Java 中，關(guān)鍵字 synchronized可以保證在同一個(gè)時(shí)刻，只有一個(gè)線程可以執(zhí)行某個(gè)方法或者某個(gè)代碼塊(主要是對(duì)方法或者代碼塊中存在共享數(shù)據(jù)的操作)，同時(shí)我們還應(yīng)該注意到synchronized另外一個(gè)重要的作用，synchronized可保證一個(gè)線程的變化(主要是共享數(shù)據(jù)的變化)被其他線程所看到（保證可見性，完全可以替代Volatile功能），這點(diǎn)確實(shí)也是很重要的。

synchronized三種作用范圍（給對(duì)象加鎖）

在靜態(tài)方法上加鎖；

在非靜態(tài)方法上加鎖；

在代碼塊上加鎖；

public class SynchronizedSample {
 
    private final Object lock = new Object();
 
    private static int money = 0;
		//非靜態(tài)方法
    public synchronized void noStaticMethod(){
        money++;
    }
		//靜態(tài)方法
    public static synchronized void staticMethod(){
        money++;
    }
		
    public void codeBlock(){
      	//代碼塊
        synchronized (lock){
            money++;
        }
    }
}

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

先理解Java對(duì)象頭與Monitor

1.對(duì)象頭：鎖的類型和狀態(tài)和對(duì)象頭的Mark Word息息相關(guān)；

對(duì)象頭分為二個(gè)部分，Mard Word 和 Klass Word

其中Mark Word在默認(rèn)情況下存儲(chǔ)著對(duì)象的HashCode、分代年齡、鎖標(biāo)記位等以下是32位JVM的Mark Word默認(rèn)存儲(chǔ)結(jié)構(gòu)

主要分析一下重量級(jí)鎖也就是通常說synchronized的對(duì)象鎖，鎖標(biāo)識(shí)位為10，其中指針指向的是monitor對(duì)象（也稱為管程或監(jiān)視器鎖）的起始地址。每個(gè)對(duì)象都存在著一個(gè) monitor 與之關(guān)聯(lián)，對(duì)象與其 monitor 之間的關(guān)系有存在多種實(shí)現(xiàn)方式，如monitor可以與對(duì)象一起創(chuàng)建銷毀或當(dāng)線程試圖獲取對(duì)象鎖時(shí)自動(dòng)生成，但當(dāng)一個(gè) monitor 被某個(gè)線程持有后，它便處于鎖定狀態(tài)。在Java虛擬機(jī)(HotSpot)中，monitor是由ObjectMonitor實(shí)現(xiàn)的，其主要數(shù)據(jù)結(jié)構(gòu)如下（位于HotSpot虛擬機(jī)源碼ObjectMonitor.hpp文件，C++實(shí)現(xiàn)的）

//👇圖詳細(xì)介紹重要變量的作用
ObjectMonitor() {
    _header       = NULL;
    _count        = 0;   // 重入次數(shù)
    _waiters      = 0,   // 等待線程數(shù)
    _recursions   = 0;
    _object       = NULL;
    _owner        = NULL;  // 當(dāng)前持有鎖的線程
    _WaitSet      = NULL;  // 調(diào)用了 wait 方法的線程被阻塞 放置在這里
    _WaitSetLock  = 0 ;
    _Responsible  = NULL ;
    _succ         = NULL ;
    _cxq          = NULL ;
    FreeNext      = NULL ;
    _EntryList    = NULL ; // 等待鎖 處于block的線程 有資格成為候選資源的線程
    _SpinFreq     = 0 ;
    _SpinClock    = 0 ;
    OwnerIsThread = 0 ;
  }

ObjectMonitor中有兩個(gè)隊(duì)列，_WaitSet 和 _EntryList，用來保存ObjectWaiter對(duì)象列表( 每個(gè)等待鎖的線程都會(huì)被封裝成ObjectWaiter對(duì)象)，_owner指向持有ObjectMonitor對(duì)象的線程，當(dāng)多個(gè)線程同時(shí)訪問一段同步代碼時(shí)，首先會(huì)進(jìn)入 _EntryList 集合，當(dāng)線程獲取到對(duì)象的monitor 后進(jìn)入 _Owner 區(qū)域并把monitor中的owner變量設(shè)置為當(dāng)前線程同時(shí)monitor中的計(jì)數(shù)器count加1，若線程調(diào)用 wait() 方法，將釋放當(dāng)前持有的monitor，owner變量恢復(fù)為null，count自減1，同時(shí)該線程進(jìn)入 WaitSet集合中等待被喚醒。若當(dāng)前線程執(zhí)行完畢也將釋放monitor(鎖)并復(fù)位變量的值，以便其他線程進(jìn)入獲取monitor(鎖)。如下圖所示

由此看來，monitor對(duì)象存在于每個(gè)Java對(duì)象的對(duì)象頭中(存儲(chǔ)的指針的指向)，synchronized鎖便是通過這種方式獲取鎖的，也是為什么Java中任意對(duì)象可以作為鎖的原因，同時(shí)也是notify/notifyAll/wait等方法存在于頂級(jí)對(duì)象Object中的原因(關(guān)于這點(diǎn)稍后還會(huì)進(jìn)行分析)。

jdk6 之后做了改進(jìn)，引入了偏向鎖和輕量級(jí)鎖：

• 依賴底層操作系統(tǒng)的 mutex 相關(guān)指令實(shí)現(xiàn)，加鎖解鎖需要在用戶態(tài)和內(nèi)核態(tài)之間切換，性能損耗非常明顯。
• 研究人員發(fā)現(xiàn)，大多數(shù)對(duì)象的加鎖和解鎖都是在特定的線程中完成。也就是出現(xiàn)線程競爭鎖的情況概率比較低。他們做了一個(gè)實(shí)驗(yàn)，找了一些典型的軟件，測(cè)試同一個(gè)線程加鎖解鎖的重復(fù)率，如下圖所示，可以看到重復(fù)加鎖比例非常高。早期JVM 有 19% 的執(zhí)行時(shí)間浪費(fèi)在鎖上。

1.無鎖到偏向鎖轉(zhuǎn)化的過程

• 首先A 線程訪問同步代碼塊，使用CAS 操作將 Thread ID 放到 Mark Word 當(dāng)中；
• 如果CAS 成功，此時(shí)線程A 就獲取了鎖
• 如果線程CAS 失敗，證明有別的線程持有鎖，例如上圖的線程B 來CAS 就失敗的，這個(gè)時(shí)候啟動(dòng)偏向鎖撤銷 （revoke bias）；
• 鎖撤銷流程：
  • 讓 A線程在全局安全點(diǎn)阻塞（類似于GC前線程在安全點(diǎn)阻塞）
  • 遍歷線程棧，查看是否有被鎖對(duì)象的鎖記錄（ Lock Record），如果有Lock Record，需要修復(fù)鎖記錄和Markword，使其變成無鎖狀態(tài)。
  • 恢復(fù)A線程
  • 將是否為偏向鎖狀態(tài)置為 0 ，開始進(jìn)行輕量級(jí)加鎖流程
    

2.偏向鎖升級(jí)輕量級(jí)

• 線程在自己的棧楨中創(chuàng)建鎖記錄 LockRecord。
• 線程A 將 Mark Word 拷貝到線程棧的 Lock Record中
• 將鎖記錄中的Owner指針指向加鎖的對(duì)象（存放對(duì)象地址）
• 將鎖對(duì)象的對(duì)象頭的MarkWord替換為指向鎖記錄的指針。
• 這時(shí)鎖標(biāo)志位變成 00 ，表示輕量級(jí)鎖

其實(shí)就是撤銷偏向鎖后，當(dāng)前線程棧中會(huì)分配鎖記錄，并拷貝Mark Word到鎖記錄中。然后兩個(gè)線程用CAS的方式去修改Mark Word中的指針指向自己，假如說第一個(gè)線程修改成功了，然后將鎖升級(jí)為輕量級(jí)鎖，去執(zhí)行同步語句塊中的內(nèi)容。

3.輕量級(jí)到重量級(jí)

修改失敗的第二個(gè)線程會(huì)進(jìn)入自旋狀態(tài)，自旋結(jié)束后會(huì)繼續(xù)去嘗試CAS修改指針指向自己。如果自旋失敗超過一定次數(shù)的時(shí)候（這個(gè)次數(shù)會(huì)動(dòng)態(tài)進(jìn)行調(diào)整），會(huì)請(qǐng)求JVM將此時(shí)的鎖狀態(tài)升級(jí)為重量級(jí)鎖，這是依賴于底層操作系統(tǒng)的調(diào)度庫來實(shí)現(xiàn)的。接著將Mark Word指向重量級(jí)鎖Monitor的指針，然后掛起當(dāng)前第二個(gè)線程（被放在Monitor的_EntryList中）。等一個(gè)線程執(zhí)行完畢后，會(huì)查看當(dāng)前Mark Word中的指針是否仍然指向自己，如果是自己的話就釋放鎖，否則不是自己的話，說明此時(shí)已經(jīng)升級(jí)成了重量級(jí)鎖，除了釋放鎖之后，還會(huì)喚醒阻塞的線程，進(jìn)行新一輪的鎖競爭。在此之后，該鎖就一直會(huì)是重量級(jí)鎖存在了

ps：為什么設(shè)計(jì)自旋數(shù)超過一定限制設(shè)置為重量級(jí)鎖？

一般來說，同步代碼塊內(nèi)的代碼應(yīng)該很快就執(zhí)行結(jié)束，這時(shí)候修改失敗的第二個(gè)線程自旋一段時(shí)間是很容易拿到鎖的，但是如果不巧，沒拿到，自旋其實(shí)就是死循環(huán)，很耗CPU的，因此就直接轉(zhuǎn)成重量級(jí)鎖咯，這樣就不用了線程一直自旋了。

源碼才學(xué)疏淺只了解到：

synchronized 在代碼塊上是通過 monitorenter 和 monitorexit指令實(shí)現(xiàn)，在靜態(tài)方法和 方法上加鎖是在方法的flags 中加入 ACC_SYNCHRONIZED 。JVM 運(yùn)行方法時(shí)檢查方法的flags，遇到同步標(biāo)識(shí)開始啟動(dòng)前面的加鎖流程，在方法內(nèi)部遇到monitorenter指令開始加鎖。

總結(jié)

本篇文章就到這里了，希望能夠給你帶來幫助，也希望您能夠多多關(guān)注腳本之家的更多內(nèi)容！