synchronized底層實現原理

      基於進入和退出管程（Monitor）對象實現，不管顯式（Monitorenter Monitorexit）仍是隱式都是如此。同步方法並非由monitorenter和monitorexit指令來實現同步的，而是由方法調用指令讀取運行時常量池中的ACC_SYNCHRONIZED標誌來隱式實現的。

    在JVM中，對象在內存中的佈局分爲三塊區域：對象頭、實例數據和對齊填充。

實例變量：存放類的屬性數據信息，包括父類的屬性信息，若是是數組的實例部分還包括數組的長度，這部份內存按4字節對齊。

填充數據：因爲虛擬機要求對象起始地址必須是8字節的整數倍。填充數據不是必須存在的，僅僅是爲了字節對齊，這點了解便可

 

而對於頂部，則是Java頭對象，它實現synchronized的鎖對象的基礎，這點咱們重點分析它，通常而言，synchronized使用的鎖對象是存儲在Java對象頭裏的，jvm中採用2個字來存儲對象頭(若是對象是數組則會分配3個字，多出來的1個字記錄的是數組長度)，其主要結構是由Mark Word 和 Class Metadata Address 組成

虛擬機位數	頭對象結構	說明
32/64bit	Mark Word	存儲對象的hashCode、鎖信息或分代年齡或GC標誌等信息
32/64bit	Class Metadata Address	類型指針指向對象的類元數據，JVM經過這個指針肯定該對象是哪一個類的實例。

Mark Word組成：

鎖狀態	25bit	4bit	1bit是不是偏向鎖	2bit 鎖標誌位
無鎖狀態	對象HashCode	對象分代年齡	0	01

因爲對象頭的信息是與對象自身定義的數據沒有關係的額外存儲成本，所以考慮到JVM的空間效率，Mark Word 被設計成爲一個非固定的數據結構，以便存儲更多有效的數據，它會根據對象自己的狀態複用本身的存儲空間

如32位JVM下，除了上述列出的Mark Word默認存儲結構外，還有以下可能變化的結構

鎖狀態	25bit		4bit	1bit	2bit
	23bit	2bit		是不是偏向鎖	鎖標誌位
輕量級鎖	指向棧中鎖記錄的指針				00
重量級鎖	指向互斥量（重量級鎖）的指針				10
GC標記	空				11
偏向鎖	線程ID	Epoch	對象分代年齡	1	01

其中輕量級鎖和偏向鎖是Java 6 對 synchronized 鎖進行優化後新增長的，稍後咱們會簡要分析。這裏咱們主要分析一下重量級鎖也就是一般說synchronized的對象鎖，鎖標識位爲10，其中指針指向的是monitor對象（也稱爲管程或監視器鎖）的起始地址。每一個對象都存在着一個 monitor 與之關聯，對象與其 monitor 之間的關係有存在多種實現方式，如monitor能夠與對象一塊兒建立銷燬或當線程試圖獲取對象鎖時自動生成，但當一個 monitor 被某個線程持有後，它便處於鎖定狀態。在Java虛擬機(HotSpot)中，monitor是由ObjectMonitor實現的

鎖的狀態總共有四種，無鎖狀態、偏向鎖、輕量級鎖和重量級鎖。隨着鎖的競爭，鎖能夠從偏向鎖升級到輕量級鎖，再升級的重量級鎖，可是鎖的升級是單向的，也就是說只能從低到高升級，不會出現鎖的降級

 

偏向鎖

偏向鎖是Java 6以後加入的新鎖，它是一種針對加鎖操做的優化手段，通過研究發現，在大多數狀況下，鎖不只不存在多線程競爭，並且老是由同一線程屢次得到，所以爲了減小同一線程獲取鎖(會涉及到一些CAS操做,耗時)的代價而引入偏向鎖。偏向鎖的核心思想是，若是一個線程得到了鎖，那麼鎖就進入偏向模式，此時Mark Word 的結構也變爲偏向鎖結構，當這個線程再次請求鎖時，無需再作任何同步操做，即獲取鎖的過程，這樣就省去了大量有關鎖申請的操做，從而也就提供程序的性能。因此，對於沒有鎖競爭的場合，偏向鎖有很好的優化效果，畢竟極有可能連續屢次是同一個線程申請相同的鎖。可是對於鎖競爭比較激烈的場合，偏向鎖就失效了，由於這樣場合極有可能每次申請鎖的線程都是不相同的，所以這種場合下不該該使用偏向鎖，不然會得不償失，須要注意的是，偏向鎖失敗後，並不會當即膨脹爲重量級鎖，而是先升級爲輕量級鎖。下面咱們接着瞭解輕量級鎖。

 

 

輕量級鎖

假若偏向鎖失敗，虛擬機並不會當即升級爲重量級鎖，它還會嘗試使用一種稱爲輕量級鎖的優化手段(1.6以後加入的)，此時Mark Word 的結構也變爲輕量級鎖的結構。輕量級鎖可以提高程序性能的依據是「對絕大部分的鎖，在整個同步週期內都不存在競爭」，注意這是經驗數據。須要瞭解的是，輕量級鎖所適應的場景是線程交替執行同步塊的場合，若是存在同一時間訪問同一鎖的場合，就會致使輕量級鎖膨脹爲重量級鎖。

 

 

自旋鎖

輕量級鎖失敗後，虛擬機爲了不線程真實地在操做系統層面掛起，還會進行一項稱爲自旋鎖的優化手段。這是基於在大多數狀況下，線程持有鎖的時間都不會太長，若是直接掛起操做系統層面的線程可能會得不償失，畢竟操做系統實現線程之間的切換時須要從用戶態轉換到核心態，這個狀態之間的轉換須要相對比較長的時間，時間成本相對較高，所以自旋鎖會假設在不久未來，當前的線程能夠得到鎖，所以虛擬機會讓當前想要獲取鎖的線程作幾個空循環(這也是稱爲自旋的緣由)，通常不會過久，多是50個循環或100循環，在通過若干次循環後，若是獲得鎖，就順利進入臨界區。若是還不能得到鎖，那就會將線程在操做系統層面掛起，這就是自旋鎖的優化方式，這種方式確實也是能夠提高效率的。最後沒辦法也就只能升級爲重量級鎖了。

鎖消除

消除鎖是虛擬機另一種鎖的優化，這種優化更完全，Java虛擬機在JIT編譯時(能夠簡單理解爲當某段代碼即將第一次被執行時進行編譯，又稱即時編譯)，經過對運行上下文的掃描，去除不可能存在共享資源競爭的鎖，經過這種方式消除沒有必要的鎖，能夠節省毫無心義的請求鎖時間，以下StringBuffer的append是一個同步方法，可是在add方法中的StringBuffer屬於一個局部變量，而且不會被其餘線程所使用，所以StringBuffer不可能存在共享資源競爭的情景，JVM會自動將其鎖消除。

synchronized的可重入性

從互斥鎖的設計上來講，當一個線程試圖操做一個由其餘線程持有的對象鎖的臨界資源時，將會處於阻塞狀態，但當一個線程再次請求本身持有對象鎖的臨界資源時，這種狀況屬於重入鎖，請求將會成功，在java中synchronized是基於原子性的內部鎖機制，是可重入的，所以在一個線程調用synchronized方法的同時在其方法體內部調用該對象另外一個synchronized方法，也就是說一個線程獲得一個對象鎖後再次請求該對象鎖，是容許的，這就是synchronized的可重入性。