前言：

線程安全是并發(fā)編程中的重要關(guān)注點(diǎn)，造成線程安全問題的主要原因有兩點(diǎn)，一是存在共享數(shù)據(jù)(也稱臨界資源)，二是存在多條線程共同操作共享數(shù)據(jù)。因此為了解決這個(gè)問題，我們可能需要這樣一個(gè)方案，當(dāng)存在多個(gè)線程操作共享數(shù)據(jù)時(shí)，需要保證同一時(shí)刻有且只有一個(gè)線程在操作共享數(shù)據(jù)，其他線程必須等到該線程處理完數(shù)據(jù)后再進(jìn)行，這種方式叫互斥鎖，即能達(dá)到互斥訪問目的的鎖，也就是說當(dāng)一個(gè)共享數(shù)據(jù)被當(dāng)前正在訪問的線程加上互斥鎖后，在同一個(gè)時(shí)刻，其他線程只能處于等待的狀態(tài)，直到當(dāng)前線程處理完畢釋放該鎖。

 1、synchronized 的作用：

synchronized 通過當(dāng)前線程持有對象鎖，從而擁有訪問權(quán)限，而其他沒有持有當(dāng)前對象鎖的線程無法擁有訪問權(quán)限，保證在同一時(shí)刻，只有一個(gè)線程可以執(zhí)行某個(gè)方法或者某個(gè)代碼塊，從而保證線程安全。synchronized 可以保證線程的可見性，synchronized 屬于隱式鎖，鎖的持有與釋放都是隱式的，我們無需干預(yù)。synchronized最主要的三種應(yīng)用方式：

• 修飾實(shí)例方法：作用于當(dāng)前實(shí)例加鎖，進(jìn)入同步代碼前要獲得當(dāng)前實(shí)例的鎖
• 修飾靜態(tài)方法：作用于當(dāng)前類對象加鎖，進(jìn)入同步代碼前要獲得當(dāng)前類對象的鎖
• 修飾代碼塊：指定加鎖對象，進(jìn)入同步代碼庫前要獲得給定對象的鎖

2、synchronized 底層語義原理：

synchronized 鎖機(jī)制在 Java 虛擬機(jī)中的同步是基于進(jìn)入和退出監(jiān)視器鎖對象 monitor 實(shí)現(xiàn)的（無論是顯示同步還是隱式同步都是如此），每個(gè)對象的對象頭都關(guān)聯(lián)著一個(gè) monitor 對象，當(dāng)一個(gè) monitor 被某個(gè)線程持有后，它便處于鎖定狀態(tài)。在 HotSpot 虛擬機(jī)中，monitor 是由 ObjectMonitor 實(shí)現(xiàn)的，每個(gè)等待鎖的線程都會被封裝成 ObjectWaiter 對象，ObjectMonitor 中有兩個(gè)集合，WaitSet 和 _EntryList，用來保存 ObjectWaiter 對象列表 ，owner 區(qū)域指向持有 ObjectMonitor 對象的線程。當(dāng)多個(gè)線程同時(shí)訪問一段同步代碼時(shí)，首先會進(jìn)入 _EntryList 集合嘗試獲取 moniter，當(dāng)線程獲取到對象的 monitor 后進(jìn)入 _Owner 區(qū)域并把 _owner 變量設(shè)置為當(dāng)前線程，同時(shí) monitor 中的計(jì)數(shù)器 count 加1；若線程調(diào)用 wait() 方法，將釋放當(dāng)前持有的 monitor，count自減1，owner 變量恢復(fù)為 null，同時(shí)該線程進(jìn)入 _WaitSet 集合中等待被喚醒。若當(dāng)前線程執(zhí)行完畢也將釋放 monitor 并復(fù)位變量的值，以便其他線程獲取 monitor。如下圖所示：

3、 synchronized 的顯式同步與隱式同步:

