synchronized 作用

synchronized 關(guān)鍵字是 Java 并發(fā)編程中線程同步的常用手段之一。

1.1 作用：

• 確保線程互斥的訪問(wèn)同步代，鎖自動(dòng)釋放，多個(gè)線程操作同個(gè)代碼塊或函數(shù)必須排隊(duì)獲得鎖，
• 保證共享變量的修改能夠及時(shí)可見，獲得鎖的線程操作完畢后會(huì)將所數(shù)據(jù)刷新到共享內(nèi)存區(qū)；
• 不解決重排序，但保證有序性。

1.2 用法：

• 修飾實(shí)例方法synchronized 關(guān)鍵詞作用在方法的前面，用來(lái)鎖定方法，其實(shí)默認(rèn)鎖定的是 this 對(duì)象。

public class Thread1 implements Runnable{ //共享資源(臨界資源) static int i=0; //如果沒有synchronized關(guān)鍵字，輸出小于20000 public synchronized void increase(){ i++; } public void run() { for(int j=0;j<10000;j++){ increase(); } } public static void main(String[] args) throws InterruptedException { Thread1 t=new Thread1(); Thread t1=new Thread(t); Thread t2=new Thread(t); t1.start(); t2.start(); t1.join();//主線程等待t1執(zhí)行完畢 t2.join();//主線程等待t2執(zhí)行完畢 System.out.println(i); }}

• 修飾靜態(tài)方法synchronized 還是修飾在方法上，不過(guò)修飾的是靜態(tài)方法，等價(jià)于鎖定的是 Class 對(duì)象。

public class Thread1 { //共享資源(臨界資源) static int i = 0; //如果沒有synchronized關(guān)鍵字，輸出小于20000 public static synchronized void increase() { i++; } public static void main(String[] args) throws InterruptedException { Thread t1 = new Thread(new Runnable() { public void run() { for (int j = 0; j < 10000; j++) { increase(); } } }); Thread t2 = new Thread(new Runnable() { @Override public void run() { for (int j = 0; j < 10000; j++) { increase(); } } }); t1.start(); t2.start(); t1.join();//主線程等待t1執(zhí)行完畢 t2.join();//主線程等待t2執(zhí)行完畢 System.out.println(i); }}

• 修飾代碼塊用法是在函數(shù)體內(nèi)部對(duì)于要修改的參數(shù)區(qū)間用 synchronized 來(lái)修飾，相比與鎖定函數(shù)這個(gè)范圍更小，可以指定鎖定什么對(duì)象。

public class Thread1 implements Runnable { //共享資源(臨界資源) static int i = 0; @Override public void run() { for (int j = 0; j < 10000; j++) { //獲得了String的類鎖 synchronized (String.class) { i++; } } } public static void main(String[] args) throws InterruptedException { Thread1 t = new Thread1(); Thread t1 = new Thread(t); Thread t2 = new Thread(t); t1.start(); t2.start(); t1.join(); t2.join(); System.out.println(i); }}

總結(jié)：

synchronized 修飾的實(shí)例方法，多線程并發(fā)訪問(wèn)時(shí)，只能有一個(gè)線程進(jìn)入，獲得對(duì)象內(nèi)置鎖，其他線程阻塞等待，但在此期間線程仍然可以訪問(wèn)其他方法。

synchronized 修飾的靜態(tài)方法，多線程并發(fā)訪問(wèn)時(shí)，只能有一個(gè)線程進(jìn)入，獲得類鎖，其他線程阻塞等待，但在此期間線程仍然可以訪問(wèn)其他方法。synchronized 修飾的代碼塊，多線程并發(fā)訪問(wèn)時(shí)，只能有一個(gè)線程進(jìn)入，根據(jù)括號(hào)中的對(duì)象或者是類，獲得相應(yīng)的對(duì)象內(nèi)置鎖或者是類鎖每個(gè)類都有一個(gè)類鎖，類的每個(gè)對(duì)象也有一個(gè)內(nèi)置鎖，它們是互不干擾的，也就是說(shuō)一個(gè)線程可以同時(shí)獲得類鎖和該類實(shí)例化對(duì)象的內(nèi)置鎖，當(dāng)線程訪問(wèn)非 synchronzied 修飾的方法時(shí)，并不需要獲得鎖，因此不會(huì)產(chǎn)生阻塞。

管程

管程(英語(yǔ)：Monitors，也稱為監(jiān)視器) 在操作系統(tǒng)中是很重要的概念，管程其實(shí)指的是管理共享變量以及管理共享變量的操作過(guò)程。有點(diǎn)扮演中介的意思，管程管理一堆對(duì)象，多個(gè)線程同一時(shí)候只能有一個(gè)線程來(lái)訪問(wèn)這些東西。

管程可以看做一個(gè)軟件模塊，它是將共享的變量和對(duì)于這些共享變量的操作封裝起來(lái)，形成一個(gè)具有一定接口的功能模塊，進(jìn)程可以調(diào)用管程來(lái)實(shí)現(xiàn)進(jìn)程級(jí)別的并發(fā)控制。

進(jìn)程只能互斥地使用管程，即當(dāng)一個(gè)進(jìn)程使用管程時(shí)，另一個(gè)進(jìn)程必須等待。當(dāng)一個(gè)進(jìn)程使用完管程后，它必須釋放管程并喚醒等待管程的某一個(gè)進(jìn)程。

管程解決互斥問(wèn)題相對(duì)簡(jiǎn)單，需要把共享變量以及共享變量的操作都封裝在一個(gè)類中。

當(dāng)線程 A 和線程 B 需要獲取共享變量 count 時(shí)，就需要調(diào)用 get 和 set 方法，而 get 和 set 方法則保證互斥性，保證每次只能有一個(gè)線程訪問(wèn)。

生活中舉例管程，比如鏈家店長(zhǎng)分配給每個(gè)中介管理一部分二手房源，多個(gè)客戶通過(guò)中介進(jìn)行房屋買賣。

• 中介就是管程。
• 多個(gè)二手房源被一個(gè)中介管理中，就是一個(gè)管程管理著多個(gè)系統(tǒng)資源。
• 多個(gè)客戶就相當(dāng)于多個(gè)線程。

Synchronzied 的底層原理

對(duì)象頭解析

我們知道在 Java 的 JVM 內(nèi)存區(qū)域中一個(gè)對(duì)象在堆區(qū)創(chuàng)建，創(chuàng)建后的對(duì)象由對(duì)象頭、實(shí)例變量、填充數(shù)據(jù)三部分組成。這三部分功能如下：

填充數(shù)據(jù)：由于虛擬機(jī)要求對(duì)象起始地址必須是 8 字節(jié)的整數(shù)倍。填充數(shù)據(jù)不是必須存在的，僅僅是為了字節(jié)對(duì)齊。

實(shí)例變量：存放類的屬性數(shù)據(jù)信息，包括父類的屬性信息，這部分內(nèi)存按 4 字節(jié)對(duì)齊。對(duì)象頭：主要包括兩部分 Klass Point 跟 Mark Word。

Klass Point (類型指針)：是對(duì)象指向它的類元數(shù)據(jù)的指針，虛擬機(jī)通過(guò)這個(gè)指針來(lái)確定這個(gè)對(duì)象是哪個(gè)類的實(shí)例。

Mark Word (標(biāo)記字段)：這一部分用于儲(chǔ)存對(duì)象自身的運(yùn)行時(shí)的數(shù)據(jù)，如哈希碼、GC 分代年齡、鎖狀態(tài)標(biāo)志、鎖指針等。這部分?jǐn)?shù)據(jù)在 32 bit 和 64 bit 的虛擬機(jī)中大小分別為 32 bit 和 64 bit，考慮到虛擬機(jī)的空間效率，Mark Word 被設(shè)計(jì)成一個(gè)非固定的數(shù)據(jù)結(jié)構(gòu)，以便在極小的空間中存儲(chǔ)盡量多的信息，它會(huì)根據(jù)對(duì)象的狀態(tài)復(fù)用自己的存儲(chǔ)空間(跟 ConcurrentHashMap 里的標(biāo)志位類似)，詳細(xì)情況如下圖：

synchronized 不論是修飾方法還是代碼塊，都是通過(guò)持有修飾對(duì)象的鎖來(lái)實(shí)現(xiàn)同步，synchronized 鎖對(duì)象是存在對(duì)象頭 Mark Word。

其中，輕量級(jí)鎖和偏向鎖是 Java6 對(duì) synchronized 鎖進(jìn)行優(yōu)化后新增加的。這里我們主要分析一下重量級(jí)鎖，也就是通常說(shuō) synchronized 的對(duì)象鎖。所標(biāo)識(shí)位為 10，其中指針指向的是 monitor 對(duì)象(也稱為管程或監(jiān)視器鎖)的起始地址。每個(gè)對(duì)象都存在著一個(gè) monitor 與之關(guān)聯(lián)。

反匯編查看

分析對(duì)象的 monitor 前我們先通過(guò)反匯編看下同步方法跟同步方法塊在匯編語(yǔ)言級(jí)別是什么樣的指令。

public class SynchronizedTest { public synchronized void doSth(){ System.out.println("Hello World"); } public void doSth1(){ synchronized (SynchronizedTest.class){ System.out.println("Hello World"); } }}

javac SynchronizedTest .java 然后 javap -c SynchronizedTest 反編譯后看匯編指令如下：

public synchronized void doSth(); descriptor: ()V flags: ACC_PUBLIC, ACC_SYNCHRONIZED // 這是重點(diǎn) 方法鎖 Code: stack=2, locals=1, args_size=1 0: getstatic #2 3: ldc #3 5: invokevirtual #4 8: return public void doSth1(); descriptor: ()V flags: ACC_PUBLIC Code: stack=2, locals=3, args_size=1 0: ldc #5 2: dup 3: astore_1 4: monitorenter // 進(jìn)入同步方法 5: getstatic #2 8: ldc #3 10: invokevirtual #4 13: aload_1 14: monitorexit //正常時(shí) 退出同步方法 15: goto 23 18: astore_2 19: aload_1 20: monitorexit // 異常時(shí) 退出同步方法 21: aload_2 22: athrow 23: return

我們可以看到 Java 編譯器為我們生成的字節(jié)碼。在對(duì)于 doSth 和 doSth1 的處理上稍有不同。也就是說(shuō)，JVM 對(duì)于同步方法和同步代碼塊的處理方式不同。對(duì)于同步方法，JVM 采用ACC_SYNCHRONIZED 標(biāo)記符來(lái)實(shí)現(xiàn)同步。對(duì)于同步代碼塊。JVM 采用 monitorenter、monitorexit 兩個(gè)指令來(lái)實(shí)現(xiàn)同步。

ACC_SYNCHRONIZED

方法級(jí)的同步是隱式的。

同步方法的常量池中會(huì)有一個(gè) ACC_SYNCHRONIZED 標(biāo)志。當(dāng)某個(gè)線程要訪問(wèn)某個(gè)方法的時(shí)候，會(huì)檢查是否有 ACC_SYNCHRONIZED，如果有設(shè)置，則需要先獲得監(jiān)視器鎖，然后開始執(zhí)行方法，方法執(zhí)行之后再釋放監(jiān)視器鎖。

這時(shí)如果其他線程來(lái)請(qǐng)求執(zhí)行方法，會(huì)因?yàn)闊o(wú)法獲得監(jiān)視器鎖而被阻斷住。值得注意的是，如果在方法執(zhí)行過(guò)程中發(fā)生了異常，并且方法內(nèi)部并沒有處理該異常，那么在異常被拋到方法外面之前監(jiān)視器鎖會(huì)被自動(dòng)釋放。

