我們都知道 synchronized 關(guān)鍵字能實(shí)現(xiàn)線程安全，但是你知道這背后的原理是什么嗎？今天我們就來講一講 synchronized 實(shí)現(xiàn)線程同步背后的原因，以及相關(guān)的鎖優(yōu)化策略吧。

背后的原理

synchronized 關(guān)鍵字經(jīng)過編譯之后，會在同步塊的前后分別形成 monitorenter 和 monitorexit 這兩個字節(jié)碼指令，這兩個字節(jié)碼只需要一個指明一個要鎖定或解鎖的對象。如果 Java 程序中指明了對象參數(shù)，那么就用這個對象作為鎖。

如果沒有指定，那么就根據(jù) synchronized 修飾的是實(shí)例方法還是類方法，去拿對應(yīng)的對象實(shí)例或 Class 對象來作為鎖對象。因此我們可以知道，synchronized 關(guān)鍵字實(shí)現(xiàn)線程同步的背后，其實(shí)是 Java 虛擬機(jī)規(guī)范對于 monitorenter 和 monitorexit 的定義。

在 Java 虛擬機(jī)規(guī)范對 monitorenter 和 monitorexit 的行為描述中，有兩點(diǎn)需要特別注意。

synchronized 同步塊對同一條線程是可沖入的，也就是不會出現(xiàn)自己把自己鎖死的問題。

同步課在已進(jìn)入的線程執(zhí)行完之前，會阻塞后面其他線程的進(jìn)入。

synchronized 關(guān)鍵字在 JDK1.6 版本之前，是通過操作系統(tǒng)的 Mutex Lock 來實(shí)現(xiàn)同步的。而操作系統(tǒng)的 Mutex Lock 是操作系統(tǒng)級別的方法，需要切換到內(nèi)核態(tài)來執(zhí)行。這就需要從用戶態(tài)轉(zhuǎn)換到內(nèi)核態(tài)中，因此我們說 synchronized 同步是重量級的操作。

鎖優(yōu)化

在 JDK1.6 版本中，HotSpot 虛擬機(jī)開發(fā)團(tuán)隊(duì)花了很大的精力去實(shí)現(xiàn)各種鎖優(yōu)化技術(shù)，如：適應(yīng)性自旋、鎖消除、鎖粗話、偏向鎖、輕量級鎖等。其中最重要的是：自旋鎖、輕量級鎖、偏向鎖這三個，我們重點(diǎn)講這三個鎖優(yōu)化。

自旋鎖與自適應(yīng)自旋

對于重量級的同步操作來說，最大的消耗其實(shí)是內(nèi)核態(tài)與用戶態(tài)的切換。很很多時候，對于共享數(shù)據(jù)的操作時間可能很短，比內(nèi)核態(tài)切換到用戶態(tài)這個耗時還短。

于是有人就想：如果有多個線程并發(fā)去獲取鎖的時候，如果能讓后面那個請求鎖的線程「稍等一下」，不放棄 CPU 的執(zhí)行時間，看看持有鎖的線程是否會很快釋放鎖。為了讓線程等待，我們只需讓線程執(zhí)行一個忙循環(huán)（自旋），這項(xiàng)技術(shù)就是所謂的自旋鎖。 從理論上來看，如果所有線程都很快地獲取鎖、釋放鎖，那么自旋鎖是可以帶來較大的性能提升的。自旋鎖在 JDK 1.4.2 中就已經(jīng)引入，默認(rèn)自旋 10 次。但自旋鎖默認(rèn)是關(guān)閉的，在 JDK 1.6 中才改為默認(rèn)開啟了。

自旋等待雖然避免了線程切換的開銷，但還是要占用處理器的時間。如果鎖被占用的時間段，自旋等待的效果就會非常好。但如果鎖被長時間占用，那么自旋的線程就會白白消耗處理器的資源，從而帶來性能上的浪費(fèi)。

為了解決特殊情況下自旋鎖的性能消耗問題，在 JDK1.6 的時候引入了自適應(yīng)的自旋鎖。 自適應(yīng)意味著自旋時間不再固定，而是由前一次在同一個鎖上的自旋時間及鎖的擁有者狀態(tài)決定。如果在同一鎖對象上，自旋等待剛剛成功獲得過鎖，那么虛擬機(jī)認(rèn)為這次自旋也很有可能再次成功，進(jìn)而允許線程自旋更長時間，例如自旋 100 個循環(huán)。

但如果對于某個鎖，自旋很少成功獲得過。那虛擬機(jī)為了避免浪費(fèi) CPU 資源，有可能省略掉自旋過程。有了自旋鎖，隨著程序運(yùn)行和性能監(jiān)控信息的不斷完善，虛擬機(jī)對鎖的狀態(tài)預(yù)測就越準(zhǔn)，虛擬機(jī)也會變得越來越聰明。

輕量級鎖

輕量級鎖是 JDK1.6 加入的新型鎖機(jī)制，名字中的「輕量級」是相對于操作系統(tǒng)互斥量這個重量級鎖而言的。輕量級鎖誕生的原因，是由于對于絕大部分的鎖而言，整個同步周期都不存在競爭。如果沒有競爭的話，那就沒必要使用重量級鎖了，于是就誕生了輕量級鎖來提高效率。

對于輕量級鎖來說，其同步的流程如下：

