這篇文章帶你徹底理解synchronized

本人免費整理了Java高級資料，涵蓋了Java、Redis、MongoDB、MySQL、Zookeeper、Spring Cloud、Dubbo高并發分布式等教程，一共30G，需要自己領取。
傳送門：https://mp.weixin.qq.com/s/JzddfH-7yNudmkjT0IRL8Q

1. synchronized簡介
在學習知識前，我們先來看一個現象：

public?class?SynchronizedDemo?implements?Runnable?{
????private?static?int?count?=?0;

????public?static?void?main(String[]?args)?{
????????for?(int?i?=?0;?i?<?10;?i++)?{
????????????Thread?thread?=?new?Thread(new?SynchronizedDemo());
????????????thread.start();
????????}
????????try?{
????????????Thread.sleep(500);
????????}?catch?(InterruptedException?e)?{
????????????e.printStackTrace();
????????}
????????System.out.println("result:?"?+?count);
????}

????@Override
????public?void?run()?{
????????for?(int?i?=?0;?i?<?1000000;?i++)
????????????count++;
????}
}

開啟了10個線程，每個線程都累加了1000000次，如果結果正確的話自然而然總數就應該是10 * 1000000 = 10000000。可就運行多次結果都不是這個數，而且每次運行結果都不一樣。這是為什么了？有什么解決方案了？這就是我們今天要聊的事情。

在上一篇博文中我們已經了解了

Java內存模型以及happens-before規則zhuanlan.zhihu.com

的一些知識，并且已經知道出現線程安全的主要來源于JMM的設計，主要集中在主內存和線程的工作內存而導致的內存可見性問題，以及重排序導致的問題，進一步知道了happens-before規則。

線程運行時擁有自己的棧空間，會在自己的棧空間運行，如果多線程間沒有共享的數據也就是說多線程間并沒有協作完成一件事情，那么，多線程就不能發揮優勢，不能帶來巨大的價值。

那么共享數據的線程安全問題怎樣處理？很自然而然的想法就是每一個線程依次去讀寫這個共享變量，這樣就不會有任何數據安全的問題，因為每個線程所操作的都是當前最新的版本數據。那么，在java關鍵字synchronized就具有使每個線程依次排隊操作共享變量的功能。

很顯然，這種同步機制效率很低，但synchronized是其他并發容器實現的基礎，對它的理解也會大大提升對并發編程的感覺，從功利的角度來說，這也是面試高頻的考點。好了，下面，就來具體說說這個關鍵字。

2. synchronized實現原理
在java代碼中使用synchronized可是使用在代碼塊和方法中，根據Synchronized用的位置可以有這些使用場景：

如圖，synchronized可以用在方法上也可以使用在代碼塊中，其中方法是實例方法和靜態方法分別鎖的是該類的實例對象和該類的對象。

而使用在代碼塊中也可以分為三種，具體的可以看上面的表格。這里的需要注意的是：如果鎖的是類對象的話，盡管new多個實例對象，但他們仍然是屬于同一個類依然會被鎖住，即線程之間保證同步關系。

現在我們已經知道了怎樣synchronized了，看起來很簡單，擁有了這個關鍵字就真的可以在并發編程中得心應手了嗎？愛學的你，就真的不想知道synchronized底層是怎樣實現了嗎？

2.1 對象鎖（monitor）機制
現在我們來看看synchronized的具體底層實現。

先寫一個簡單的demo:

public?class?SynchronizedDemo?{
????public?static?void?main(String[]?args)?{
????????synchronized?(SynchronizedDemo.class)?{
????????}
????????method();
????}

????private?static?void?method()?{
????}
}

上面的代碼中有一個同步代碼塊，鎖住的是類對象，并且還有一個同步靜態方法，鎖住的依然是該類的類對象。編譯之后，切換到SynchronizedDemo.class的同級目錄之后，然后用javap -v SynchronizedDemo.class查看字節碼文件：

