前言
之前只是對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是沒有非可重入鎖的實現的，那么我們可以類比就行（具體可以看我在學習JUC源碼（2）——自定義同步組件寫的Mutex用例）。
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; } }
----------------------------未完待續，下一個繼續介紹共享鎖與排它鎖（結合部分源碼），同時重點介紹鎖升級-----------------------------------------------