synchronized 分為顯式同步（同步代碼塊）和隱式同步（同步方法），顯式同步指的是有明確的 monitorenter 和 monitorexit 指令，而隱式同步并不是由 monitorenter 和 monitorexit 指令來實(shí)現(xiàn)同步的，而是由方法調(diào)用指令讀取運(yùn)行時(shí)常量池中方法的 ACC_SYNCHRONIZED 標(biāo)志來隱式實(shí)現(xiàn)的。

3.1、synchronized 代碼塊底層原理：

synchronized 同步語句塊的實(shí)現(xiàn)是顯式同步的，通過 monitorenter 和 monitorexit 指令實(shí)現(xiàn)，其中 monitorenter 指令指向同步代碼塊的開始位置，monitorexit 指令則指明同步代碼塊的結(jié)束位置，當(dāng)執(zhí)行 monitorenter 指令時(shí)，當(dāng)前線程將嘗試獲取 objectref（即對象鎖）所對應(yīng)的 monitor 的持有權(quán)：

• 當(dāng)對象鎖的 monitor 的進(jìn)入計(jì)數(shù)器為 0，那線程可以成功取得 monitor，并將計(jì)數(shù)器值設(shè)置為 1，取鎖成功。
• 如果當(dāng)前線程已經(jīng)擁有對象鎖的 monitor 的持有權(quán)，那它可以重入這個(gè) monitor，重入時(shí)計(jì)數(shù)器的值也會加1。
• 若其他線程已經(jīng)擁有對象鎖的 monitor 的所有權(quán)，那當(dāng)前線程將被阻塞，直到正在執(zhí)行線程執(zhí)行完畢，即monitorexit 指令被執(zhí)行，執(zhí)行線程將釋放 monitor 并設(shè)置計(jì)數(shù)器值為0，其他線程將有機(jī)會持有 monitor。

編譯器會確保無論方法通過何種方式完成，無論是正常結(jié)束還是異常結(jié)束，代碼中調(diào)用過的每條 monitorenter 指令都有執(zhí)行其對應(yīng) monitorexit 指令。為了保證在方法異常完成時(shí)，monitorenter 和 monitorexit 指令依然可以正確配對執(zhí)行，編譯器會自動產(chǎn)生一個(gè)異常處理器，這個(gè)異常處理器可處理所有的異常，它的目的就是用來執(zhí)行 monitorexit 指令。

3.2、synchronized 方法底層原理：

synchronized 同步方法的實(shí)現(xiàn)是隱式的，無需通過字節(jié)碼指令來控制，它是在方法調(diào)用和返回操作之中實(shí)現(xiàn)。JVM 可以通過方法常量池中的方法表結(jié)構(gòu)（method_info Structure）中的 ACC_SYNCHRONIZED 訪問標(biāo)志 判斷一個(gè)方法是否同步方法。當(dāng)方法調(diào)用時(shí)，調(diào)用指令將會檢查方法的 ACC_SYNCHRONIZED 訪問標(biāo)志是否被設(shè)置，如果設(shè)置了，標(biāo)識該方法是一個(gè)同步方法，執(zhí)行線程將先持有 monitor， 然后再執(zhí)行方法，最后再方法完成(無論是正常完成還是非正常完成)時(shí)釋放 monitor。在方法執(zhí)行期間，執(zhí)行線程持有了 monitor，其他任何線程都無法再獲得同一個(gè) monitor。

 如果一個(gè)同步方法執(zhí)行期間拋出了異常，并且在方法內(nèi)部無法處理此異常，那這個(gè)同步方法所持有的 monitor 將在異常拋到同步方法之外時(shí)自動釋放。

 4、JVM 對 synchronized 鎖的優(yōu)化：

