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è)：

1. 原子性：確保線程互斥的訪問同步代碼榜掌；
2. 可見性：保證共享變量的修改能夠及時(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操作初始化變量值” 來保證的；
3. 有序性：有效解決重排序問題综芥，即 “一個(gè)unlock操作先行發(fā)生(happen-before)于后面對同一個(gè)鎖的lock操作”丽蝎；

從語法上講，Synchronized可以把任何一個(gè)非null對象作為"鎖"膀藐，在HotSpot JVM實(shí)現(xiàn)中屠阻，鎖有個(gè)專門的名字：對象監(jiān)視器（Object Monitor）。

Synchronized總共有三種用法：

1. 當(dāng)synchronized作用在實(shí)例方法時(shí)额各，監(jiān)視器鎖（monitor）便是對象實(shí)例（this）栏笆；
2. 當(dāng)synchronized作用在靜態(tài)方法時(shí)，監(jiān)視器鎖（monitor）便是對象的Class實(shí)例臊泰，因?yàn)镃lass數(shù)據(jù)存在于永久代蛉加，因此靜態(tài)方法鎖相當(dāng)于該類的一個(gè)全局鎖；
3. 當(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ī)制的呢？我們先看一段簡單的代碼：

package com.paddx.test.concurrent;

public class SynchronizedDemo {
    public void method() {
        synchronized (this) {
            System.out.println("Method 1 start");
        }
    }
}

查看反編譯后結(jié)果：

反編譯結(jié)果

1. monitorenter：每個(gè)對象都是一個(gè)監(jiān)視器鎖（monitor）趋距。當(dāng)monitor被占用時(shí)就會處于鎖定狀態(tài)粒氧，線程執(zhí)行monitorenter指令時(shí)嘗試獲取monitor的所有權(quán)，過程如下：

   1. 如果monitor的進(jìn)入數(shù)為0节腐，則該線程進(jìn)入monitor外盯，然后將進(jìn)入數(shù)設(shè)置為1，該線程即為monitor的所有者铜跑；
   2. 如果線程已經(jīng)占有該monitor门怪，只是重新進(jìn)入骡澈，則進(jìn)入monitor的進(jìn)入數(shù)加1锅纺；
   3. 如果其他線程已經(jīng)占用了monitor，則該線程進(jìn)入阻塞狀態(tài)肋殴，直到monitor的進(jìn)入數(shù)為0囤锉，再重新嘗試獲取monitor的所有權(quán)；

2. 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的異常的原因舍哄。

再來看一下同步方法：

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)用時(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ù)和對齊填充冠息。如下圖所示：

1. 實(shí)例數(shù)據(jù)：存放類的屬性數(shù)據(jù)信息，包括父類的屬性信息孕索；
2. 對齊填充：由于虛擬機(jī)要求 對象起始地址必須是8字節(jié)的整數(shù)倍逛艰。填充數(shù)據(jù)不是必須存在的，僅僅是為了字節(jié)對齊搞旭；
3. 對象頭：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)：

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)。

1. MonitorEnter指令：插入在同步代碼塊的開始位置垦梆，當(dāng)代碼執(zhí)行到該指令時(shí)匹颤，將會嘗試獲取該對象Monitor的所有權(quán)，即嘗試獲得該對象的鎖托猩；
2. 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í)：