monitorenter 跟 monitorexit

可以把執(zhí)行 monitorenter 指令理解為加鎖，執(zhí)行 monitorexit 理解為釋放鎖。

每個(gè)對(duì)象維護(hù)著一個(gè)記錄著被鎖次數(shù)的計(jì)數(shù)器。未被鎖定的對(duì)象的該計(jì)數(shù)器為 0，當(dāng)一個(gè)線程獲得鎖(執(zhí)行 monitorenter )后，該計(jì)數(shù)器自增變?yōu)?1 ，當(dāng)同一個(gè)線程再次獲得該對(duì)象的鎖的時(shí)候，計(jì)數(shù)器再次自增。當(dāng)同一個(gè)線程釋放鎖(執(zhí)行 monitorexit 指令)的時(shí)候，計(jì)數(shù)器再自檢。

當(dāng)計(jì)數(shù)器為 0 的時(shí)候。鎖將被釋放，其他線程便可以獲得鎖。

結(jié)論：

同步方法和同步代碼塊底層都是通過(guò) monitor 來(lái)實(shí)現(xiàn)同步的。兩者區(qū)別：同步方式是通過(guò)方法中的 access_flags 中設(shè)置 ACC_SYNCHRONIZED 標(biāo)志來(lái)實(shí)現(xiàn)，同步代碼塊是通過(guò) monitorenter 和 monitorexit 來(lái)實(shí)現(xiàn)。