如圖，上面用黃.色高亮的部分就是需要注意的部分了，這也是添Synchronized關鍵字之后獨有的。執行同步代碼塊后首先要先執行monitorenter指令，退出的時候monitorexit指令。

通過分析之后可以看出，使用Synchronized進行同步，其關鍵就是必須要對對象的監視器monitor進行獲取，當線程獲取monitor后才能繼續往下執行，否則就只能等待。

而這個獲取的過程是互斥的，即同一時刻只有一個線程能夠獲取到monitor。

上面的demo中在執行完同步代碼塊之后緊接著再會去執行一個靜態同步方法，而這個方法鎖的對象依然就這個類對象，那么這個正在執行的線程還需要獲取該鎖嗎？答案是不必的，從上圖中就可以看出來，執行靜態同步方法的時候就只有一條monitorexit指令，并沒有monitorenter獲取鎖的指令。

這就是鎖的重入性，即在同一鎖程中，線程不需要再次獲取同一把鎖。Synchronized先天具有重入性。每個對象擁有一個計數器，當線程獲取該對象鎖后，計數器就會加一，釋放鎖后就會將計數器減一。

任意一個對象都擁有自己的監視器，當這個對象由同步塊或者這個對象的同步方法調用時，執行方法的線程必須先獲取該對象的監視器才能進入同步塊和同步方法，如果沒有獲取到監視器的線程將會被阻塞在同步塊和同步方法的入口處，進入到BLOCKED狀態（關于線程的狀態可以看

線程的狀態轉換以及基本操作zhuanlan.zhihu.com

下圖表現了對象，對象監視器，同步隊列以及執行線程狀態之間的關系：

該圖可以看出，任意線程對Object的訪問，首先要獲得Object的監視器，如果獲取失敗，該線程就進入同步狀態，線程狀態變為BLOCKED，當Object的監視器占有者釋放后，在同步隊列中得線程就會有機會重新獲取該監視器。

2.2 synchronized的happens-before關系
在上一篇文章中討論過

Java內存模型以及happens-before規則zhuanlan.zhihu.com

規則，抱著學以致用的原則我們現在來看一看Synchronized的happens-before規則，即監視器鎖規則：對同一個監視器的解鎖，happens-before于對該監視器的加鎖。

繼續來看代碼：

public?class?MonitorDemo?{
????private?int?a?=?0;

????public?synchronized?void?writer()?{?????//?1
????????a++;????????????????????????????????//?2
????}???????????????????????????????????????//?3

????public?synchronized?void?reader()?{????//?4
????????int?i?=?a;?????????????????????????//?5
????}??????????????????????????????????????//?6
}

該代碼的happens-before關系如圖所示：

在圖中每一個箭頭連接的兩個節點就代表之間的happens-before關系，黑色的是通過程序順序規則推導出來，紅色的為監視器鎖規則推導而出：線程A釋放鎖happens-before線程B加鎖，藍色的則是通過程序順序規則和監視器鎖規則推測出來happens-befor關系，通過傳遞性規則進一步推導的happens-before關系。

現在我們來重點關注2 happens-before 5，通過這個關系我們可以得出什么？

根據happens-before的定義中的一條:如果A happens-before B，則A的執行結果對B可見，并且A的執行順序先于B。

線程A先對共享變量A進行加一，由2 happens-before 5關系可知線程A的執行結果對線程B可見即線程B所讀取到的a的值為1。

2.3 鎖獲取和鎖釋放的內存語義
在上一篇文章提到過JMM核心為兩個部分：happens-before規則以及內存抽象模型。

我們分析完Synchronized的happens-before關系后，還是不太完整的，我們接下來看看基于java內存抽象模型的Synchronized的內存語義。
廢話不多說依舊先上圖。

從上圖可以看出，線程A會首先先從主內存中讀取共享變量a=0的值然后將該變量拷貝到自己的本地內存，進行加一操作后，再將該值刷新到主內存，整個過程即為線程A 加鎖-->執行臨界區代碼-->釋放鎖相對應的內存語義。