在代碼進(jìn)入同步塊的時候，如果此同步對象沒有被鎖定（鎖標(biāo)志位為 01 狀態(tài)），那么虛擬機(jī)會在當(dāng)前線程的棧幀中建立一個名為鎖記錄（Lock Record）的空間，用于存儲鎖對象目前的 Mark Word 拷貝。

虛擬機(jī)將使用 CAS 操作嘗試將對象的 Mark Word 更新為指向 Lock Record 的指針。如果更新動作成功了，那么線程就泳衣了該對象的鎖，并且對象 Mark Word 的鎖標(biāo)志位就變成了 00，表示此對象處于輕量級鎖定狀態(tài)。

簡單地說，輕量級鎖的同步流程可以總結(jié)為：使用 CAS 操作，在線程棧幀與鎖對象建立雙向的指針。

在沒有線程競爭的情況下，輕量級鎖使用 CAS 自旋操作避免了使用互斥量的開銷，提高了效率。但如果存在鎖競爭，除了互斥量的開銷外，還額外發(fā)生了 CAS 操作。因此在有競爭的情況下，輕量級鎖會比傳統(tǒng)的重量級鎖更慢。

偏向鎖

偏向鎖是 JDK1.6 中引入的一項(xiàng)優(yōu)化，它的意思是這個鎖會偏向于第一個獲得它的線程。如果在接下來的執(zhí)行過程中，該鎖沒有被其他線程獲取，則持有偏向鎖的線程將永遠(yuǎn)不需要再進(jìn)行同步。 對于偏向鎖來說，其同步流程如下所示：

• 假設(shè)當(dāng)前虛擬機(jī)啟動了偏向鎖，那么當(dāng)鎖對象第一次被線程獲取的時候，虛擬機(jī)將會把對象的鎖標(biāo)志位設(shè)置為 01，偏向鎖位設(shè)置為 1。同時使用 CAS 操作將線程 ID 記錄在對象的 MarkWord 之中。如果 CAS 操作成功，那么持有偏向鎖的線程進(jìn)入鎖對應(yīng)的同步塊時，虛擬機(jī)將不再進(jìn)行任何同步操作。
• 當(dāng)有另外一個線程嘗試去獲取這個鎖時，根據(jù)鎖對象目前是否處于鎖定狀態(tài)，將其恢復(fù)到未鎖定（01）或輕量級鎖定（00）狀態(tài)。隨后的同步操作，就向上面介紹的輕量級鎖那樣執(zhí)行。

可以看到偏向鎖還是需要做一些 CAS 操作，但是對比起輕量級鎖來說，其要設(shè)置的內(nèi)容大大減少了，因此也提高了一些效率。

偏向鎖可以提高帶有同步但無競爭的程序性能。 它同樣是一個帶有效益權(quán)衡（Trade Off）性質(zhì)的優(yōu)化，也就是說，它并不一定總是對程序運(yùn)行有利，如果程序中大多數(shù)的鎖總是被多個不同的線程訪問，那偏向模式就是多余的。

優(yōu)化后的鎖獲取流程

經(jīng)過 JDK1.6 的優(yōu)化，synchronized 同步機(jī)制的流程變成了：

• 首先，synchronized 會嘗試使用偏向鎖的方式去競爭鎖資源，如果能夠競爭到偏向鎖，表示加鎖成功直接返回。
• 如果競爭鎖失敗，說明當(dāng)前鎖已經(jīng)偏向了其他線程。需要將鎖升級到輕量級鎖，在輕量級鎖狀態(tài)下，競爭鎖的線程根據(jù)自適應(yīng)自旋次數(shù)去嘗試搶占鎖資源。
• 如果在輕量級鎖狀態(tài)下還是沒有競爭到鎖，就只能升級到重量級鎖。在重量級鎖狀態(tài)下，沒有競爭到鎖的線程就會被阻塞。處于鎖等待狀態(tài)的線程需要等待獲得鎖的線程來觸發(fā)喚醒。

上面的鎖獲取流程，可以用如下的示意圖來表示：

Java 對象鎖競爭流程

總結(jié)

本文首先簡單講解了 synchronized 關(guān)鍵字實(shí)現(xiàn)同步的原理，其實(shí)是通過 Java 虛擬機(jī)規(guī)范對于 monitorenter 和 monitorexit 的支持，從而使得 synchronized 能夠?qū)崿F(xiàn)同步。而 synchronized 同步本質(zhì)上是通過操作系統(tǒng)的 mutex 鎖來實(shí)現(xiàn)的。由于操作操作系統(tǒng) mutex 鎖太過于消耗資源，因此在 JDK1.6 后 HotSpot 虛擬機(jī)做了一系列的鎖優(yōu)化，其中最重要的便是：自旋鎖、輕量級鎖、偏向鎖。這三個鎖的誕生原因，以及提升的點(diǎn)如下表所示。

從上面表格可以看到，自旋鎖、輕量級鎖、偏向鎖，他們的優(yōu)化是逐漸深入的。

• 對于重量級鎖來說，自旋鎖減少了互斥量的內(nèi)核、用戶態(tài)切換開銷。
• 對于自旋鎖來說，輕量級鎖減少了自旋等待的時間。
• 對于輕量級鎖來說，偏向于減少了多余的對象復(fù)制操作。