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