在早期版本中，synchronized 屬于重量級鎖，效率低下，因?yàn)楸O(jiān)視器鎖 monitor 是依賴于操作系統(tǒng)的 Mutex 互斥量來實(shí)現(xiàn)的，操作系統(tǒng)實(shí)現(xiàn)線程之間的切換時(shí)需要從用戶態(tài)轉(zhuǎn)換到核心態(tài)，這個(gè)狀態(tài)之間的轉(zhuǎn)換需要相對比較長的時(shí)間，時(shí)間成本相對較高。在 JDK6 之后，synchronized 在 JVM 層面做了優(yōu)化，減少鎖的獲取和釋放所帶來的性能消耗，主要優(yōu)化方向有以下幾點(diǎn)：

4.1、鎖升級：偏向鎖->輕量級鎖->自旋鎖->重量級鎖

鎖的狀態(tài)總共有四種，無鎖狀態(tài)、偏向鎖、輕量級鎖和重量級鎖。隨著鎖的競爭，鎖可以從偏向鎖升級到輕量級鎖，再升級的重量級鎖，但是鎖的升級是單向的，只能從低到高升級，不會出現(xiàn)鎖的降級。重量級鎖基于從操作系統(tǒng)的互斥量實(shí)現(xiàn)的，而偏向鎖與輕量級鎖不同，他們是通過 CAS 并配合 Mark Word 一起實(shí)現(xiàn)的。

4.1.1、synchronized 的 Mark word 標(biāo)志位：

synchronized 使用的鎖對象是存儲在 Java 對象頭里的，那么 Java 對象頭是什么呢？對象實(shí)例分為：

• 對象頭
  • Mark Word
  • 指向類的指針
  • 數(shù)組長度
• 實(shí)例數(shù)據(jù)
• 對齊填充

其中，Mark Word 記錄了對象的 hashcode、分代年齡、鎖標(biāo)記位相關(guān)的信息，由于對象頭的信息是與對象自身定義的數(shù)據(jù)沒有關(guān)系的額外存儲成本，因此考慮到 JVM 的空間效率，Mark Word 被設(shè)計(jì)成為一個(gè)非固定的數(shù)據(jù)結(jié)構(gòu)，以便存儲更多有效的數(shù)據(jù)，它會根據(jù)對象本身的狀態(tài)復(fù)用自己的存儲空間，在 32位 JVM 中的長度是 32 位，具體信息如下圖所示：

4.1.2、鎖升級過程：

（1）偏向鎖：如果一個(gè)線程獲得了鎖，那么進(jìn)入偏向模式，當(dāng)這個(gè)線程再次請求鎖的時(shí)候，只需去對象頭的 Mark Word 中判斷偏向線程ID是否指向它自己，無需再進(jìn)入 monitor 中去競爭對象，這樣就省去了大量鎖申請的操作，適用于連續(xù)多次都是同一個(gè)線程申請相同的鎖的場景。偏向鎖只有初始化的時(shí)候需要一次 CAS 操作，但如果出現(xiàn)其他線程競爭鎖資源，那么偏向鎖就會被撤銷，并升級為輕量級鎖。

（2）輕量級鎖：不需要申請互斥量，允許短時(shí)間內(nèi)的鎖競爭，每次申請、釋放鎖都至少需要一次 CAS，適用于多個(gè)線程交替執(zhí)行同步代碼塊的場景

（3）自旋鎖：自旋鎖假設(shè)在不久將來，當(dāng)前的線程可以獲得鎖，因此在輕量級鎖升級成為重量級鎖之前，虛擬機(jī)會讓當(dāng)前想要獲取鎖的線程做幾個(gè)空循環(huán)，在經(jīng)過若干次循環(huán)后，如果得到鎖，就順利進(jìn)入臨界區(qū)，如果還不能獲得鎖，那就會將線程在操作系統(tǒng)層面掛起。

這種方式確實(shí)可以提升效率的，但是當(dāng)線程越來越多競爭很激烈時(shí)，占用 CPU 的時(shí)間變長會導(dǎo)致性能急劇下降，因此 JVM 對于自旋鎖有一定的次數(shù)限制，可能是50或者100次循環(huán)后就放棄，直接掛起線程，讓出CPU資源。