1. 首先會進(jìn)入 _EntryList 集合烙样，當(dāng)線程獲取到對象的monitor后冯遂，進(jìn)入 _Owner區(qū)域并把monitor中的owner變量設(shè)置為當(dāng)前線程，同時(shí)monitor中的計(jì)數(shù)器count加1谒获；
2. 若線程調(diào)用 wait() 方法蛤肌，將釋放當(dāng)前持有的monitor，owner變量恢復(fù)為null批狱，count自減1裸准，同時(shí)該線程進(jìn)入 WaitSet集合中等待被喚醒；
3. 若當(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í)語義清晰、操作簡單天试、無需手動(dòng)關(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()方法：

public void vectorTest(){
    Vector<String> vector = new Vector<String>();
    for(int i = 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即可择同，處理流程如下：

1. 檢測Mark Word是否為可偏向狀態(tài)，即是否為偏向鎖1净宵，鎖標(biāo)識位為01敲才；
2. 若為可偏向狀態(tài)，則測試線程ID是否為當(dāng)前線程ID择葡，如果是紧武，則執(zhí)行步驟（5），否則執(zhí)行步驟（3）敏储；
3. 如果測試線程ID不為當(dāng)前線程ID阻星，則通過CAS操作競爭鎖，競爭成功已添，則將Mark Word的線程ID替換為當(dāng)前線程ID妥箕，否則執(zhí)行線程（4）；
4. 通過CAS競爭鎖失敗酝碳，證明當(dāng)前存在多線程競爭情況矾踱，當(dāng)?shù)竭_(dá)全局安全點(diǎn)，獲得偏向鎖的線程被掛起疏哗，偏向鎖升級為輕量級鎖呛讲，然后被阻塞在安全點(diǎn)的線程繼續(xù)往下執(zhí)行同步代碼塊；
5. 執(zhí)行同步代碼塊；

偏向鎖的釋放采用了 一種只有競爭才會釋放鎖的機(jī)制贝搁，線程是不會主動(dòng)去釋放偏向鎖吗氏，需要等待其他線程來競爭。偏向鎖的撤銷需要 等待全局安全點(diǎn)（這個(gè)時(shí)間點(diǎn)是上沒有正在執(zhí)行的代碼）雷逆。其步驟如下：

1. 暫停擁有偏向鎖的線程弦讽；
2. 判斷鎖對象是否還處于被鎖定狀態(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)致偏向鎖升級為輕量級鎖，則會嘗試獲取輕量級鎖佃迄，其步驟如下：

1. 在線程進(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)

2. 拷貝對象頭中的Mark Word復(fù)制到鎖記錄（Lock Record）中吼肥；

3. 拷貝成功后，虛擬機(jī)將使用CAS操作嘗試將對象Mark Word中的Lock Word更新為指向當(dāng)前線程Lock Record的指針麻车，并將Lock record里的owner指針指向object mark word缀皱。如果更新成功，則執(zhí)行步驟（4）动猬，否則執(zhí)行步驟（5）啤斗；

4. 如果這個(gè)更新動(dòng)作成功了，那么當(dāng)前線程就擁有了該對象的鎖赁咙，并且對象Mark Word的鎖標(biāo)志位設(shè)置為“00”钮莲，即表示此對象處于輕量級鎖定狀態(tài)免钻，此時(shí)線程堆棧與對象頭的狀態(tài)如下圖所示：

   輕量級鎖CAS操作之后線程堆棧與對象的狀態(tài)

5. 如果這個(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)行的，主要步驟如下：

1. 通過CAS操作嘗試把線程中復(fù)制的Displaced Mark Word對象替換當(dāng)前的Mark Word步鉴；
2. 如果替換成功，整個(gè)同步過程就完成了璃哟，恢復(fù)到無鎖狀態(tài)（01）氛琢；
3. 如果替換失敗，說明有其他線程嘗試過獲取該鎖（此時(shí)鎖已膨脹）随闪，那就要在釋放鎖的同時(shí)阳似，喚醒被掛起的線程；

對于輕量級鎖铐伴，其性能提升的依據(jù)是 “對于絕大部分的鎖撮奏，在整個(gè)生命周期內(nèi)都是不會存在競爭的”，如果打破這個(gè)依據(jù)則除了互斥的開銷外当宴，還有額外的CAS操作畜吊，因此在有多線程競爭的情況下，輕量級鎖比重量級鎖更慢户矢。

輕量級鎖的獲取和釋放過程

1. 為什么升級為輕量鎖時(shí)要把對象頭里的Mark Word復(fù)制到線程棧的鎖記錄中呢玲献？

   因?yàn)樵谏暾垖ο箧i時(shí) 需要以該值作為CAS的比較條件，同時(shí)在升級到重量級鎖的時(shí)候梯浪，能通過這個(gè)比較判定是否在持有鎖的過程中此鎖被其他線程申請過捌年，如果被其他線程申請了，則在釋放鎖的時(shí)候要喚醒被掛起的線程挂洛。

2. 為什么會嘗試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è)過程就是開銷逐漸加大的過程怔锌。

1. 如果是單線程使用寥粹，那偏向鎖毫無疑問代價(jià)最小，并且它就能解決問題埃元，連CAS都不用做涝涤，僅僅在內(nèi)存中比較下對象頭就可以了；
2. 如果出現(xiàn)了其他線程競爭岛杀，則偏向鎖就會升級為輕量級鎖阔拳；
3. 如果其他線程通過一定次數(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ò)展資料

1. JVM源碼分析之synchronized實(shí)現(xiàn)
2. 自旋鎖拓轻、排隊(duì)自旋鎖、MCS鎖经伙、CLH鎖
3. 深入理解Java并發(fā)之synchronized實(shí)現(xiàn)原理