線程B獲取鎖的時候同樣會從主內存中共享變量a的值，這個時候就是最新的值1,然后將該值拷貝到線程B的工作內存中去，釋放鎖的時候同樣會重寫到主內存中。

從整體上來看，線程A的執行結果（a=1）對線程B是可見的，實現原理為：釋放鎖的時候會將值刷新到主內存中，其他線程獲取鎖時會強制從主內存中獲取最新的值。另外也驗證了2 happens-before 5，2的執行結果對5是可見的。

從橫向來看，這就像線程A通過主內存中的共享變量和線程B進行通信，A 告訴 B 我們倆的共享數據現在為1啦，這種線程間的通信機制正好吻合java的內存模型正好是共享內存的并發模型結構。

3. synchronized優化
通過上面的討論現在我們對Synchronized應該有所印象了，它最大的特征就是在同一時刻只有一個線程能夠獲得對象的監視器（monitor），從而進入到同步代碼塊或者同步方法之中，即表現為互斥性（排它性）。

這種方式肯定效率低下，每次只能通過一個線程，既然每次只能通過一個，這種形式不能改變的話，那么我們能不能讓每次通過的速度變快一點了。

打個比方，去收銀臺付款，之前的方式是，大家都去排隊，然后去紙幣付款收銀員找零，有的時候付款的時候在包里拿出錢包再去拿出錢，這個過程是比較耗時的，然后，支付寶解放了大家去錢包找錢的過程，現在只需要掃描下就可以完成付款了，也省去了收銀員跟你找零的時間的了。

同樣是需要排隊，但整個付款的時間大大縮短，是不是整體的效率變高速率變快了？這種優化方式同樣可以引申到鎖優化上，縮短獲取鎖的時間，偉大的科學家們也是這樣做的，令人欽佩，畢竟java是這么優秀的語言。

在聊到鎖的優化也就是鎖的幾種狀態前，有兩個知識點需要先關注：
（1）CAS操作?
（2）Java對象頭，這是理解下面知識的前提條件。

3.1 CAS操作
3.1.1 什么是CAS?
使用鎖時，線程獲取鎖是一種悲觀鎖策略，即假設每一次執行臨界區代碼都會產生沖突，所以當前線程獲取到鎖的時候同時也會阻塞其他線程獲取該鎖。

而CAS操作（又稱為無鎖操作）是一種樂觀鎖策略，它假設所有線程訪問共享資源的時候不會出現沖突，既然不會出現沖突自然而然就不會阻塞其他線程的操作。

因此，線程就不會出現阻塞停頓的狀態。

那么，如果出現沖突了怎么辦？無鎖操作是使用**CAS(compare and swap)**又叫做比較交換來鑒別線程是否出現沖突，出現沖突就重試當前操作直到沒有沖突為止。

3.1.2 CAS的操作過程
CAS比較交換的過程可以通俗的理解為CAS(V,O,N)，包含三個值分別為：V 內存地址存放的實際值；O 預期的值（舊值）；N 更新的新值。

當V和O相同時，也就是說舊值和內存中實際的值相同表明該值沒有被其他線程更改過，即該舊值O就是目前來說最新的值了，自然而然可以將新值N賦值給V。

反之，V和O不相同，表明該值已經被其他線程改過了則該舊值O不是最新版本的值了，所以不能將新值N賦給V，返回V即可。

當多個線程使用CAS操作一個變量是，只有一個線程會成功，并成功更新，其余會失敗。失敗的線程會重新嘗試，當然也可以選擇掛起線程CAS的實現需要硬件指令集的支撐，在JDK1.5后虛擬機才可以使用處理器提供的CMPXCHG指令實現。
Synchronized VS CAS

元老級的Synchronized(未優化前)最主要的問題是：在存在線程競爭的情況下會出現線程阻塞和喚醒鎖帶來的性能問題，因為這是一種互斥同步（阻塞同步）。

而CAS并不是武斷的間線程掛起，當CAS操作失敗后會進行一定的嘗試，而非進行耗時的掛起喚醒的操作，因此也叫做非阻塞同步。這是兩者主要的區別。

