深入分析Synchronized原理(阿里面试题)
我們學(xué)習(xí)Java的時候，一遇到多線程情況就使用synchronized，相對于當(dāng)時的我們來說synchronized是這么的神奇而又強(qiáng)大，那個時候我們賦予它一個名字“同步”，也成為了我們解決多線程情況的百試不爽的良藥。但是，隨著學(xué)習(xí)的進(jìn)行我們知道在JDK1.5之前synchronized是一個重量級鎖，相對于j.u.c.Lock，它會顯得那么笨重，以至于我們認(rèn)為它不是那么的高效而慢慢摒棄它。
不過，隨著Javs SE 1.6對synchronized進(jìn)行的各種優(yōu)化后，synchronized并不會顯得那么重了。下面來一起探索synchronized的基本使用、實(shí)現(xiàn)機(jī)制、Java是如何對它進(jìn)行了優(yōu)化、鎖優(yōu)化機(jī)制、鎖的存儲結(jié)構(gòu)等升級過程。
1 基本使用
Synchronized是Java中解決并發(fā)問題的一種最常用的方法，也是最簡單的一種方法。Synchronized的作用主要有三個：
原子性：確保線程互斥的訪問同步代碼；
可見性：保證共享變量的修改能夠及時可見，其實(shí)是通過Java內(nèi)存模型中的 “對一個變量unlock操作之前，必須要同步到主內(nèi)存中；如果對一個變量進(jìn)行l(wèi)ock操作，則將會清空工作內(nèi)存中此變量的值，在執(zhí)行引擎使用此變量前，需要重新從主內(nèi)存中l(wèi)oad操作或assign操作初始化變量值” 來保證的；
有序性：有效解決重排序問題，即 “一個unlock操作先行發(fā)生(happen-before)于后面對同一個鎖的lock操作”；
從語法上講，Synchronized可以把任何一個非null對象作為"鎖"，在HotSpot JVM實(shí)現(xiàn)中，鎖有個專門的名字：對象監(jiān)視器（Object Monitor）。
Synchronized總共有三種用法：
當(dāng)synchronized作用在實(shí)例方法時，監(jiān)視器鎖（monitor）便是對象實(shí)例（this）；
當(dāng)synchronized作用在靜態(tài)方法時，監(jiān)視器鎖（monitor）便是對象的Class實(shí)例，因?yàn)镃lass數(shù)據(jù)存在于永久代，因此靜態(tài)方法鎖相當(dāng)于該類的一個全局鎖；
當(dāng)synchronized作用在某一個對象實(shí)例時，監(jiān)視器鎖（monitor）便是括號括起來的對象實(shí)例；
注意，synchronized 內(nèi)置鎖 是一種 對象鎖（鎖的是對象而非引用變量），作用粒度是對象 ，可以用來實(shí)現(xiàn)對 臨界資源的同步互斥訪問 ，是 可重入 的。其可重入最大的作用是避免死鎖，如：
子類同步方法調(diào)用了父類同步方法，如沒有可重入的特性，則會發(fā)生死鎖；
2 同步原理
數(shù)據(jù)同步需要依賴鎖，那鎖的同步又依賴誰？synchronized給出的答案是在軟件層面依賴JVM，而j.u.c.Lock給出的答案是在硬件層面依賴特殊的CPU指令。
當(dāng)一個線程訪問同步代碼塊時，首先是需要得到鎖才能執(zhí)行同步代碼，當(dāng)退出或者拋出異常時必須要釋放鎖，那么它是如何來實(shí)現(xiàn)這個機(jī)制的呢？我們先看一段簡單的代碼：
package com.paddx.test.concurrent;
public class SynchronizedDemo {
public void method() {
synchronized (this) {
System.out.println(“Method 1 start”);
}
}
}
查看反編譯后結(jié)果：
反編譯結(jié)果
monitorenter：每個對象都是一個監(jiān)視器鎖（monitor）。當(dāng)monitor被占用時就會處于鎖定狀態(tài)，線程執(zhí)行monitorenter指令時嘗試獲取monitor的所有權(quán)，過程如下：
如果monitor的進(jìn)入數(shù)為0，則該線程進(jìn)入monitor，然后將進(jìn)入數(shù)設(shè)置為1，該線程即為monitor的所有者；
如果線程已經(jīng)占有該monitor，只是重新進(jìn)入，則進(jìn)入monitor的進(jìn)入數(shù)加1；
如果其他線程已經(jīng)占用了monitor，則該線程進(jìn)入阻塞狀態(tài)，直到monitor的進(jìn)入數(shù)為0，再重新嘗試獲取monitor的所有權(quán)；
monitorexit：執(zhí)行monitorexit的線程必須是objectref所對應(yīng)的monitor的所有者。指令執(zhí)行時，monitor的進(jìn)入數(shù)減1，如果減1后進(jìn)入數(shù)為0，那線程退出monitor，不再是這個monitor的所有者。其他被這個monitor阻塞的線程可以嘗試去獲取這個 monitor 的所有權(quán)。
monitorexit指令出現(xiàn)了兩次，第1次為同步正常退出釋放鎖；第2次為發(fā)生異步退出釋放鎖；
通過上面兩段描述，我們應(yīng)該能很清楚的看出Synchronized的實(shí)現(xiàn)原理，Synchronized的語義底層是通過一個monitor的對象來完成，其實(shí)wait/notify等方法也依賴于monitor對象，這就是為什么只有在同步的塊或者方法中才能調(diào)用wait/notify等方法，否則會拋出java.lang.IllegalMonitorStateException的異常的原因。
再來看一下同步方法：
package com.paddx.test.concurrent;
public class SynchronizedMethod {
public synchronized void method() {
System.out.println(“Hello World!”);
}
}
查看反編譯后結(jié)果：
反編譯結(jié)果
從編譯的結(jié)果來看，方法的同步并沒有通過指令 monitorenter 和 monitorexit 來完成（理論上其實(shí)也可以通過這兩條指令來實(shí)現(xiàn)），不過相對于普通方法，其常量池中多了 ACC_SYNCHRONIZED 標(biāo)示符。JVM就是根據(jù)該標(biāo)示符來實(shí)現(xiàn)方法的同步的：
當(dāng)方法調(diào)用時，調(diào)用指令將會檢查方法的 ACC_SYNCHRONIZED 訪問標(biāo)志是否被設(shè)置，如果設(shè)置了，執(zhí)行線程將先獲取monitor，獲取成功之后才能執(zhí)行方法體，方法執(zhí)行完后再釋放monitor。在方法執(zhí)行期間，其他任何線程都無法再獲得同一個monitor對象。
兩種同步方式本質(zhì)上沒有區(qū)別，只是方法的同步是一種隱式的方式來實(shí)現(xiàn)，無需通過字節(jié)碼來完成。兩個指令的執(zhí)行是JVM通過調(diào)用操作系統(tǒng)的互斥原語mutex來實(shí)現(xiàn)，被阻塞的線程會被掛起、等待重新調(diào)度，會導(dǎo)致“用戶態(tài)和內(nèi)核態(tài)”兩個態(tài)之間來回切換，對性能有較大影響。
3 同步概念
3.1 Java對象頭
在JVM中，對象在內(nèi)存中的布局分為三塊區(qū)域：對象頭、實(shí)例數(shù)據(jù)和對齊填充。如下圖所示：
實(shí)例數(shù)據(jù)：存放類的屬性數(shù)據(jù)信息，包括父類的屬性信息；
對齊填充：由于虛擬機(jī)要求 對象起始地址必須是8字節(jié)的整數(shù)倍。填充數(shù)據(jù)不是必須存在的，僅僅是為了字節(jié)對齊；
對象頭：Java對象頭一般占有2個機(jī)器碼（在32位虛擬機(jī)中，1個機(jī)器碼等于4字節(jié)，也就是32bit，在64位虛擬機(jī)中，1個機(jī)器碼是8個字節(jié)，也就是64bit），但是 如果對象是數(shù)組類型，則需要3個機(jī)器碼，因?yàn)镴VM虛擬機(jī)可以通過Java對象的元數(shù)據(jù)信息確定Java對象的大小，但是無法從數(shù)組的元數(shù)據(jù)來確認(rèn)數(shù)組的大小，所以用一塊來記錄數(shù)組長度。
Synchronized用的鎖就是存在Java對象頭里的，那么什么是Java對象頭呢？Hotspot虛擬機(jī)的對象頭主要包括兩部分?jǐn)?shù)據(jù)：Mark Word（標(biāo)記字段）、Class Pointer（類型指針）。其中 Class Pointer是對象指向它的類元數(shù)據(jù)的指針，虛擬機(jī)通過這個指針來確定這個對象是哪個類的實(shí)例，Mark Word用于存儲對象自身的運(yùn)行時數(shù)據(jù)，它是實(shí)現(xiàn)輕量級鎖和偏向鎖的關(guān)鍵。 Java對象頭具體結(jié)構(gòu)描述如下：
Java對象頭結(jié)構(gòu)組成
Mark Word用于存儲對象自身的運(yùn)行時數(shù)據(jù)，如：哈希碼（HashCode）、GC分代年齡、鎖狀態(tài)標(biāo)志、線程持有的鎖、偏向線程 ID、偏向時間戳等。比如鎖膨脹就是借助Mark Word的偏向的線程ID 參考：JAVA鎖的膨脹過程和優(yōu)化(阿里) 阿里也經(jīng)常問的問題
下圖是Java對象頭 無鎖狀態(tài)下Mark Word部分的存儲結(jié)構(gòu)（32位虛擬機(jī)）：
Mark Word存儲結(jié)構(gòu)
對象頭信息是與對象自身定義的數(shù)據(jù)無關(guān)的額外存儲成本，但是考慮到虛擬機(jī)的空間效率，Mark Word被設(shè)計(jì)成一個非固定的數(shù)據(jù)結(jié)構(gòu)以便在極小的空間內(nèi)存存儲盡量多的數(shù)據(jù)，它會根據(jù)對象的狀態(tài)復(fù)用自己的存儲空間，也就是說，Mark Word會隨著程序的運(yùn)行發(fā)生變化，可能變化為存儲以下4種數(shù)據(jù)：
Mark Word可能存儲4種數(shù)據(jù)
在64位虛擬機(jī)下，Mark Word是64bit大小的，其存儲結(jié)構(gòu)如下：
64位Mark Word存儲結(jié)構(gòu)
對象頭的最后兩位存儲了鎖的標(biāo)志位，01是初始狀態(tài)，未加鎖，其對象頭里存儲的是對象本身的哈希碼，隨著鎖級別的不同，對象頭里會存儲不同的內(nèi)容。偏向鎖存儲的是當(dāng)前占用此對象的線程ID；而輕量級則存儲指向線程棧中鎖記錄的指針。從這里我們可以看到，“鎖”這個東西，可能是個鎖記錄+對象頭里的引用指針（判斷線程是否擁有鎖時將線程的鎖記錄地址和對象頭里的指針地址比較)，也可能是對象頭里的線程ID（判斷線程是否擁有鎖時將線程的ID和對象頭里存儲的線程ID比較）。
HotSpot虛擬機(jī)對象頭Mark Word
3.2 對象頭中Mark Word與線程中Lock Record
在線程進(jìn)入同步代碼塊的時候，如果此同步對象沒有被鎖定，即它的鎖標(biāo)志位是01，則虛擬機(jī)首先在當(dāng)前線程的棧中創(chuàng)建我們稱之為“鎖記錄（Lock Record）”的空間，用于存儲鎖對象的Mark Word的拷貝，官方把這個拷貝稱為Displaced Mark Word。整個Mark Word及其拷貝至關(guān)重要。
Lock Record是線程私有的數(shù)據(jù)結(jié)構(gòu)，每一個線程都有一個可用Lock Record列表，同時還有一個全局的可用列表。每一個被鎖住的對象Mark Word都會和一個Lock Record關(guān)聯(lián)（對象頭的MarkWord中的Lock Word指向Lock Record的起始地址），同時Lock Record中有一個Owner字段存放擁有該鎖的線程的唯一標(biāo)識（或者object mark word），表示該鎖被這個線程占用。如下圖所示為Lock Record的內(nèi)部結(jié)構(gòu)：
3.3 監(jiān)視器（Monitor）
任何一個對象都有一個Monitor與之關(guān)聯(lián)，當(dāng)且一個Monitor被持有后，它將處于鎖定狀態(tài)。Synchronized在JVM里的實(shí)現(xiàn)都是 基于進(jìn)入和退出Monitor對象來實(shí)現(xiàn)方法同步和代碼塊同步，雖然具體實(shí)現(xiàn)細(xì)節(jié)不一樣，但是都可以通過成對的MonitorEnter和MonitorExit指令來實(shí)現(xiàn)。
MonitorEnter指令：插入在同步代碼塊的開始位置，當(dāng)代碼執(zhí)行到該指令時，將會嘗試獲取該對象Monitor的所有權(quán)，即嘗試獲得該對象的鎖；
MonitorExit指令：插入在方法結(jié)束處和異常處，JVM保證每個MonitorEnter必須有對應(yīng)的MonitorExit；
那什么是Monitor？可以把它理解為 一個同步工具，也可以描述為 一種同步機(jī)制，它通常被 描述為一個對象。
與一切皆對象一樣，所有的Java對象是天生的Monitor，每一個Java對象都有成為Monitor的潛質(zhì)，因?yàn)樵贘ava的設(shè)計(jì)中 ，每一個Java對象自打娘胎里出來就帶了一把看不見的鎖，它叫做內(nèi)部鎖或者M(jìn)onitor鎖。
也就是通常說Synchronized的對象鎖，MarkWord鎖標(biāo)識位為10，其中指針指向的是Monitor對象的起始地址。在Java虛擬機(jī)（HotSpot）中，Monitor是由ObjectMonitor實(shí)現(xiàn)的，其主要數(shù)據(jù)結(jié)構(gòu)如下（位于HotSpot虛擬機(jī)源碼ObjectMonitor.hpp文件，C++實(shí)現(xiàn)的）：
ObjectMonitor() {
_header = NULL;
_count = 0; // 記錄個數(shù)
_waiters = 0,
_recursions = 0;
_object = NULL;
_owner = NULL;
_WaitSet = NULL; // 處于wait狀態(tài)的線程，會被加入到_WaitSet
_WaitSetLock = 0 ;
_Responsible = NULL ;
_succ = NULL ;
_cxq = NULL ;
FreeNext = NULL ;
_EntryList = NULL ; // 處于等待鎖block狀態(tài)的線程，會被加入到該列表
_SpinFreq = 0 ;
_SpinClock = 0 ;
OwnerIsThread = 0 ;
}
ObjectMonitor中有兩個隊(duì)列，_WaitSet 和 _EntryList，用來保存ObjectWaiter對象列表（ 每個等待鎖的線程都會被封裝成ObjectWaiter對象 ），_owner指向持有ObjectMonitor對象的線程，當(dāng)多個線程同時訪問一段同步代碼時：
首先會進(jìn)入 _EntryList 集合，當(dāng)線程獲取到對象的monitor后，進(jìn)入 _Owner區(qū)域并把monitor中的owner變量設(shè)置為當(dāng)前線程，同時monitor中的計(jì)數(shù)器count加1；
若線程調(diào)用 wait() 方法，將釋放當(dāng)前持有的monitor，owner變量恢復(fù)為null，count自減1，同時該線程進(jìn)入 WaitSet集合中等待被喚醒；
若當(dāng)前線程執(zhí)行完畢，也將釋放monitor（鎖）并復(fù)位count的值，以便其他線程進(jìn)入獲取monitor(鎖)；
同時，Monitor對象存在于每個Java對象的對象頭Mark Word中（存儲的指針的指向），Synchronized鎖便是通過這種方式獲取鎖的，也是為什么Java中任意對象可以作為鎖的原因，同時notify/notifyAll/wait等方法會使用到Monitor鎖對象，所以必須在同步代碼塊中使用。
監(jiān)視器Monitor有兩種同步方式：互斥與協(xié)作。多線程環(huán)境下線程之間如果需要共享數(shù)據(jù)，需要解決互斥訪問數(shù)據(jù)的問題，監(jiān)視器可以確保監(jiān)視器上的數(shù)據(jù)在同一時刻只會有一個線程在訪問。
什么時候需要協(xié)作？ 比如：
一個線程向緩沖區(qū)寫數(shù)據(jù)，另一個線程從緩沖區(qū)讀數(shù)據(jù)，如果讀線程發(fā)現(xiàn)緩沖區(qū)為空就會等待，當(dāng)寫線程向緩沖區(qū)寫入數(shù)據(jù)，就會喚醒讀線程，這里讀線程和寫線程就是一個合作關(guān)系。JVM通過Object類的wait方法來使自己等待，在調(diào)用wait方法后，該線程會釋放它持有的監(jiān)視器，直到其他線程通知它才有執(zhí)行的機(jī)會。一個線程調(diào)用notify方法通知在等待的線程，這個等待的線程并不會馬上執(zhí)行，而是要通知線程釋放監(jiān)視器后，它重新獲取監(jiān)視器才有執(zhí)行的機(jī)會。如果剛好喚醒的這個線程需要的監(jiān)視器被其他線程搶占，那么這個線程會繼續(xù)等待。Object類中的notifyAll方法可以解決這個問題，它可以喚醒所有等待的線程，總有一個線程執(zhí)行。
如上圖所示，一個線程通過1號門進(jìn)入Entry Set(入口區(qū))，如果在入口區(qū)沒有線程等待，那么這個線程就會獲取監(jiān)視器成為監(jiān)視器的Owner，然后執(zhí)行監(jiān)視區(qū)域的代碼。如果在入口區(qū)中有其它線程在等待，那么新來的線程也會和這些線程一起等待。線程在持有監(jiān)視器的過程中，有兩個選擇，一個是正常執(zhí)行監(jiān)視器區(qū)域的代碼，釋放監(jiān)視器，通過5號門退出監(jiān)視器；還有可能等待某個條件的出現(xiàn)，于是它會通過3號門到Wait Set（等待區(qū)）休息，直到相應(yīng)的條件滿足后再通過4號門進(jìn)入重新獲取監(jiān)視器再執(zhí)行。
注意：
當(dāng)一個線程釋放監(jiān)視器時，在入口區(qū)和等待區(qū)的等待線程都會去競爭監(jiān)視器，如果入口區(qū)的線程贏了，會從2號門進(jìn)入；如果等待區(qū)的線程贏了會從4號門進(jìn)入。只有通過3號門才能進(jìn)入等待區(qū)，在等待區(qū)中的線程只有通過4號門才能退出等待區(qū)，也就是說一個線程只有在持有監(jiān)視器時才能執(zhí)行wait操作，處于等待的線程只有再次獲得監(jiān)視器才能退出等待狀態(tài)。
4 鎖的優(yōu)化
從JDK5引入了現(xiàn)代操作系統(tǒng)新增加的CAS原子操作（ JDK5中并沒有對synchronized關(guān)鍵字做優(yōu)化，而是體現(xiàn)在J.U.C中，所以在該版本concurrent包有更好的性能 ），從JDK6開始，就對synchronized的實(shí)現(xiàn)機(jī)制進(jìn)行了較大調(diào)整，包括使用JDK5引進(jìn)的CAS自旋之外，還增加了自適應(yīng)的CAS自旋、鎖消除、鎖粗化、偏向鎖、輕量級鎖這些優(yōu)化策略。由于此關(guān)鍵字的優(yōu)化使得性能極大提高，同時語義清晰、操作簡單、無需手動關(guān)閉，所以推薦在允許的情況下盡量使用此關(guān)鍵字，同時在性能上此關(guān)鍵字還有優(yōu)化的空間。
鎖主要存在四種狀態(tài)，依次是：無鎖狀態(tài)、偏向鎖狀態(tài)、輕量級鎖狀態(tài)、重量級鎖狀態(tài)，鎖可以從偏向鎖升級到輕量級鎖，再升級的重量級鎖。但是鎖的升級是單向的，也就是說只能從低到高升級，不會出現(xiàn)鎖的降級。
在 JDK 1.6 中默認(rèn)是開啟偏向鎖和輕量級鎖的，可以通過-XX:-UseBiasedLocking來禁用偏向鎖。
4.1 自旋鎖
線程的阻塞和喚醒需要CPU從用戶態(tài)轉(zhuǎn)為核心態(tài)，頻繁的阻塞和喚醒對CPU來說是一件負(fù)擔(dān)很重的工作，勢必會給系統(tǒng)的并發(fā)性能帶來很大的壓力。同時我們發(fā)現(xiàn)在許多應(yīng)用上面，對象鎖的鎖狀態(tài)只會持續(xù)很短一段時間，為了這一段很短的時間頻繁地阻塞和喚醒線程是非常不值得的。
所以引入自旋鎖，何謂自旋鎖？
所謂自旋鎖，就是指當(dāng)一個線程嘗試獲取某個鎖時，如果該鎖已被其他線程占用，就一直循環(huán)檢測鎖是否被釋放，而不是進(jìn)入線程掛起或睡眠狀態(tài)。
自旋鎖適用于鎖保護(hù)的臨界區(qū)很小的情況，臨界區(qū)很小的話，鎖占用的時間就很短。自旋等待不能替代阻塞，雖然它可以避免線程切換帶來的開銷，但是它占用了CPU處理器的時間。如果持有鎖的線程很快就釋放了鎖，那么自旋的效率就非常好，反之，自旋的線程就會白白消耗掉處理的資源，它不會做任何有意義的工作，典型的占著茅坑不拉屎，這樣反而會帶來性能上的浪費(fèi)。所以說，自旋等待的時間（自旋的次數(shù)）必須要有一個限度，如果自旋超過了定義的時間仍然沒有獲取到鎖，則應(yīng)該被掛起。
自旋鎖在JDK 1.4.2中引入，默認(rèn)關(guān)閉，但是可以使用-XX:+UseSpinning開開啟，在JDK1.6中默認(rèn)開啟。同時自旋的默認(rèn)次數(shù)為10次，可以通過參數(shù)-XX:PreBlockSpin來調(diào)整。
如果通過參數(shù)-XX:PreBlockSpin來調(diào)整自旋鎖的自旋次數(shù)，會帶來諸多不便。假如將參數(shù)調(diào)整為10，但是系統(tǒng)很多線程都是等你剛剛退出的時候就釋放了鎖（假如多自旋一兩次就可以獲取鎖），是不是很尷尬。于是JDK1.6引入自適應(yīng)的自旋鎖，讓虛擬機(jī)會變得越來越聰明。
4.2 適應(yīng)性自旋鎖
JDK 1.6引入了更加聰明的自旋鎖，即自適應(yīng)自旋鎖。所謂自適應(yīng)就意味著自旋的次數(shù)不再是固定的，它是由前一次在同一個鎖上的自旋時間及鎖的擁有者的狀態(tài)來決定。那它如何進(jìn)行適應(yīng)性自旋呢？
線程如果自旋成功了，那么下次自旋的次數(shù)會更加多，因?yàn)樘摂M機(jī)認(rèn)為既然上次成功了，那么此次自旋也很有可能會再次成功，那么它就會允許自旋等待持續(xù)的次數(shù)更多。反之，如果對于某個鎖，很少有自旋能夠成功，那么在以后要或者這個鎖的時候自旋的次數(shù)會減少甚至省略掉自旋過程，以免浪費(fèi)處理器資源。
有了自適應(yīng)自旋鎖，隨著程序運(yùn)行和性能監(jiān)控信息的不斷完善，虛擬機(jī)對程序鎖的狀況預(yù)測會越來越準(zhǔn)確，虛擬機(jī)會變得越來越聰明。
4.3 鎖消除
為了保證數(shù)據(jù)的完整性，在進(jìn)行操作時需要對這部分操作進(jìn)行同步控制，但是在有些情況下，JVM檢測到不可能存在共享數(shù)據(jù)競爭，這是JVM會對這些同步鎖進(jìn)行鎖消除。
鎖消除的依據(jù)是逃逸分析的數(shù)據(jù)支持
如果不存在競爭，為什么還需要加鎖呢？所以鎖消除可以節(jié)省毫無意義的請求鎖的時間。變量是否逃逸，對于虛擬機(jī)來說需要使用數(shù)據(jù)流分析來確定，但是對于程序員來說這還不清楚么？在明明知道不存在數(shù)據(jù)競爭的代碼塊前加上同步嗎？但是有時候程序并不是我們所想的那樣？雖然沒有顯示使用鎖，但是在使用一些JDK的內(nèi)置API時，如StringBuffer、Vector、HashTable等，這個時候會存在隱形的加鎖操作。比如StringBuffer的append()方法，Vector的add()方法：
public void vectorTest(){
Vector vector = new Vector();
for(int i = 0 ; i < 10 ; i++){
vector.add(i + “”);
}
}
在運(yùn)行這段代碼時，JVM可以明顯檢測到變量vector沒有逃逸出方法vectorTest()之外，所以JVM可以大膽地將vector內(nèi)部的加鎖操作消除。
4.4 鎖粗化
在使用同步鎖的時候，需要讓同步塊的作用范圍盡可能小—僅在共享數(shù)據(jù)的實(shí)際作用域中才進(jìn)行同步，這樣做的目的是 為了使需要同步的操作數(shù)量盡可能縮小，如果存在鎖競爭，那么等待鎖的線程也能盡快拿到鎖。
在大多數(shù)的情況下，上述觀點(diǎn)是正確的。但是如果一系列的連續(xù)加鎖解鎖操作，可能會導(dǎo)致不必要的性能損耗，所以引入鎖粗話的概念。
鎖粗話概念比較好理解，就是將多個連續(xù)的加鎖、解鎖操作連接在一起，擴(kuò)展成一個范圍更大的鎖
如上面實(shí)例：
vector每次add的時候都需要加鎖操作，JVM檢測到對同一個對象（vector）連續(xù)加鎖、解鎖操作，會合并一個更大范圍的加鎖、解鎖操作，即加鎖解鎖操作會移到for循環(huán)之外。
4.5 偏向鎖
偏向鎖是JDK6中的重要引進(jìn)，因?yàn)镠otSpot作者經(jīng)過研究實(shí)踐發(fā)現(xiàn)，在大多數(shù)情況下，鎖不僅不存在多線程競爭，而且總是由同一線程多次獲得，為了讓線程獲得鎖的代價(jià)更低，引進(jìn)了偏向鎖。
偏向鎖是在單線程執(zhí)行代碼塊時使用的機(jī)制，如果在多線程并發(fā)的環(huán)境下（即線程A尚未執(zhí)行完同步代碼塊，線程B發(fā)起了申請鎖的申請），則一定會轉(zhuǎn)化為輕量級鎖或者重量級鎖。
在JDK5中偏向鎖默認(rèn)是關(guān)閉的，而到了JDK6中偏向鎖已經(jīng)默認(rèn)開啟。如果并發(fā)數(shù)較大同時同步代碼塊執(zhí)行時間較長，則被多個線程同時訪問的概率就很大，就可以使用參數(shù)-XX:-UseBiasedLocking來禁止偏向鎖(但這是個JVM參數(shù)，不能針對某個對象鎖來單獨(dú)設(shè)置)。
引入偏向鎖主要目的是：為了在沒有多線程競爭的情況下盡量減少不必要的輕量級鎖執(zhí)行路徑。因?yàn)檩p量級鎖的加鎖解鎖操作是需要依賴多次CAS原子指令的，而偏向鎖只需要在置換ThreadID的時候依賴一次CAS原子指令（由于一旦出現(xiàn)多線程競爭的情況就必須撤銷偏向鎖，所以偏向鎖的撤銷操作的性能損耗也必須小于節(jié)省下來的CAS原子指令的性能消耗）。
輕量級鎖是為了在線程交替執(zhí)行同步塊時提高性能，而偏向鎖則是在只有一個線程執(zhí)行同步塊時進(jìn)一步提高性能。
那么偏向鎖是如何來減少不必要的CAS操作呢？首先我們看下無競爭下鎖存在什么問題：
現(xiàn)在幾乎所有的鎖都是可重入的，即已經(jīng)獲得鎖的線程可以多次鎖住/解鎖監(jiān)視對象，按照之前的HotSpot設(shè)計(jì)，每次加鎖/解鎖都會涉及到一些CAS操作（比如對等待隊(duì)列的CAS操作），CAS操作會延遲本地調(diào)用，因此偏向鎖的想法是 一旦線程第一次獲得了監(jiān)視對象，之后讓監(jiān)視對象“偏向”這個線程，之后的多次調(diào)用則可以避免CAS操作，說白了就是置個變量，如果發(fā)現(xiàn)為true則無需再走各種加鎖/解鎖流程。
CAS為什么會引入本地延遲？這要從SMP（對稱多處理器）架構(gòu)說起，下圖大概表明了SMP的結(jié)構(gòu)：
SMP（對稱多處理器）架構(gòu)
其意思是 所有的CPU會共享一條系統(tǒng)總線（BUS），靠此總線連接主存。每個核都有自己的一級緩存，各核相對于BUS對稱分布，因此這種結(jié)構(gòu)稱為“對稱多處理器”。
而CAS的全稱為Compare-And-Swap，是一條CPU的原子指令，其作用是讓CPU比較后原子地更新某個位置的值，經(jīng)過調(diào)查發(fā)現(xiàn)，其實(shí)現(xiàn)方式是基于硬件平臺的匯編指令，就是說CAS是靠硬件實(shí)現(xiàn)的，JVM只是封裝了匯編調(diào)用，那些AtomicInteger類便是使用了這些封裝后的接口。
例如：Core1和Core2可能會同時把主存中某個位置的值Load到自己的L1 Cache中，當(dāng)Core1在自己的L1 Cache中修改這個位置的值時，會通過總線，使Core2中L1 Cache對應(yīng)的值“失效”，而Core2一旦發(fā)現(xiàn)自己L1 Cache中的值失效（稱為Cache命中缺失）則會通過總線從內(nèi)存中加載該地址最新的值，大家通過總線的來回通信稱為“Cache一致性流量”，因?yàn)榭偩€被設(shè)計(jì)為固定的“通信能力”，如果Cache一致性流量過大，總線將成為瓶頸。而當(dāng)Core1和Core2中的值再次一致時，稱為“Cache一致性”，從這個層面來說，鎖設(shè)計(jì)的終極目標(biāo)便是減少Cache一致性流量。
而CAS恰好會導(dǎo)致Cache一致性流量，如果有很多線程都共享同一個對象，當(dāng)某個Core CAS成功時必然會引起總線風(fēng)暴，這就是所謂的本地延遲，本質(zhì)上偏向鎖就是為了消除CAS，降低Cache一致性流量。
Cache一致性：
上面提到Cache一致性，其實(shí)是有協(xié)議支持的，現(xiàn)在通用的協(xié)議是MESI（最早由Intel開始支持），具體參考：http://en.wikipedia.org/wiki/MESI_protocol。
Cache一致性流量的例外情況：
其實(shí)也不是所有的CAS都會導(dǎo)致總線風(fēng)暴，這跟Cache一致性協(xié)議有關(guān)，具體參考：http://blogs.oracle.com/dave/entry/biased_locking_in_hotspot
NUMA(Non Uniform Memory Access Achitecture）架構(gòu)：
與SMP對應(yīng)還有非對稱多處理器架構(gòu)，現(xiàn)在主要應(yīng)用在一些高端處理器上，主要特點(diǎn)是沒有總線，沒有公用主存，每個Core有自己的內(nèi)存，針對這種結(jié)構(gòu)此處不做討論。
所以，當(dāng)一個線程訪問同步塊并獲取鎖時，會在對象頭和棧幀中的鎖記錄里存儲鎖偏向的線程ID，以后該線程進(jìn)入和退出同步塊時不需要花費(fèi)CAS操作來爭奪鎖資源，只需要檢查是否為偏向鎖、鎖標(biāo)識為以及ThreadID即可，處理流程如下：
檢測Mark Word是否為可偏向狀態(tài)，即是否為偏向鎖1，鎖標(biāo)識位為01；
若為可偏向狀態(tài)，則測試線程ID是否為當(dāng)前線程ID，如果是，則執(zhí)行步驟（5），否則執(zhí)行步驟（3）；
如果測試線程ID不為當(dāng)前線程ID，則通過CAS操作競爭鎖，競爭成功，則將Mark Word的線程ID替換為當(dāng)前線程ID，否則執(zhí)行線程（4）；
通過CAS競爭鎖失敗，證明當(dāng)前存在多線程競爭情況，當(dāng)?shù)竭_(dá)全局安全點(diǎn)，獲得偏向鎖的線程被掛起，偏向鎖升級為輕量級鎖，然后被阻塞在安全點(diǎn)的線程繼續(xù)往下執(zhí)行同步代碼塊；
執(zhí)行同步代碼塊；
偏向鎖的釋放采用了 一種只有競爭才會釋放鎖的機(jī)制，線程是不會主動去釋放偏向鎖，需要等待其他線程來競爭。偏向鎖的撤銷需要 等待全局安全點(diǎn)（這個時間點(diǎn)是上沒有正在執(zhí)行的代碼）。其步驟如下：
暫停擁有偏向鎖的線程；
判斷鎖對象是否還處于被鎖定狀態(tài)，否，則恢復(fù)到無鎖狀態(tài)（01），以允許其余線程競爭。是，則掛起持有鎖的當(dāng)前線程，并將指向當(dāng)前線程的鎖記錄地址的指針放入對象頭Mark Word，升級為輕量級鎖狀態(tài)（00），然后恢復(fù)持有鎖的當(dāng)前線程，進(jìn)入輕量級鎖的競爭模式；
注意：此處將 當(dāng)前線程掛起再恢復(fù)的過程中并沒有發(fā)生鎖的轉(zhuǎn)移，仍然在當(dāng)前線程手中，只是穿插了個 “將對象頭中的線程ID變更為指向鎖記錄地址的指針” 這么個事。
偏向鎖的獲取和釋放過程
4.6 輕量級鎖
引入輕量級鎖的主要目的是 在沒有多線程競爭的前提下，減少傳統(tǒng)的重量級鎖使用操作系統(tǒng)互斥量產(chǎn)生的性能消耗。當(dāng)關(guān)閉偏向鎖功能或者多個線程競爭偏向鎖導(dǎo)致偏向鎖升級為輕量級鎖，則會嘗試獲取輕量級鎖，其步驟如下：
在線程進(jìn)入同步塊時，如果同步對象鎖狀態(tài)為無鎖狀態(tài)（鎖標(biāo)志位為“01”狀態(tài)，是否為偏向鎖為“0”），虛擬機(jī)首先將在當(dāng)前線程的棧幀中建立一個名為鎖記錄（Lock Record）的空間，用于存儲鎖對象目前的Mark Word的拷貝，官方稱之為 Displaced Mark Word。此時線程堆棧與對象頭的狀態(tài)如下圖所示：
輕量級鎖CAS操作之前線程堆棧與對象的狀態(tài)
拷貝對象頭中的Mark Word復(fù)制到鎖記錄（Lock Record）中；
拷貝成功后，虛擬機(jī)將使用CAS操作嘗試將對象Mark Word中的Lock Word更新為指向當(dāng)前線程Lock Record的指針，并將Lock record里的owner指針指向object mark word。如果更新成功，則執(zhí)行步驟（4），否則執(zhí)行步驟（5）；
如果這個更新動作成功了，那么當(dāng)前線程就擁有了該對象的鎖，并且對象Mark Word的鎖標(biāo)志位設(shè)置為“00”，即表示此對象處于輕量級鎖定狀態(tài)，此時線程堆棧與對象頭的狀態(tài)如下圖所示
輕量級鎖CAS操作之后線程堆棧與對象的狀態(tài)
如果這個更新操作失敗了，虛擬機(jī)首先會檢查對象Mark Word中的Lock Word是否指向當(dāng)前線程的棧幀，如果是，就說明當(dāng)前線程已經(jīng)擁有了這個對象的鎖，那就可以直接進(jìn)入同步塊繼續(xù)執(zhí)行。否則說明多個線程競爭鎖，進(jìn)入自旋執(zhí)行（3），若自旋結(jié)束時仍未獲得鎖，輕量級鎖就要膨脹為重量級鎖，鎖標(biāo)志的狀態(tài)值變?yōu)椤?0”，Mark Word中存儲的就是指向重量級鎖（互斥量）的指針，當(dāng)前線程以及后面等待鎖的線程也要進(jìn)入阻塞狀態(tài)。
輕量級鎖的釋放也是通過CAS操作來進(jìn)行的，主要步驟如下：
通過CAS操作嘗試把線程中復(fù)制的Displaced Mark Word對象替換當(dāng)前的Mark Word；
如果替換成功，整個同步過程就完成了，恢復(fù)到無鎖狀態(tài)（01）；
如果替換失敗，說明有其他線程嘗試過獲取該鎖（此時鎖已膨脹），那就要在釋放鎖的同時，喚醒被掛起的線程；
對于輕量級鎖，其性能提升的依據(jù)是 “對于絕大部分的鎖，在整個生命周期內(nèi)都是不會存在競爭的”，如果打破這個依據(jù)則除了互斥的開銷外，還有額外的CAS操作，因此在有多線程競爭的情況下，輕量級鎖比重量級鎖更慢。
輕量級鎖的獲取和釋放過程
為什么升級為輕量鎖時要把對象頭里的Mark Word復(fù)制到線程棧的鎖記錄中呢？
因?yàn)樵谏暾垖ο箧i時 需要以該值作為CAS的比較條件，同時在升級到重量級鎖的時候，能通過這個比較判定是否在持有鎖的過程中此鎖被其他線程申請過，如果被其他線程申請了，則在釋放鎖的時候要喚醒被掛起的線程。
為什么會嘗試CAS不成功以及什么情況下會不成功？
CAS本身是不帶鎖機(jī)制的，其是通過比較而來。假設(shè)如下場景：線程A和線程B都在對象頭里的鎖標(biāo)識為無鎖狀態(tài)進(jìn)入，那么如線程A先更新對象頭為其鎖記錄指針成功之后，線程B再用CAS去更新，就會發(fā)現(xiàn)此時的對象頭已經(jīng)不是其操作前的對象HashCode了，所以CAS會失敗。也就是說，只有兩個線程并發(fā)申請鎖的時候會發(fā)生CAS失敗。
然后線程B進(jìn)行CAS自旋，等待對象頭的鎖標(biāo)識重新變回?zé)o鎖狀態(tài)或?qū)ο箢^內(nèi)容等于對象HashCode（因?yàn)檫@是線程B做CAS操作前的值），這也就意味著線程A執(zhí)行結(jié)束（參見后面輕量級鎖的撤銷，只有線程A執(zhí)行完畢撤銷鎖了才會重置對象頭），此時線程B的CAS操作終于成功了，于是線程B獲得了鎖以及執(zhí)行同步代碼的權(quán)限。如果線程A的執(zhí)行時間較長，線程B經(jīng)過若干次CAS時鐘沒有成功，則鎖膨脹為重量級鎖，即線程B被掛起阻塞、等待重新調(diào)度。
此處，如何理解“輕量級”？“輕量級”是相對于使用操作系統(tǒng)互斥量來實(shí)現(xiàn)的傳統(tǒng)鎖而言的。但是，首先需要強(qiáng)調(diào)一點(diǎn)的是，輕量級鎖并不是用來代替重量級鎖的，它的本意是在沒有多線程競爭的前提下，減少傳統(tǒng)的重量級鎖使用產(chǎn)生的性能消耗。
輕量級鎖所適應(yīng)的場景是線程交替執(zhí)行同步塊的情況，如果存在同一時間訪問同一鎖的情況，必然就會導(dǎo)致輕量級鎖膨脹為重量級鎖。
4.7 重量級鎖
Synchronized是通過對象內(nèi)部的一個叫做 監(jiān)視器鎖（Monitor）來實(shí)現(xiàn)的。但是監(jiān)視器鎖本質(zhì)又是依賴于底層的操作系統(tǒng)的Mutex Lock來實(shí)現(xiàn)的。而操作系統(tǒng)實(shí)現(xiàn)線程之間的切換這就需要從用戶態(tài)轉(zhuǎn)換到核心態(tài)，這個成本非常高，狀態(tài)之間的轉(zhuǎn)換需要相對比較長的時間，這就是為什么Synchronized效率低的原因。因此，這種依賴于操作系統(tǒng)Mutex Lock所實(shí)現(xiàn)的鎖我們稱之為 “重量級鎖”。
4.8 重量級鎖、輕量級鎖和偏向鎖之間轉(zhuǎn)換
重量級鎖、輕量級鎖和偏向鎖之間轉(zhuǎn)換
5 鎖的優(yōu)劣
各種鎖并不是相互代替的，而是在不同場景下的不同選擇，絕對不是說重量級鎖就是不合適的。每種鎖是只能升級，不能降級，即由偏向鎖->輕量級鎖->重量級鎖，而這個過程就是開銷逐漸加大的過程。
如果是單線程使用，那偏向鎖毫無疑問代價(jià)最小，并且它就能解決問題，連CAS都不用做，僅僅在內(nèi)存中比較下對象頭就可以了；
如果出現(xiàn)了其他線程競爭，則偏向鎖就會升級為輕量級鎖；
如果其他線程通過一定次數(shù)的CAS嘗試沒有成功，則進(jìn)入重量級鎖；
在第3種情況下進(jìn)入同步代碼塊就 要做偏向鎖建立、偏向鎖撤銷、輕量級鎖建立、升級到重量級鎖，最終還是得靠重量級鎖來解決問題，那這樣的代價(jià)就比直接用重量級鎖要大不少了。所以使用哪種技術(shù)，一定要看其所處的環(huán)境及場景，在絕大多數(shù)的情況下，偏向鎖是有效的，這是基于HotSpot作者發(fā)現(xiàn)的“大多數(shù)鎖只會由同一線程并發(fā)申請”的經(jīng)驗(yàn)規(guī)律。
總結(jié)
以上是生活随笔為你收集整理的深入分析Synchronized原理(阿里面试题)的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Lock与synchronized 的区
- 下一篇： 什么是分布式系统中的幂等性