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