monitor 解析

每個(gè)對(duì)象都與一個(gè) monitor 相關(guān)聯(lián)，而 monitor 可以被線程擁有或釋放，在Java 虛擬機(jī)( HotSpot )中，monitor 是由 ObjectMonitor 實(shí)現(xiàn)的，其主要數(shù)據(jù)結(jié)構(gòu)如下(位于 HotSpot 虛擬機(jī)源碼 ObjectMonitor.hpp 文件，C++實(shí)現(xiàn)的)。

ObjectMonitor() { _count = 0; //記錄數(shù) _recursions = 0; //鎖的重入次數(shù) _owner = NULL; //指向持有ObjectMonitor對(duì)象的線程 _WaitSet = NULL; //調(diào)用wait后，線程會(huì)被加入到_WaitSet _EntryList = NULL ; //等待獲取鎖的線程，會(huì)被加入到該列表}

monitor 運(yùn)行圖如下：

對(duì)于一個(gè) synchronized 修飾的方法(代碼塊)來(lái)說(shuō)：

• 當(dāng)多個(gè)線程同時(shí)訪問(wèn)該方法，那么這些線程會(huì)先被放進(jìn)_EntryList 隊(duì)列，此時(shí)線程處于 blocked 狀態(tài)；
• 當(dāng)一個(gè)線程獲取到了對(duì)象的 monitor 后，那么就可以進(jìn)入 running 狀態(tài)，執(zhí)行方法塊，此時(shí)，ObjectMonitor 對(duì)象的_owner 指向當(dāng)前線程，_count 加 1 表示當(dāng)前對(duì)象鎖被一個(gè)線程獲取；
• 當(dāng) running 狀態(tài)的線程調(diào)用 wait() 方法，那么當(dāng)前線程釋放 monitor 對(duì)象，進(jìn)入 waiting 狀態(tài)，ObjectMonitor 對(duì)象的_owner 變?yōu)?null，_count 見 1，同時(shí)線程進(jìn)入_WaitSet 隊(duì)列，直到有線程調(diào)用 notify() 方法喚醒該線程，則該線程進(jìn)入_EntryList 隊(duì)列，競(jìng)爭(zhēng)到鎖再進(jìn)入_owner區(qū)；
• 如果當(dāng)前線程執(zhí)行完畢，那么也釋放 monitor 對(duì)象，ObjectMonitor 對(duì)象的_owner 變?yōu)?null，_count 見 1。

