一、Synchronized 的基本使用
Synchronized 的作用主要有三個：
- 確保線程互斥的訪問同步代碼
- 保證共享變量的修改能夠及時可見
- 有效解決重排序問題
從語法上講，Synchronized 總共有三種用法：
- 修飾實例方法，作用於當前對象實例加鎖，進入同步代碼前要獲得當前對象實例的鎖。
- 修飾靜態方法，作用於當前類對象加鎖，進入同步代碼前要獲得當前類對象的鎖 。也就是給當前類加鎖，會作用於類的所有對象實例，因爲靜態成員不屬於任何一個實例對象，是類成員（ static 表明這是該類的一個靜態資源，不管new了多少個對象，只有一份，所以對該類的所有對象都加了鎖）。所以如果一個線程A調用一個實例對象的非靜態 synchronized 方法，而線程B需要調用這個實例對象所屬類的靜態 synchronized 方法，是允許的，不會發生互斥現象，因爲訪問靜態 synchronized 方法佔用的鎖是當前類的鎖，而訪問非靜態 synchronized 方法佔用的鎖是當前實例對象鎖。
- 修飾代碼塊，指定加鎖對象，對給定對象加鎖，進入同步代碼庫前要獲得給定對象的鎖。 和 synchronized 方法一樣，synchronized(this)代碼塊也是鎖定當前對象的。synchronized 關鍵字加到 static 靜態方法和 synchronized(class)代碼塊上都是是給 Class 類上鎖。這裏再提一下：synchronized關鍵字加到非 static 靜態方法上是給對象實例上鎖。另外需要注意的是：儘量不要使用 synchronized(String a) 因爲JVM中，字符串常量池具有緩衝功能！
二、Synchronized 的升級過程
Synchronized的升級順序是 無鎖-->偏向鎖-->輕量級鎖-->重量級鎖，順序不可逆。（Java SE 1.6中爲了減少獲得鎖和釋放鎖帶來的性能消耗而引入的偏向鎖和輕量級鎖）
三、Synchronized 關鍵字底層原理
synchronized 關鍵字底層原理屬於 JVM 層面。
1. synchronized 同步語句塊的情況
public class SynchronizedDemo {
public void method() {
synchronized (this) {
System.out.println("synchronized 代碼塊");
}
}
}
synchronized 同步語句塊的實現使用的是 monitorenter 和 monitorexit 指令，其中 monitorenter 指令指向同步代碼塊的開始位置，monitorexit 指令則指明同步代碼塊的結束位置。 當執行 monitorenter 指令時，線程試圖獲取鎖也就是獲取 monitor(monitor對象存在於每個Java對象的對象頭中，synchronized 鎖便是通過這種方式獲取鎖的，也是爲什麼Java中任意對象可以作爲鎖的原因) 的持有權.當計數器爲0則可以成功獲取，獲取後將鎖計數器設爲1也就是加1。相應的在執行 monitorexit 指令後，將鎖計數器設爲0，表明鎖被釋放。如果獲取對象鎖失敗，那當前線程就要阻塞等待，直到鎖被另外一個線程釋放爲止。
2. synchronized 修飾方法的的情況
public class SynchronizedDemo2 {
public synchronized void method() {
System.out.println("synchronized 方法");
}
}
synchronized 修飾的方法並沒有 monitorenter 指令和 monitorexit 指令，取得代之的確實是 ACC_SYNCHRONIZED 標識，該標識指明瞭該方法是一個同步方法，JVM 通過該 ACC_SYNCHRONIZED 訪問標誌來辨別一個方法是否聲明爲同步方法，從而執行相應的同步調用。
在 Java 早期版本中，synchronized 屬於重量級鎖，效率低下，因爲監視器鎖（monitor）是依賴於底層的操作系統的互斥鎖來實現的，Java 的線程是映射到操作系統的原生線程之上的。如果要掛起或者喚醒一個線程，都需要操作系統幫忙完成，而操作系統實現線程之間的切換時需要從用戶態轉換到內核態，這個狀態之間的轉換需要相對比較長的時間，時間成本相對較高，這也是爲什麼早期的 synchronized 效率低的原因。但在 Java 6 之後 Java 官方對從 JVM 層面對synchronized 較大優化，所以現在的 synchronized 鎖效率也優化得很不錯了。JDK1.6對鎖的實現引入了大量的優化，如自旋鎖、適應性自旋鎖、鎖消除、鎖粗化、偏向鎖、輕量級鎖等技術來減少鎖操作的開銷。
四、JDK1.6 之後的底層優化
JDK1.6 對鎖的實現引入了大量的優化，如偏向鎖、輕量級鎖、自旋鎖、適應性自旋鎖、鎖消除、鎖粗化等技術來減少鎖操作的開銷。
鎖主要存在四中狀態，依次是：無鎖狀態、偏向鎖狀態、輕量級鎖狀態、重量級鎖狀態，他們會隨着競爭的激烈而逐漸升級。注意鎖可以升級不可降級，這種策略是爲了提高獲得鎖和釋放鎖的效率。
自旋鎖在 JDK1.6 之前其實就已經引入了，不過是默認關閉的，需要通過--XX:+UseSpinning參數來開啓。JDK1.6及1.6之後，就改爲默認開啓的了。需要注意的是：自旋等待不能完全替代阻塞，因爲它還是要佔用處理器時間。如果鎖被佔用的時間短，那麼效果當然就很好了！反之，相反！自旋等待的時間必須要有限度。如果自旋超過了限定次數任然沒有獲得鎖，就應該掛起線程。自旋次數的默認值是10次，用戶可以修改--XX:PreBlockSpin來更改。
另外,在 JDK1.6 中引入了自適應的自旋鎖。自適應的自旋鎖帶來的改進就是：自旋的時間不在固定了，而是和前一次同一個鎖上的自旋時間以及鎖的擁有者的狀態來決定。
五、synchronized 與 volatile 的區別
- volatile關鍵字是線程同步的輕量級實現，所以volatile性能肯定比synchronized關鍵字要好。但是volatile關鍵字只能用於變量而synchronized關鍵字可以修飾方法以及代碼塊。synchronized關鍵字在JavaSE1.6之後進行了主要包括爲了減少獲得鎖和釋放鎖帶來的性能消耗而引入的偏向鎖和輕量級鎖以及其它各種優化之後執行效率有了顯著提升，實際開發中使用 synchronized 關鍵字的場景還是更多一些。
- 多線程訪問volatile關鍵字不會發生阻塞，而synchronized關鍵字可能會發生阻塞
- volatile關鍵字能保證數據的可見性，但不能保證數據的原子性。synchronized關鍵字兩者都能保證。
- volatile關鍵字主要用於解決變量在多個線程之間的可見性，而 synchronized關鍵字解決的是多個線程之間訪問資源的同步性。
六、synchronized 與 ReenTrantLock 的區別
1. 兩者都是可重入鎖：“可重入鎖”概念是：自己可以再次獲取自己的內部鎖。比如一個線程獲得了某個對象的鎖，此時這個對象鎖還沒有釋放，當其再次想要獲取這個對象的鎖的時候還是可以獲取的，如果不可鎖重入的話，就會造成死鎖。同一個線程每次獲取鎖，鎖的計數器都自增1，所以要等到鎖的計數器下降爲0時才能釋放鎖。
2. synchronized 依賴於 JVM 而 ReenTrantLock 依賴於 API
3. ReenTrantLock 比 synchronized 增加了一些高級功能相比synchronized，ReenTrantLock增加了一些高級功能。主要來說主要有三點：①等待可中斷；②可實現公平鎖；③可實現選擇性通知（鎖可以綁定多個條件）。
- ReenTrantLock提供了一種能夠中斷等待鎖的線程的機制，通過lock.lockInterruptibly()來實現這個機制。也就是說正在等待的線程可以選擇放棄等待，改爲處理其他事情。
- ReenTrantLock可以指定是公平鎖還是非公平鎖。而synchronized只能是非公平鎖。所謂的公平鎖就是先等待的線程先獲得鎖。
- synchronized關鍵字與wait()和notify/notifyAll()方法相結合可以實現等待/通知機制，ReentrantLock類當然也可以實現，但是需要藉助於Condition接口與newCondition() 方法。Condition是JDK1.5之後纔有的，它具有很好的靈活性，比如可以實現多路通知功能也就是在一個Lock對象中可以創建多個Condition實例（即對象監視器），線程對象可以註冊在指定的Condition中，從而可以有選擇性的進行線程通知，在調度線程上更加靈活。 在使用notify/notifyAll()方法進行通知時，被通知的線程是由 JVM 選擇的，用ReentrantLock類結合Condition實例可以實現“選擇性通知” 。
- 性能已不是選擇標準