3.1.3 CAS的應用場景
在J.U.C包中利用CAS實現類有很多，可以說是支撐起整個concurrency包的實現，在Lock實現中會有CAS改變state變量，在atomic包中的實現類也幾乎都是用CAS實現，關于這些具體的實現場景在之后會詳細聊聊，現在有個印象就好了。

3.1.4 CAS的問題
1. ABA問題?因為CAS會檢查舊值有沒有變化，這里存在這樣一個有意思的問題。比如一個舊值A變為了成B，然后再變成A，剛好在做CAS時檢查發現舊值并沒有變化依然為A，但是實際上的確發生了變化。

解決方案可以沿襲數據庫中常用的樂觀鎖方式，添加一個版本號可以解決。原來的變化路徑A->B->A就變成了1A->2B->3C。

java這么優秀的語言，當然在java 1.5后的atomic包中提供了AtomicStampedReference來解決ABA問題，解決思路就是這樣的。

2. 自旋時間過長
使用CAS時非阻塞同步，也就是說不會將線程掛起，會自旋（無非就是一個死循環）進行下一次嘗試，如果這里自旋時間過長對性能是很大的消耗。如果JVM能支持處理器提供的pause指令，那么在效率上會有一定的提升。

3. 只能保證一個共享變量的原子操作
當對一個共享變量執行操作時CAS能保證其原子性，如果對多個共享變量進行操作,CAS就不能保證其原子性。

有一個解決方案是利用對象整合多個共享變量，即一個類中的成員變量就是這幾個共享變量。然后將這個對象做CAS操作就可以保證其原子性。atomic中提供了AtomicReference來保證引用對象之間的原子性。

3.2 Java對象頭
在同步的時候是獲取對象的monitor,即獲取到對象的鎖。那么對象的鎖怎么理解？無非就是類似對對象的一個標志，那么這個標志就是存放在Java對象的對象頭。

Java對象頭里的Mark Word里默認的存放的對象的Hashcode,分代年齡和鎖標記位。32為JVM Mark Word默認存儲結構為（注:java對象頭以及下面的鎖狀態變化摘自《java并發編程的藝術》一書，該書我認為寫的足夠好，就沒在自己組織語言班門弄斧了）：

如圖在Mark Word會默認存放hasdcode，年齡值以及鎖標志位等信息。
Java SE 1.6中，鎖一共有4種狀態，級別從低到高依次是：無鎖狀態、偏向鎖狀態、輕量級鎖狀態和重量級鎖狀態，這幾個狀態會隨著競爭情況逐漸升級。

鎖可以升級但不能降級，意味著偏向鎖升級成輕量級鎖后不能降級成偏向鎖。這種鎖升級卻不能降級的策略，目的是為了提高獲得鎖和釋放鎖的效率。對象的MarkWord變化為下圖：

3.2 偏向鎖
HotSpot的作者經過研究發現，大多數情況下，鎖不僅不存在多線程競爭，而且總是由同一線程多次獲得，為了讓線程獲得鎖的代價更低而引入了偏向鎖。

偏向鎖的獲取
當一個線程訪問同步塊并獲取鎖時，會在對象頭和棧幀中的鎖記錄里存儲鎖偏向的線程ID，以后該線程在進入和退出同步塊時不需要進行CAS操作來加鎖和解鎖，只需簡單地測試一下對象頭的Mark Word里是否存儲著指向當前線程的偏向鎖。

如果測試成功，表示線程已經獲得了鎖。如果測試失敗，則需要再測試一下Mark Word中偏向鎖的標識是否設置成1（表示當前是偏向鎖）：如果沒有設置，則使用CAS競爭鎖；如果設置了，則嘗試使用CAS將對象頭的偏向鎖指向當前線程

偏向鎖的撤銷
偏向鎖使用了一種等到競爭出現才釋放鎖的機制，所以當其他線程嘗試競爭偏向鎖時，持有偏向鎖的線程才會釋放鎖。