因?yàn)楸O(jiān)視器鎖(monitor)是依賴于底層的操作系統(tǒng)的 Mutex Lock 來(lái)實(shí)現(xiàn)的，而操作系統(tǒng)實(shí)現(xiàn)線程之間的切換時(shí)需要從用戶態(tài)轉(zhuǎn)換到核心態(tài)(具體可看CXUAN 寫的 OS 哦)，這個(gè)狀態(tài)之間的轉(zhuǎn)換需要相對(duì)比較長(zhǎng)的時(shí)間，時(shí)間成本相對(duì)較高，這也是早期的 synchronized 效率低的原因。慶幸在 Java 6 之后Java 官方對(duì)從 JVM 層面對(duì) synchronized 較大優(yōu)化最終提升顯著，Java 6 之后，為了減少獲得鎖和釋放鎖所帶來(lái)的性能消耗，引入了鎖升級(jí)的概念。

鎖升級(jí)

synchronized 鎖有四種狀態(tài)：無(wú)鎖、偏向鎖、輕量級(jí)鎖、重量級(jí)鎖。

這幾個(gè)狀態(tài)會(huì)隨著競(jìng)爭(zhēng)狀態(tài)逐漸升級(jí)，鎖可以升級(jí)但不能降級(jí)，但是偏向鎖狀態(tài)可以被重置為無(wú)鎖狀態(tài)。科學(xué)性的說(shuō)這些鎖之前我們先看個(gè)簡(jiǎn)單通俗的例子來(lái)加深印象。

