我們最初學習Java的時候，遇到多線程我們會知道synchronized，對于當時的我們來說synchronized是保證了多線程之間的同步，也成為了我們解決多線程情況的常用手段。但是，隨著我們學習的進行我們知道synchronized是一個重量級鎖，相對于Lock，它會顯得那么笨重，以至于我們認為它不是那么的高效而慢慢摒棄它。
但是，隨著Javs SE 1.6對synchronized進行的各種優化后，synchronized并不會顯得那么重了。下面跟隨LZ一起來探索synchronized的實現機制、Java是如何對它進行了優化、鎖優化機制、鎖的存儲結構和升級過程；
一.synchronized的實現機制
Java對象頭和monitor是實現synchronized的基礎！下面就這兩個概念來做詳細介紹。
1.Java對象頭:Hotspot虛擬機的對象頭主要包括兩部分數據：Mark Word（標記字段）、Klass Pointer（類型指針）。
Klass Point是對象指向它的類元數據的指針，虛擬機通過這個指針來確定這個對象是哪個類的實例;
Mark Word用于存儲對象自身的運行時數據，如哈希碼（HashCode）、GC分代年齡、鎖狀態標志、線程持有的鎖、偏向線程 ID、偏向時間戳等等,它是實現輕量級鎖和偏向鎖的關鍵.
2.什么是Monitor？我們可以把它理解為一個同步工具，也可以描述為一種同步機制，它通常被描述為對象監視器。
當多個線程同時請求某個對象監視器時，對象監視器會設置幾種狀態用來區分請求的線程：
Contention List：所有請求鎖的線程將被首先放置到該競爭隊列
Entry List：Contention List中那些有資格成為候選人的線程被移到Entry List
Wait Set：那些調用wait方法被阻塞的線程被放置到Wait Set
OnDeck：任何時刻最多只能有一個線程正在競爭鎖，該線程稱為OnDeck
Owner：獲得鎖的線程稱為Owner
!Owner：釋放鎖的線程
下圖就是多個線程獲取鎖的示意圖
新請求鎖的線程將首先被加入到ConetentionList中，當某個擁有鎖的線程（Owner狀態）調用unlock之后，如果發現EntryList為空則從ContentionList中移動線程到EntryList，下面說明下ContentionList和EntryList的實現方式：
ContentionList虛擬隊列
ContentionList并不是一個真正的Queue，而只是一個虛擬隊列，原因在于ContentionList是由Node及其next指針邏輯構成，并不存在一個Queue的數據結構。ContentionList是一個先進先出（FIFO）的隊列，每次新加入Node時都會在隊頭進行，通過CAS改變第一個節點的的指針為新增節點，同時設置新增節點的next指向后續節點，而取得操作則發生在隊尾。顯然，該結構其實是個Lock-Free的隊列。
因為只有Owner線程才能從隊尾取元素，也即線程出列操作無爭用，當然也就避免了CAS的ABA問題。
EntryList
EntryList與ContentionList邏輯上同屬等待隊列，ContentionList會被線程并發訪問，為了降低對ContentionList隊尾的爭用，而建立EntryList。Owner線程在unlock時會從ContentionList中遷移線程到EntryList，并會指定EntryList中的某個線程（一般為Head）為Ready（OnDeck）線程。Owner線程并不是把鎖傳遞給OnDeck線程，只是把競爭鎖的權利交給OnDeck，OnDeck線程需要重新競爭鎖。這樣做雖然犧牲了一定的公平性，但極大的提高了整體吞吐量，在Hotspot中把OnDeck的選擇行為稱之為“競爭切換”。
OnDeck線程獲得鎖后即變為owner線程，無法獲得鎖則會依然留在EntryList中，考慮到公平性，在EntryList中的位置不發生變化（依然在隊頭）。如果Owner線程被wait方法阻塞，則轉移到WaitSet隊列；如果在某個時刻被notify/notifyAll喚醒，則再次轉移到EntryList。
二.java1.6之后synchronized的優化
jdk1.6對鎖的實現引入了大量的優化，如自旋鎖、適應性自旋鎖、鎖消除、鎖粗化、偏向鎖、輕量級鎖等技術來減少鎖操作的開銷。
自旋鎖
線程的阻塞和喚醒需要CPU從用戶態轉為核心態，頻繁的阻塞和喚醒對CPU來說是一件負擔很重的工作，勢必會給系統的并發性能帶來很大的壓力。同時我們發現在許多應用上面，對象鎖的鎖狀態只會持續很短一段時間，為了這一段很短的時間頻繁地阻塞和喚醒線程是非常不值得的。所以引入自旋鎖。
何謂自旋鎖？
所謂自旋鎖，就是讓該線程等待一段時間，不會被立即掛起，看持有鎖的線程是否會很快釋放鎖。怎么等待呢？執行一段無意義的循環即可（自旋）。
自旋等待不能替代阻塞，先不說對處理器數量的要求（多核，貌似現在沒有單核的處理器了），雖然它可以避免線程切換帶來的開銷，但是它占用了處理器的時間。如果持有鎖的線程很快就釋放了鎖，那么自旋的效率就非常好，反之，自旋的線程就會白白消耗掉處理的資源，它不會做任何有意義的工作，典型的占著茅坑不拉屎，這樣反而會帶來性能上的浪費。所以說，自旋等待的時間（自旋的次數）必須要有一個限度，如果自旋超過了定義的時間仍然沒有獲取到鎖，則應該被掛起。
自旋鎖在JDK 1.4.2中引入，默認關閉，但是可以使用-XX:+UseSpinning開開啟，在JDK1.6中默認開啟。同時自旋的默認次數為10次，可以通過參數-XX:PreBlockSpin來調整；
如果通過參數-XX:preBlockSpin來調整自旋鎖的自旋次數，會帶來諸多不便。假如我將參數調整為10，但是系統很多線程都是等你剛剛退出的時候就釋放了鎖（假如你多自旋一兩次就可以獲取鎖），你是不是很尷尬。于是JDK1.6引入自適應的自旋鎖，讓虛擬機會變得越來越聰明。
適應自旋鎖
JDK 1.6引入了更加聰明的自旋鎖，即自適應自旋鎖。所謂自適應就意味著自旋的次數不再是固定的，它是由前一次在同一個鎖上的自旋時間及鎖的擁有者的狀態來決定。它怎么做呢？線程如果自旋成功了，那么下次自旋的次數會更加多，因為虛擬機認為既然上次成功了，那么此次自旋也很有可能會再次成功，那么它就會允許自旋等待持續的次數更多。反之，如果對于某個鎖，很少有自旋能夠成功的，那么在以后要或者這個鎖的時候自旋的次數會減少甚至省略掉自旋過程，以免浪費處理器資源。
有了自適應自旋鎖，隨著程序運行和性能監控信息的不斷完善，虛擬機對程序鎖的狀況預測會越來越準確，虛擬機會變得越來越聰明。
鎖消除
為了保證數據的完整性，我們在進行操作時需要對這部分操作進行同步控制，但是在有些情況下，JVM檢測到不可能存在共享數據競爭，這是JVM會對這些同步鎖進行鎖消除。鎖消除的依據是逃逸分析的數據支持。
如果不存在競爭，為什么還需要加鎖呢？所以鎖消除可以節省毫無意義的請求鎖的時間。變量是否逃逸，對于虛擬機來說需要使用數據流分析來確定，但是對于我們程序員來說這還不清楚么？我們會在明明知道不存在數據競爭的代碼塊前加上同步嗎？但是有時候程序并不是我們所想的那樣？我們雖然沒有顯示使用鎖，但是我們在使用一些JDK的內置API時，如StringBuffer、Vector、HashTable等，這個時候會存在隱形的加鎖操作。比如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);
}
在運行這段代碼時，JVM可以明顯檢測到變量vector沒有逃逸出方法vectorTest()之外，所以JVM可以大膽地將vector內部的加鎖操作消除。
鎖粗化
我們知道在使用同步鎖的時候，需要讓同步塊的作用范圍盡可能小—僅在共享數據的實際作用域中才進行同步，這樣做的目的是為了使需要同步的操作數量盡可能縮小，如果存在鎖競爭，那么等待鎖的線程也能盡快拿到鎖。
在大多數的情況下，上述觀點是正確的，LZ也一直堅持著這個觀點。但是如果一系列的連續加鎖解鎖操作，可能會導致不必要的性能損耗，所以引入鎖粗話的概念。
鎖粗話概念比較好理解，就是將多個連續的加鎖、解鎖操作連接在一起，擴展成一個范圍更大的鎖。如上面實例：vector每次add的時候都需要加鎖操作，JVM檢測到對同一個對象（vector）連續加鎖、解鎖操作，會合并一個更大范圍的加鎖、解鎖操作，即加鎖解鎖操作會移到for循環之外。
三.鎖的等級
鎖主要存在四中狀態，依次是：無鎖狀態、偏向鎖狀態、輕量級鎖狀態、重量級鎖狀態，他們會隨著競爭的激烈而逐漸升級。注意鎖可以升級不可降級，這種策略是為了提高獲得鎖和釋放鎖的效率。
偏向鎖是指一段同步代碼一直被一個線程所訪問，那么該線程會自動獲取鎖。降低獲取鎖的代價。其中識別是不是同一個線程一只獲取鎖的標志是在上面提到的對象頭Mark Word（標記字段）中存儲的。
輕量級鎖是指當鎖是偏向鎖的時候，被另一個線程所訪問，偏向鎖就會升級為輕量級鎖，其他線程會通過自旋的形式嘗試獲取鎖，不會阻塞，提高性能。
重量級鎖是指當鎖為輕量級鎖的時候，另一個線程雖然是自旋，但自旋不會一直持續下去，當自旋一定次數的時候，還沒有獲取到鎖，就會進入阻塞，該鎖膨脹為重量級鎖。重量級鎖會讓其他申請的線程進入阻塞，性能降低。這時候也就成為了原始的Synchronized的實現。
JVM在運行過程會根據實際情況對添加了Synchronized關鍵字的部分進行鎖自動升級來實現自我優化。
以上就是Synchronized的實現原理和java1.6以后對其所做的優化以及在實際運行中可能遇到的鎖升級等，另一種鎖Lock的實現原理我們在下一文章中進行解析。