如圖，偏向鎖的撤銷，需要等待全局安全點（在這個時間點上沒有正在執行的字節碼）。它會首先暫停擁有偏向鎖的線程，然后檢查持有偏向鎖的線程是否活著，如果線程不處于活動狀態，則將對象頭設置成無鎖狀態；
如果線程仍然活著，擁有偏向鎖的棧會被執行，遍歷偏向對象的鎖記錄，棧中的鎖記錄和對象頭的Mark Word要么重新偏向于其他線程，要么恢復到無鎖或者標記對象不適合作為偏向鎖，最后喚醒暫停的線程。

下圖線程1展示了偏向鎖獲取的過程，線程2展示了偏向鎖撤銷的過程。

如何關閉偏向鎖
偏向鎖在Java 6和Java 7里是默認啟用的，但是它在應用程序啟動幾秒鐘之后才激活，如有必要可以使用JVM參數來關閉延遲：-XX:BiasedLockingStartupDelay=0。

如果你確定應用程序里所有的鎖通常情況下處于競爭狀態，可以通過JVM參數關閉偏向鎖：-XX:-UseBiasedLocking=false，那么程序默認會進入輕量級鎖狀態

3.3 輕量級鎖
加鎖
線程在執行同步塊之前，JVM會先在當前線程的棧楨中創建用于存儲鎖記錄的空間，并將對象頭中的Mark Word復制到鎖記錄中，官方稱為Displaced Mark Word。然后線程嘗試使用CAS將對象頭中的Mark Word替換為指向鎖記錄的指針。

如果成功，當前線程獲得鎖，如果失敗，表示其他線程競爭鎖，當前線程便嘗試使用自旋來獲取鎖。

解鎖
輕量級解鎖時，會使用原子的CAS操作將Displaced Mark Word替換回到對象頭，如果成功，則表示沒有競爭發生。如果失敗，表示當前鎖存在競爭，鎖就會膨脹成重量級鎖。下圖是兩個線程同時爭奪鎖，導致鎖膨脹的流程圖。

因為自旋會消耗CPU，為了避免無用的自旋（比如獲得鎖的線程被阻塞住了），一旦鎖升級成重量級鎖，就不會再恢復到輕量級鎖狀態。當鎖處于這個狀態下，其他線程試圖獲取鎖時，都會被阻塞住，當持有鎖的線程釋放鎖之后會喚醒這些線程，被喚醒的線程就會進行新一輪的奪鎖之爭。

3.5 各種鎖的比較

4. 一個例子
經過上面的理解，我們現在應該知道了該怎樣解決了。

更正后的代碼為：

public?class?SynchronizedDemo?implements?Runnable?{
????private?static?int?count?=?0;

????public?static?void?main(String[]?args)?{
????????for?(int?i?=?0;?i?<?10;?i++)?{
????????????Thread?thread?=?new?Thread(new?SynchronizedDemo());
????????????thread.start();
????????}
????????try?{
????????????Thread.sleep(500);
????????}?catch?(InterruptedException?e)?{
????????????e.printStackTrace();
????????}
????????System.out.println("result:?"?+?count);
????}

????@Override
????public?void?run()?{
????????synchronized?(SynchronizedDemo.class)?{
????????????for?(int?i?=?0;?i?<?1000000;?i++)
????????????????count++;
????????}
????}
}

開啟十個線程，每個線程在原值上累加1000000次，最終正確的結果為10X1000000=10000000，這里能夠計算出正確的結果是因為在做累加操作時使用了同步代碼塊，這樣就能保證每個線程所獲得共享變量的值都是當前最新的值，如果不使用同步的話，就可能會出現A線程累加后，而B線程做累加操作有可能是使用原來的就值，即“臟值”。

這樣，就導致最終的計算結果不是正確的。而使用Syncnized就可能保證內存可見性，保證每個線程都是操作的最新值。這里只是一個示例性的demo，聰明的你，還有其他辦法嗎？