通俗說(shuō)法理解各種鎖

偏向鎖、輕量級(jí)鎖和重量級(jí)鎖之間的關(guān)系，首先打個(gè)比方：假設(shè)現(xiàn)在廁所只有一個(gè)位置，每個(gè)使用者都有打開門鎖的鑰匙。必須打開門鎖才能使用廁所。其中小明、小紅理解為兩個(gè)線程，上廁所理解為執(zhí)行同步代碼，門鎖理解為同步代碼的鎖

• 小明今天吃壞了東西需要反復(fù)去廁所，如果小明每次都要開鎖就很耽誤時(shí)間，于是門鎖將小明的臉記錄下來(lái)(假設(shè)那個(gè)鎖是智能鎖)，下次小明再來(lái)的時(shí)候門鎖會(huì)自動(dòng)識(shí)別出是小明來(lái)了，然后自動(dòng)開鎖，這樣就省去了小明拿鑰匙開門的過(guò)程，此時(shí)門鎖就是偏向鎖，也可以理解為偏向小明的鎖。

接下來(lái)，小紅又去上廁所，試圖將廁所的門鎖設(shè)置為偏向自己的偏向鎖，于是發(fā)現(xiàn)門鎖無(wú)法偏向自己，因?yàn)榇藭r(shí)門鎖已是偏向小明的偏向鎖。于是小紅很生氣，要求門鎖撤銷對(duì)小明的偏向，當(dāng)然，小明也不同意門鎖偏向小紅。于是等小明用完廁所之后，門鎖撤銷了對(duì)任何人的偏向(只要出現(xiàn)競(jìng)爭(zhēng)的情況，就會(huì)撤銷偏向鎖)。這個(gè)過(guò)程就是撤銷偏向鎖。此時(shí)門鎖升級(jí)為輕量級(jí)鎖。等小明出來(lái)以后，輕量級(jí)鎖正式生效 。下一次小明和小紅同時(shí)來(lái)廁所，誰(shuí)跑的快誰(shuí)先走到門前，開門后將門鎖拿進(jìn)廁所，并將門鎖打開以后拿進(jìn)廁所里，將門反鎖，于是在門外原來(lái)放門鎖的位置放置了一個(gè)有人的標(biāo)志(這個(gè)標(biāo)識(shí)可以理解為指向門鎖的指針，或者理解為作為鎖的 Java 對(duì)象頭的 Mark Word 值)，這時(shí)，小紅看到有人以后很著急，催著里面的人出來(lái)時(shí)馬上進(jìn)去，于是不斷的來(lái)敲門，問(wèn)小明什么時(shí)候出來(lái)。這個(gè)過(guò)程就是自旋。反復(fù)敲了幾次以后，小明受不了了，對(duì)小紅喊話，說(shuō)你別敲了，等我用完廁所我告訴你，于是小紅去一邊等著(線性阻塞)。此時(shí)門鎖升級(jí)為重量級(jí)鎖。升級(jí)為重量級(jí)鎖的后果就是，小紅不再反復(fù)敲門，小明在上完廁所以后必須告訴小紅一聲，否則小紅就會(huì)一直等著。

結(jié)論：

偏向鎖在只有一個(gè)人上廁所時(shí)非常高效，省去了開門的過(guò)程。

輕量級(jí)鎖在有多人上廁所但是每個(gè)人使用的特別快的時(shí)候，比較高效，因?yàn)闀?huì)出現(xiàn)這種現(xiàn)象，小紅敲門的時(shí)候正好趕上小明出來(lái)，這樣就省得小明出來(lái)告訴小紅以后小紅才能進(jìn)去，但是這樣可能會(huì)出現(xiàn)小紅敲門失敗的情況(就是敲門時(shí)小明還沒用完)。

重量級(jí)鎖相比與輕量級(jí)鎖的多了一步小明呼喚小紅的步驟，但是卻省掉了小紅反復(fù)去敲門的過(guò)程，但是能保證小紅去廁所時(shí)廁所一定是沒人的。