（4）自適應(yīng)自旋鎖：自適應(yīng)自旋解決的是 “鎖競爭時(shí)間不確定” 的問題，自適應(yīng)意味著自旋的時(shí)間不再固定了，而是由前一次在同一個(gè)鎖上的自旋時(shí)間及鎖的擁有者的狀態(tài)來決定。

• 如果在同一個(gè)鎖對象上，自旋等待剛剛成功獲得過鎖，并且持有鎖的線程正在運(yùn)行中，那么虛擬機(jī)就會認(rèn)為這次自旋也很有可能再次成功，進(jìn)而它將允許自旋等待持續(xù)相對更長的時(shí)間，比如100個(gè)循環(huán)。
• 相反的，如果對于某個(gè)鎖，自旋很少成功獲得過，那在以后要獲取這個(gè)鎖時(shí)將可能減少自旋時(shí)間甚至省略自旋過程，以避免浪費(fèi)處理器資源。

但自旋鎖帶來的副作用就是不公平的鎖機(jī)制：處于阻塞狀態(tài)的線程，并沒有辦法立刻競爭被釋放的鎖。然而，處于自旋狀態(tài)的線程，則很有可能優(yōu)先獲得這把鎖。

（5）重量級鎖：適用于多個(gè)線程同時(shí)執(zhí)行同步代碼塊的場景，且鎖競爭時(shí)間長。在這個(gè)狀態(tài)下，未搶到鎖的線程都會進(jìn)入到 Monitor 中并阻塞在 _WaitSet 集合中。

4.2、鎖消除：

消除鎖屬于編譯器對鎖的優(yōu)化，JIT 編譯時(shí)(可以簡單理解為當(dāng)某段代碼即將第一次被執(zhí)行時(shí)進(jìn)行編譯，又稱即時(shí)編譯)會使用逃逸分析技術(shù)，通過對運(yùn)行上下文的掃描，去除不可能存在共享資源競爭的鎖，通過這種方式消除沒有必要的鎖，可以節(jié)省毫無意義的請求鎖時(shí)間。

4.3、鎖粗化：

JIT 編譯器動態(tài)編譯時(shí)，如果發(fā)現(xiàn)幾個(gè)相鄰的同步塊使用的是同一個(gè)鎖實(shí)例，那么 JIT 編譯器將會把這幾個(gè)同步塊合并為一個(gè)大的同步塊，從而避免一個(gè)線程“反復(fù)申請、釋放同一個(gè)鎖“所帶來的性能開銷。

5、偏向鎖的廢除：

 在 JDK6 中引入的偏向鎖能夠減少競爭鎖定的開銷，使得 JVM 的性能得到了顯著改善，但是 JDK15 卻將決定將偏向鎖禁用，并在以后刪除它，這是為什么呢？主要有以下幾個(gè)原因：

• 為了支持偏向鎖使得代碼復(fù)雜度大幅度提升，并且對 HotSpot 的其他組件產(chǎn)生了影響，這種復(fù)雜性已成為理解代碼的障礙，也阻礙了對同步系統(tǒng)進(jìn)行重構(gòu)
• 在更高的 JDK 版本中針對多線程場景推出了性能更高的并發(fā)數(shù)據(jù)結(jié)構(gòu)，所以過去看到的性能提升，在現(xiàn)在看來已經(jīng)不那么明顯了。
• 圍繞線程池隊(duì)列和工作線程構(gòu)建的應(yīng)用程序，性能通常在禁用偏向鎖的情況下變得更好。

鎖升級過程詳細(xì)解析推薦閱讀：http://www.dbjr.com.cn/article/186708.htm

參考文章：//www.dbjr.com.cn/article/221033.htm

總結(jié)

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

最新評論