一、Synchronized的基本使用
Synchronized是Java中解決併發問題的一種最常用的方法，也是最簡單的一種方法。Synchronized的作用主要有三個：（1）確保線程互斥的訪問同步代碼（2）保證共享變量的修改能夠及時可見（3）有效解決重排序問題。從語法上講，Synchronized總共有三種用法：
（1）修飾普通方法
（2）修飾靜態方法
（3）修飾代碼塊
二、Synchronized 原理
1.Synchronized修飾代碼塊
public class SynchronizedTest {
public void method(){
synchronized(this){
System.out.println("Method 1 start");
}
}
}
指令：javac SynchronizedTest.java
javap -c SynchronizedTest
反編譯結果：
關於這兩條指令的作用，我們直接參考JVM規範中描述：
monitorenter ：
Each object is associated with a monitor. A monitor is locked if and only if it has an owner. The thread that executes monitorenter attempts to gain ownership of the monitor associated with objectref, as follows:
• If the entry count of the monitor associated with objectref is zero, the thread enters the monitor and sets its entry count to one. The thread is then the owner of the monitor.
• If the thread already owns the monitor associated with objectref, it reenters the monitor, incrementing its entry count.
• If another thread already owns the monitor associated with objectref, the thread blocks until the monitor's entry count is zero, then tries again to gain ownership.
這段話的大概意思爲：
每個對象有一個監視器鎖（monitor）。當monitor被佔用時就會處於鎖定狀態，線程執行monitorenter指令時嘗試獲取monitor的所有權，過程如下：
1、如果monitor的進入數爲0，則該線程進入monitor，然後將進入數設置爲1，該線程即爲monitor的所有者。
2、如果線程已經佔有該monitor，只是重新進入，則進入monitor的進入數加1.
3.如果其他線程已經佔用了monitor，則該線程進入阻塞狀態，直到monitor的進入數爲0，再重新嘗試獲取monitor的所有權。
monitorexit：
The thread that executes monitorexit must be the owner of the monitor associated with the instance referenced by objectref.
The thread decrements the entry count of the monitor associated with objectref. If as a result the value of the entry count is zero, the thread exits the monitor and is no longer its owner. Other threads that are blocking to enter the monitor are allowed to attempt to do so.
這段話的大概意思爲：
執行monitorexit的線程必須是objectref所對應的monitor的所有者。
指令執行時，monitor的進入數減1，如果減1後進入數爲0，那線程退出monitor，不再是這個monitor的所有者。其他被這個monitor阻塞的線程可以嘗試去獲取這個 monitor 的所有權。
通過這兩段描述，我們應該能很清楚的看出Synchronized的實現原理，Synchronized的語義底層是通過一個monitor的對象來完成，其實wait/notify等方法也依賴於monitor對象，這就是爲什麼只有在同步的塊或者方法中才能調用wait/notify等方法，否則會拋出java.lang.IllegalMonitorStateException的異常的原因。
2.Synchronized修飾普通方法
public class SynchronizedTest {
public synchronized void method(){
System.out.println("Method 1 start");
}
}
指令：javac SynchronizedTest.java
javap -verbose SynchronizedTest.class
反編譯結果：
3.Synchronized修飾靜態方法
public class SynchronizedTest {
public static synchronized void method(){
System.out.println("Method 1 start");
}
}
指令：javac SynchronizedTest.java
javap -verbose SynchronizedTest.class
反編譯結果：
從反編譯的結果來看，方法的同步並沒有通過指令monitorenter和monitorexit來完成（理論上其實也可以通過這兩條指令來實現），不過相對於普通方法，其常量池中多了ACC_SYNCHRONIZED標示符。JVM就是根據該標示符來實現方法的同步的：當方法調用時，調用指令將會檢查方法的 ACC_SYNCHRONIZED 訪問標誌是否被設置，如果設置了，執行線程將先獲取monitor，獲取成功之後才能執行方法體，方法執行完後再釋放monitor。在方法執行期間，其他任何線程都無法再獲得同一個monitor對象。 其實本質上沒有區別，只是方法的同步是一種隱式的方式來實現。
同時我們還必須注意到的是在Java早期版本中，synchronized屬於重量級鎖，效率低下，因爲監視器鎖（monitor）是依賴於底層的操作系統的Mutex Lock來實現的，而操作系統實現線程之間的切換時需要從用戶態轉換到核心態，這個狀態之間的轉換需要相對比較長的時間，時間成本相對較高，這也是爲什麼早期的synchronized效率低的原因。慶幸的是在Java 6之後Java官方對從JVM層面對synchronized較大優化，所以現在的synchronized鎖效率也優化得很不錯了，Java 6之後，爲了減少獲得鎖和釋放鎖所帶來的性能消耗，引入了輕量級鎖和偏向鎖，接下來我們將簡單瞭解一下Java官方在JVM層面對synchronized鎖的優化。
三、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在默認情況下存儲着對象的HashCode、分代年齡、鎖標記位等以下是32位JVM的Mark Word默認存儲結構
| 鎖狀態 | 25bit | 4bit | 1bit是否是偏向鎖 | 2bit 鎖標誌位 |
|---|---|---|---|---|
| 無鎖狀態 | 對象HashCode | 對象分代年齡 | 0 | 01 |
由於對象頭的信息是與對象自身定義的數據沒有關係的額外存儲成本，因此考慮到JVM的空間效率，Mark Word 被設計成爲一個非固定的數據結構，以便存儲更多有效的數據，它會根據對象本身的狀態複用自己的存儲空間，如32位JVM下，除了上述列出的Mark Word默認存儲結構外，還有如下可能變化的結構：
其中輕量級鎖和偏向鎖是Java 6 對 synchronized 鎖進行優化後新增加的，稍後我們會簡要分析。這裏我們主要分析一下重量級鎖也就是通常說synchronized的對象鎖，鎖標識位爲10，其中指針指向的是monitor對象（也稱爲管程或監視器鎖）的起始地址。每個對象都存在着一個 monitor 與之關聯，對象與其 monitor 之間的關係有存在多種實現方式，如monitor可以與對象一起創建銷燬或當線程試圖獲取對象鎖時自動生成，但當一個 monitor 被某個線程持有後，它便處於鎖定狀態。在Java虛擬機(HotSpot)中，monitor是由ObjectMonitor實現的，其主要數據結構如下（位於HotSpot虛擬機源碼ObjectMonitor.hpp文件，C++實現的）
ObjectMonitor() {
_header = NULL;
_count = 0; //記錄個數
_waiters = 0,
_recursions = 0;
_object = NULL;
_owner = NULL;
_WaitSet = NULL; //處於wait狀態的線程，會被加入到_WaitSet
_WaitSetLock = 0 ;
_Responsible = NULL ;
_succ = NULL ;
_cxq = NULL ;
FreeNext = NULL ;
_EntryList = NULL ; //處於等待鎖block狀態的線程，會被加入到該列表
_SpinFreq = 0 ;
_SpinClock = 0 ;
OwnerIsThread = 0 ;
}
ObjectMonitor中有兩個隊列，_WaitSet 和 _EntryList，用來保存ObjectWaiter對象列表( 每個等待鎖的線程都會被封裝成ObjectWaiter對象)，_owner指向持有ObjectMonitor對象的線程，當多個線程同時訪問一段同步代碼時，首先會進入 _EntryList 集合，當線程獲取到對象的monitor 後進入 _Owner 區域並把monitor中的owner變量設置爲當前線程同時monitor中的計數器count加1，若線程調用 wait() 方法，將釋放當前持有的monitor，owner變量恢復爲null，count自減1，同時該線程進入 WaitSe t集合中等待被喚醒。若當前線程執行完畢也將釋放monitor(鎖)並復位變量的值，以便其他線程進入獲取monitor(鎖)。如下圖所示
由此看來，monitor對象存在於每個Java對象的對象頭中(存儲的指針的指向)，synchronized鎖便是通過這種方式獲取鎖的，也是爲什麼Java中任意對象可以作爲鎖的原因，同時也是notify/notifyAll/wait等方法存在於頂級對象Object中的原因。
四、Java虛擬機對synchronized的優化
鎖的狀態總共有四種，無鎖狀態、偏向鎖、輕量級鎖和重量級鎖。隨着鎖的競爭，鎖可以從偏向鎖升級到輕量級鎖，再升級的重量級鎖，但是鎖的升級是單向的，也就是說只能從低到高升級，不會出現鎖的降級，關於重量級鎖，前面我們已詳細分析過，下面我們將介紹偏向鎖和輕量級鎖以及JVM的其他優化手段，這裏並不打算深入到每個鎖的實現和轉換過程更多地是闡述Java虛擬機所提供的每個鎖的核心優化思想，畢竟涉及到具體過程比較繁瑣，如需瞭解詳細過程可以查閱《深入理解Java虛擬機原理》。
偏向鎖
偏向鎖是Java 6之後加入的新鎖，它是一種針對加鎖操作的優化手段，經過研究發現，在大多數情況下，鎖不僅不存在多線程競爭，而且總是由同一線程多次獲得，因此爲了減少同一線程獲取鎖(會涉及到一些CAS操作,耗時)的代價而引入偏向鎖。偏向鎖的核心思想是，如果一個線程獲得了鎖，那麼鎖就進入偏向模式，此時Mark Word 的結構也變爲偏向鎖結構，當這個線程再次請求鎖時，無需再做任何同步操作，即獲取鎖的過程，這樣就省去了大量有關鎖申請的操作，從而也就提供程序的性能。所以，對於沒有鎖競爭的場合，偏向鎖有很好的優化效果，畢竟極有可能連續多次是同一個線程申請相同的鎖。但是對於鎖競爭比較激烈的場合，偏向鎖就失效了，因爲這樣場合極有可能每次申請鎖的線程都是不相同的，因此這種場合下不應該使用偏向鎖，否則會得不償失，需要注意的是，偏向鎖失敗後，並不會立即膨脹爲重量級鎖，而是先升級爲輕量級鎖。下面我們接着瞭解輕量級鎖。
輕量級鎖
倘若偏向鎖失敗，虛擬機並不會立即升級爲重量級鎖，它還會嘗試使用一種稱爲輕量級鎖的優化手段(1.6之後加入的)，此時Mark Word 的結構也變爲輕量級鎖的結構。輕量級鎖能夠提升程序性能的依據是“對絕大部分的鎖，在整個同步週期內都不存在競爭”，注意這是經驗數據。需要了解的是，輕量級鎖所適應的場景是線程交替執行同步塊的場合，如果存在同一時間訪問同一鎖的場合，就會導致輕量級鎖膨脹爲重量級鎖。
自旋鎖
輕量級鎖失敗後，虛擬機爲了避免線程真實地在操作系統層面掛起，還會進行一項稱爲自旋鎖的優化手段。這是基於在大多數情況下，線程持有鎖的時間都不會太長，如果直接掛起操作系統層面的線程可能會得不償失，畢竟操作系統實現線程之間的切換時需要從用戶態轉換到核心態，這個狀態之間的轉換需要相對比較長的時間，時間成本相對較高，因此自旋鎖會假設在不久將來，當前的線程可以獲得鎖，因此虛擬機會讓當前想要獲取鎖的線程做幾個空循環(這也是稱爲自旋的原因)，一般不會太久，可能是50個循環或100循環，在經過若干次循環後，如果得到鎖，就順利進入臨界區。如果還不能獲得鎖，那就會將線程在操作系統層面掛起，這就是自旋鎖的優化方式，這種方式確實也是可以提升效率的。最後沒辦法也就只能升級爲重量級鎖了。
鎖消除
消除鎖是虛擬機另外一種鎖的優化，這種優化更徹底，Java虛擬機在JIT編譯時(可以簡單理解爲當某段代碼即將第一次被執行時進行編譯，又稱即時編譯)，通過對運行上下文的掃描，去除不可能存在共享資源競爭的鎖，通過這種方式消除沒有必要的鎖，可以節省毫無意義的請求鎖時間，如下StringBuffer的append是一個同步方法，但是在add方法中的StringBuffer屬於一個局部變量，並且不會被其他線程所使用，因此StringBuffer不可能存在共享資源競爭的情景，JVM會自動將其鎖消除。
public class StringBufferRemoveSync {
public void add(String str1, String str2) {
//StringBuffer是線程安全,由於sb只會在append方法中使用,不可能被其他線程引用
//因此sb屬於不可能共享的資源,JVM會自動消除內部的鎖
StringBuffer sb = new StringBuffer();
sb.append(str1).append(str2);
}
public static void main(String[] args) {
StringBufferRemoveSync rmsync = new StringBufferRemoveSync();
for (int i = 0; i < 10000000; i++) {
rmsync.add("abc", "123");
}
}
}
參考文章：
1.https://www.cnblogs.com/paddix/p/5367116.html
2.https://blog.csdn.net/javazejian/article/details/72828483