偏向鎖

經(jīng)過(guò) HotSpot 作者大量的研究發(fā)現(xiàn)：大多數(shù)時(shí)候是不存在鎖競(jìng)爭(zhēng)的，經(jīng)常是一個(gè)線程多次獲得同一個(gè)鎖，因此如果每次都要競(jìng)爭(zhēng)鎖會(huì)增大很多沒有必要付出的代價(jià)，為了降低獲取鎖的代價(jià)，才引入的偏向鎖。核心思想：

如果一個(gè)線程獲得了鎖，那么鎖就進(jìn)入偏向模式，此時(shí) Mark Word 的結(jié)構(gòu)也變?yōu)槠蜴i結(jié)構(gòu)，當(dāng)這個(gè)線程再次請(qǐng)求鎖時(shí)，無(wú)需再做任何同步操作，即獲取鎖的過(guò)程。

這樣就省去了大量有關(guān)鎖申請(qǐng)的操作，從而也就提供程序的性能。所以，對(duì)于沒有鎖競(jìng)爭(zhēng)的場(chǎng)合，偏向鎖有很好的優(yōu)化效果，畢竟極有可能連續(xù)多次是同一個(gè)線程申請(qǐng)相同的鎖。但是對(duì)于鎖競(jìng)爭(zhēng)比較激烈的場(chǎng)合，偏向鎖就失效了，因?yàn)檫@樣場(chǎng)合極有可能每次申請(qǐng)鎖的線程都是不相同的。

因此這種場(chǎng)合下不應(yīng)該使用偏向鎖，否則會(huì)得不償失，需要注意的是，偏向鎖失敗后，并不會(huì)立即膨脹為重量級(jí)鎖，而是先升級(jí)為輕量級(jí)鎖。

具體流程：當(dāng)線程 1 訪問(wèn)代碼塊并獲取鎖對(duì)象時(shí)，會(huì)在 java 對(duì)象頭和棧幀中記錄偏向的鎖的 threadID，因?yàn)槠蜴i不會(huì)主動(dòng)釋放鎖。因此以后線程 1 再次獲取鎖的時(shí)候，需要比較當(dāng)前線程的 threadID 和 Java 對(duì)象頭中的threadID 是否一致，如果一致(還是線程 1 獲取鎖對(duì)象)，則無(wú)需使用 CAS 來(lái)加鎖、解鎖；如果不一致(其他線程，如線程 2 要競(jìng)爭(zhēng)鎖對(duì)象，而偏向鎖不會(huì)主動(dòng)釋放因此還是存儲(chǔ)的線程 1 的 threadID)，那么需要查看Java 對(duì)象頭中記錄的線程 1 是否存活，如果沒有存活，那么鎖對(duì)象被重置為無(wú)鎖狀態(tài)，其它線程(線程 2)可以競(jìng)爭(zhēng)將其設(shè)置為偏向鎖；如果存活，那么立刻查找該線程(線程 1)的棧幀信息，如果還是需要繼續(xù)持有這個(gè)鎖對(duì)象，那么暫停當(dāng)前線程 1，撤銷偏向鎖，升級(jí)為 輕量級(jí)鎖，如果線程 1 不再使用該鎖對(duì)象，那么將鎖對(duì)象狀態(tài)設(shè)為無(wú)鎖狀態(tài)，重新偏向新的線程。

輕量級(jí)鎖

輕量級(jí)鎖考慮的是競(jìng)爭(zhēng)鎖對(duì)象的線程不多，而且線程持有鎖的時(shí)間也不長(zhǎng)的情景。因?yàn)樽枞€程需要高昂的耗時(shí)實(shí)現(xiàn) CPU 從用戶態(tài)轉(zhuǎn)到內(nèi)核態(tài)的切換，如果剛剛阻塞不久這個(gè)鎖就被釋放了，那這個(gè)代價(jià)就有點(diǎn)得不償失了，因此這個(gè)時(shí)候就干脆不阻塞這個(gè)線程，讓它自旋這等待鎖釋放。

