前言
之前只是對Java各種鎖都有所認識，但沒有一個統一的整理及總結，且沒有對“鎖升級”這一概念的加深理解，今天趁著週末好好整理下之前記過的筆記，並歸納為此博文，主要參考資源為《Java併發程式設計的藝術》與《Java多執行緒程式設計核心技術》，有需要的朋友可以私信評論我，這個是有書籤的PDF電子版！
一、Java鎖的分類及簡單介紹
平時大家都知道的鎖一般都有：CAS鎖，synchronized鎖，ReentranLock鎖等，但是並沒有瞭解各自的用處與一些細節，這裡用XMind畫一個圖，並做一個簡單的總結。
1、悲觀鎖與樂觀鎖
樂觀鎖與悲觀鎖是一種廣義上的概念，體現了看待執行緒同步的不同角度。在Java和資料庫中都有此概念對應的實際應用。
先說概念。對於同一個資料的併發操作：
- 悲觀鎖認為自己在使用資料的時候一定有別的執行緒來修改資料，因此在獲取資料的時候會先加鎖，確保資料不會被別的執行緒修改。Java中，synchronized關鍵字和Lock的實現類都是悲觀鎖。
- 而樂觀鎖認為自己在使用資料時不會有別的執行緒修改資料，所以不會新增鎖，只是在更新資料的時候去判斷之前有沒有別的執行緒更新了這個資料。如果這個資料沒有被更新，當前執行緒將自己修改的資料成功寫入。如果資料已經被其他執行緒更新，則根據不同的實現方式執行不同的操作（例如報錯或者自動重試），樂觀鎖在Java中是通過使用無鎖程式設計來實現，最常採用的是CAS演算法，Java原子類中的遞增操作就通過CAS自旋實現的
根據從上面的概念描述我們可以發現：
悲觀鎖適合寫操作多的場景，先加鎖可以保證寫操作時資料正確。
樂觀鎖適合讀操作多的場景，不加鎖的特點能夠使其讀操作的效能大幅提升。
程式碼舉例：ReentranLock中採用lock()與unlock方法鎖住同步資源塊
注意事項：
正確的寫法：一開始就ock()方法，緊跟著try...finally，unlock()方法一定要在finally{}中的第一行。
錯誤的寫法：lock沒有緊跟著try...語句；沒有一開始就lock()方法鎖住資源
2、自旋鎖與適應性自旋鎖
（1）自旋鎖
阻塞或喚醒一個Java執行緒需要作業系統切換CPU狀態來完成，這種狀態轉換需要耗費處理器時間。如果同步程式碼塊中的內容過於簡單，狀態轉換消耗的時間有可能比使用者程式碼執行的時間還要長。
在許多場景中，同步資源的鎖定時間很短，為了這一小段時間去切換執行緒，執行緒掛起和恢復現場的花費可能會讓系統得不償失。如果物理機器有多個處理器，能夠讓兩個或以上的執行緒同時並行執行，我們就可以讓後面那個請求鎖的執行緒不放棄CPU的執行時間，看看持有鎖的執行緒是否很快就會釋放鎖。而為了讓當前執行緒“稍等一下”，我們需讓當前執行緒進行自旋，如果在自旋完成後前面鎖定同步資源的執行緒已經釋放了鎖，那麼當前執行緒就可以不必阻塞而是直接獲取同步資源，從而避免切換執行緒的開銷。這就是自旋鎖。
自旋鎖的缺點：
從概念上來看，就知道自旋鎖本身是有缺點的，它不能代替阻塞。自旋等待雖然避免了執行緒切換的開銷，但它要佔用處理器時間。如果鎖被佔用的時間很短，自旋等待的效果就會非常好。反之，如果鎖被佔用的時間很長，那麼自旋的執行緒只會白浪費處理器資源。所以，自旋等待的時間必須要有一定的限度，如果自旋超過了限定次數（預設是10次，可以使用-XX:PreBlockSpin來更改）沒有成功獲得鎖，就應當掛起執行緒。簡單來說就是自旋的次數跟時間超過一定的閾值就可能浪費處理器的資源。
自旋鎖的CAS實現：
在AtomicInteger原始碼中就使用了CAS思想（實際上就是呼叫unsafe中方法），採用do-while迴圈（這是一個CAS常用的do{}while(){}，還有就是for(;;){if(...) return}），這裡就是一個CAS操作，首先do{...}讀取值，之後在通過迴圈while中CAS自旋修改值，直到成功為止。
自旋鎖在JDK1.4.2中引入，使用-XX:+UseSpinning來開啟。JDK 6中變為預設開啟，並且引入了自適應的自旋鎖（適應性自旋鎖）。
（2）自適應自旋鎖
自適應意味著自旋的時間（次數）不再固定，而是由前一次在同一個鎖上的自旋時間及鎖的擁有者的狀態來決定。
如果在同一個鎖物件上，自旋等待剛剛成功獲得過鎖，並且持有鎖的執行緒正在執行中，那麼虛擬機器就會認為這次自旋也是很有可能再次成功，進而它將允許自旋等待持續相對更長的時間。
如果對於某個鎖，自旋很少成功獲得過，那在以後嘗試獲取這個鎖時將可能省略掉自旋過程，直接阻塞執行緒，避免浪費處理器資源，即根據實際情況，決定自旋的時間。
3、公平鎖與非公平鎖
公平鎖是指多個執行緒按照申請鎖的順序來獲取鎖，執行緒直接進入佇列中排隊，佇列中的第一個執行緒才能獲得鎖（排隊獲取鎖）。
- 公平鎖的優點是等待鎖的執行緒不會餓死。
- 缺點是整體吞吐效率相對非公平鎖要低，等待佇列中除第一個執行緒以外的所有執行緒都會阻塞，CPU喚醒阻塞執行緒的開銷比非公平鎖大。
非公平鎖是多個執行緒加鎖時直接嘗試獲取鎖，獲取不到才會到等待佇列的隊尾等待。但如果此時鎖剛好可用，那麼這個執行緒可以無需阻塞直接獲取到鎖，所以非公平鎖有可能出現後申請鎖的執行緒先獲取鎖的場景（嘗試獲取鎖，不行就重新進隊尾等待）。
- 非公平鎖的優點是可以減少喚起執行緒的開銷，整體的吞吐效率高，因為執行緒有機率不阻塞直接獲得鎖，CPU不必喚醒所有執行緒。
- 缺點是處於等待佇列中的執行緒可能會餓死，或者等很久才會獲得鎖。
我們先結合ReentranLock中的原始碼結構及部分原始碼分析下，可以得到以下兩點：
（1）實際上，ReentranceLock中有一個內部類Sync，ReentranceLock新增鎖/釋放鎖等關鍵操作都是由它完成的，並且它繼承了AQS（AbstractQueuedSynchronizer，這是一個很重要的能學到很多知識的需要好好分析原始碼的類，之後會抽時間好好分析），原始碼註釋有有這麼一句話：Synchronizer providing all implementation mechanics。
（2）ReentrantLock它還有公平鎖FairSync和非公平鎖NonfairSync兩個子類，ReentrantLock預設使用非公平鎖，也可以通過構造器來顯示的指定使用公平鎖。
接下來我們分別看公平鎖與非公平鎖加鎖的實現對比：
公平鎖加鎖方法: 非公平鎖加鎖方法：
我們可以清晰的看出有一個公平鎖中有一個hasQueuePredecessors()方法：判斷當前執行緒是否是隊頭，不是的話不會去處理。這也就是公平鎖與非公平鎖最大的區別。
4、可重入鎖與非可重入鎖
可重入鎖又名遞迴鎖，是指在同一個執行緒在外層方法獲取鎖的時候，再進入該執行緒的內層方法會自動獲取鎖（前提鎖物件得是同一個物件或者class），不會因為之前已經獲取過還沒釋放而阻塞。Java中ReentrantLock和synchronized都是可重入鎖，可重入鎖的一個優點是可一定程度避免死鎖 。
關鍵字synchronized在使用時，當一個執行緒得到一個物件鎖後，再次請求物件鎖時是可以再次得到該物件鎖的，這也證明synchronized塊/方法的內部呼叫本類的其它synchronized方法/塊時，是可以永遠得到鎖的。
編寫測試類：
執行結果：
service1()
service2()
service3()
從結果上來說，“可重入鎖”概念就是：自己能夠再次獲取自己的內部鎖，同時當存在子類繼承關係時，子類也完全可以通過“可重入鎖”呼叫父類的同步方法的。
好了，以上都是通過synchronized關鍵字的舉例，接下來我們同樣採用對比的方法對比ReentranLock部分關鍵原始碼來說明可重入鎖與非可重入鎖細節。實際上ReentranLock是沒有非可重入鎖的實現的，那麼我們可以類比就行。
ReentranLock中可重入鎖與非可重入鎖與區別（結合原始碼）
ReentrantLock繼承父類AQS，其父類AQS中維護了一個同步狀態status來計數重入次數，status初始值為0。當執行緒嘗試獲取鎖時：
可重入鎖：
- 可重入鎖先嚐試獲取並更新status值，如果status == 0表示沒有其他執行緒在執行同步程式碼，則把status置為1，當前執行緒開始執行。
- 判斷如果status != 0，則判斷當前執行緒是否是獲取到這個鎖的執行緒，如果是的話執行status+1，且當前執行緒可以再次獲取鎖
final boolean nonfairTryAcquire(int acquires) { final Thread current = Thread.currentThread(); int c = getState(); if (c == 0) { // state為0鎖處於空閒狀態 if (compareAndSetState(0, acquires)) { // 獲取成功之後，當前執行緒是該鎖的持有者 setExclusiveOwnerThread(current); return true; } } // 鎖不是空閒狀態，但是當前執行緒是該鎖的持有者的話，實現可重入 else if (current == getExclusiveOwnerThread()) { int nextc = c + acquires; // state+1 可重入數 if (nextc < 0) // overflow throw new Error("Maximum lock count exceeded"); setState(nextc); return true; // 返回true，表示獲取鎖成功（可重入的） } return false; }
非可重入鎖：
- 是直接去獲取並嘗試更新當前status的值，如果status != 0的話會導致其獲取鎖失敗，當前執行緒阻塞
/** * 類似可重入操作類比出非可重入操作 * @param acquires * @return */ final boolean tryAcquire(int acquires) { final Thread current = Thread.currentThread(); // 非重入鎖直接嘗試獲取該鎖 if (compareAndSetState(0, acquires)) { // 這裡acquires實際就是1，對state+1 // 獲取之後設定為持有者，返回true，表示成功，其它情況都是false，即不能被重入了 setExclusiveOwnerThread(current); return true; } // 鎖不是空閒狀態，但是當前執行緒是該鎖的持有者的話，實現可重入 else if { return false; } }
釋放鎖時，同樣都是執行緒先嚐試獲取當前status的值，並判斷當前執行緒是不是持有鎖的執行緒的前提下
可重入鎖：
- 執行判斷status-1==0，如果true則說明所有重複所有鎖的操作已經完成，接下來就是真正的釋放鎖，如果為false說明還有內部持有鎖的操作未完成。
protected final boolean tryRelease(int releases) { int c = getState() - releases; // 保證釋放鎖的必須是當前執行緒 if (Thread.currentThread() != getExclusiveOwnerThread()) throw new IllegalMonitorStateException(); boolean free = false; // 釋放後state為0，則持有者置為null if (c == 0) { free = true; setExclusiveOwnerThread(null); } // 否則設定重置後的state setState(c); return free; }
非可重入鎖：
- 只需要判斷是不是當前持有鎖的執行緒，是的話status=0，鎖釋放操作完成
/** * 類似可重入鎖釋放鎖操作 得到非可重入鎖操作 * @param releases * @return */ protected final boolean tryRelease(int releases) { // 保證釋放鎖的必須是當前執行緒 if (Thread.currentThread() != getExclusiveOwnerThread()) { throw new IllegalMonitorStateException(); } else { // 非可重入鎖釋放鎖直接將持有者置為null setExclusiveOwnerThread(null); // state直接置為0 setState(0); return true; } }
----------------------------未完待續，下一個繼續介紹共享鎖與排它鎖（結合部分原始碼），同時重點介紹鎖升級-----------------------------------------------