前言：

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

 1、synchronized 的作用：

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

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

2、synchronized 底層語義原理：

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

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

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

3.1、synchronized 代碼塊底層原理：

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

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

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

3.2、synchronized 方法底層原理：

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

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

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

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

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

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

4.1.1、synchronized 的 Mark word 標志位：

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

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

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

4.1.2、鎖升級過程：

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

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

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

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

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

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

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

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

4.2、鎖消除：

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

4.3、鎖粗化：

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

5、偏向鎖的廢除：

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

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

鎖升級過程詳細解析推薦閱讀：http://m.dhdzp.com/article/186708.htm

參考文章：//m.dhdzp.com/article/221033.htm

總結(jié)

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