原理跟升級(jí)：線程 1 獲取輕量級(jí)鎖時(shí)會(huì)先把鎖對(duì)象的對(duì)象頭 MarkWord 復(fù)制一份到線程 1 的棧幀中創(chuàng)建的用于存儲(chǔ)鎖記錄的空間(稱為DisplacedMarkWord )，然后使用 CAS 把對(duì)象頭中的內(nèi)容替換為線程 1 存儲(chǔ)的鎖記錄(DisplacedMarkWord)的地址；

如果在線程 1 復(fù)制對(duì)象頭的同時(shí)(在線程 1 CAS 之前)，線程 2 也準(zhǔn)備獲取鎖，復(fù)制了對(duì)象頭到線程 2 的鎖記錄空間中，但是在線程 2 CAS 的時(shí)候，發(fā)現(xiàn)線程 1 已經(jīng)把對(duì)象頭換了，「線程 2 的 CAS 失敗，那么線程 2 就嘗試使用自旋鎖來(lái)等待線程 1 釋放鎖」。自旋鎖簡(jiǎn)單來(lái)說(shuō)就是讓線程 2 在循環(huán)中不斷 CAS 嘗試獲得鎖對(duì)象。

但是如果自旋的時(shí)間太長(zhǎng)也不行，因?yàn)樽孕且?CPU 的，因此自旋的次數(shù)是有限制的。比如 10 次或者 100 次，如果自旋次數(shù)到了線程 1 還沒有釋放鎖，或者線程 1 還在執(zhí)行，線程 2 還在自旋等待，那么這個(gè)時(shí)候輕量級(jí)鎖就會(huì)膨脹為重量級(jí)鎖。重量級(jí)鎖把除了擁有鎖的線程都阻塞，防止 CPU 空轉(zhuǎn)。

鎖消除

消除鎖是虛擬機(jī)另外一種鎖的優(yōu)化，這種優(yōu)化更徹底，Java 虛擬機(jī)在 JIT 編譯時(shí)通過(guò)對(duì)運(yùn)行上下文的掃描，去除不可能存在共享資源競(jìng)爭(zhēng)的鎖，通過(guò)這種方式消，除沒有必要的鎖，可以節(jié)省毫無(wú)意義的請(qǐng)求鎖時(shí)間，我們知道StringBuffer 是線程安全的，里面包含鎖的存在，但是如果我們?cè)诤瘮?shù)內(nèi)部使用 StringBuffer 那么代碼會(huì)在 JIT 后會(huì)自動(dòng)將鎖釋放掉哦。

對(duì)比如下：

鎖狀態(tài)優(yōu)點(diǎn)缺點(diǎn)適用場(chǎng)景偏向鎖加鎖解鎖無(wú)需額外消耗，跟非同步方法時(shí)間相差納秒級(jí)別如果競(jìng)爭(zhēng)線程多，會(huì)帶來(lái)額外的鎖撤銷的消耗基本沒有其他線程競(jìng)爭(zhēng)的同步場(chǎng)景輕量級(jí)鎖競(jìng)爭(zhēng)的線程不會(huì)阻塞而是在自旋，可提高程序響應(yīng)速度如果一直無(wú)法獲得會(huì)自旋消耗CPU少量線程競(jìng)爭(zhēng)，持有鎖時(shí)間不長(zhǎng)，追求響應(yīng)速度重量級(jí)鎖線程競(jìng)爭(zhēng)不會(huì)導(dǎo)致 CPU 自旋跟消耗 CPU 資源線程阻塞，響應(yīng)時(shí)間長(zhǎng)很多線程競(jìng)爭(zhēng)鎖，切鎖持有時(shí)間長(zhǎng)，追求吞吐量時(shí)候

PS：ReentrantLock 底層實(shí)現(xiàn)依賴于特殊的 CPU 指令，比如發(fā)送 lock 指令和 unlock 指令，不需要用戶態(tài)和內(nèi)核態(tài)的切換，所以效率高。而synchronized 底層由監(jiān)視器鎖(monitor)是依賴于底層的操作系統(tǒng)的Mutex Lock 需要用戶態(tài)和內(nèi)核態(tài)的切換，所以效率會(huì)低一些。

鎖升級(jí)流程圖

最后奉上 unbelievableme 繪制的鎖升級(jí)大圖。

總結(jié)

以上是生活随笔為你收集整理的synchronized 异常_由浅入深，Java 并发编程中的 Synchronized的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。