詳解Java鎖的升級與對比（1）——鎖的分類與細節（結合部分源碼）

時間 2020-11-23

原文原文鏈接

前言

　　以前只是對Java各類鎖都有所認識，但沒有一個統一的整理及總結，且沒有對「鎖升級」這一律唸的加深理解，今天趁着週末好好整理下以前記過的筆記，並概括爲此博文，主要參考資源爲《Java併發編程的藝術》與《Java多線程編程核心技術》，有須要的朋友能夠私信評論我，這個是有書籤的PDF電子版！算法

1、Java鎖的分類及簡單介紹

　　平時你們都知道的鎖通常都有：CAS鎖，synchronized鎖，ReentranLock鎖等，可是並無瞭解各自的用處與一些細節，這裏用XMind畫一個圖，並作一個簡單的總結。　　數據庫

一、悲觀鎖與樂觀鎖

　　樂觀鎖與悲觀鎖是一種廣義上的概念，體現了看待線程同步的不一樣角度。在Java和數據庫中都有此概念對應的實際應用。編程

　　先說概念。對於同一個數據的併發操做：多線程

悲觀鎖認爲本身在使用數據的時候必定有別的線程來修改數據，所以在獲取數據的時候會先加鎖，確保數據不會被別的線程修改。Java中，synchronized關鍵字和Lock的實現類都是悲觀鎖。
而樂觀鎖認爲本身在使用數據時不會有別的線程修改數據，因此不會添加鎖，只是在更新數據的時候去判斷以前有沒有別的線程更新了這個數據。若是這個數據沒有被更新，當前線程將本身修改的數據成功寫入。若是數據已經被其餘線程更新，則根據不一樣的實現方式執行不一樣的操做（例如報錯或者自動重試），樂觀鎖在Java中是經過使用無鎖編程來實現，最常採用的是CAS算法，Java原子類中的遞增操做就經過CAS自旋實現的

　　根據從上面的概念描述咱們能夠發現：併發

　　悲觀鎖適合寫操做多的場景，先加鎖能夠保證寫操做時數據正確。源碼分析

　　樂觀鎖適合讀操做多的場景，不加鎖的特色可以使其讀操做的性能大幅提高。性能

　　代碼舉例：ReentranLock中採用lock()與unlock方法鎖住同步資源塊測試

　　注意事項：ui

　　正確的寫法：一開始就ock()方法，緊跟着try...finally，unlock()方法必定要在finally{}中的第一行。spa

　　錯誤的寫法：lock沒有緊跟着try...語句；沒有一開始就lock()方法鎖住資源

二、自旋鎖與適應性自旋鎖

　（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）自適應自旋鎖

　　自適應意味着自旋的時間（次數）再也不固定，而是由前一次在同一個鎖上的自旋時間及鎖的擁有者的狀態來決定。

　　若是在同一個鎖對象上，自旋等待剛剛成功得到過鎖，而且持有鎖的線程正在運行中，那麼虛擬機就會認爲此次自旋也是頗有可能再次成功，進而它將容許自旋等待持續相對更長的時間。

　　若是對於某個鎖，自旋不多成功得到過，那在之後嘗試獲取這個鎖時將可能省略掉自旋過程，直接阻塞線程，避免浪費處理器資源，即根據實際狀況，決定自旋的時間。

三、公平鎖與非公平鎖

公平鎖是指多個線程按照申請鎖的順序來獲取鎖，線程直接進入隊列中排隊，隊列中的第一個線程才能得到鎖（排隊獲取鎖）。

公平鎖的優勢是等待鎖的線程不會餓死。
缺點是總體吞吐效率相對非公平鎖要低，等待隊列中除第一個線程之外的全部線程都會阻塞，CPU喚醒阻塞線程的開銷比非公平鎖大。

非公平鎖是多個線程加鎖時直接嘗試獲取鎖，獲取不到纔會到等待隊列的隊尾等待。但若是此時鎖恰好可用，那麼這個線程能夠無需阻塞直接獲取到鎖，因此非公平鎖有可能出現後申請鎖的線程先獲取鎖的場景（嘗試獲取鎖，不行就從新進隊尾等待）。

非公平鎖的優勢是能夠減小喚起線程的開銷，總體的吞吐效率高，由於線程有概率不阻塞直接得到鎖，CPU沒必要喚醒全部線程。
缺點是處於等待隊列中的線程可能會餓死，或者等好久纔會得到鎖。

咱們先結合ReentranLock中的源碼結構及部分源碼分析下，能夠獲得如下兩點：

　（1）實際上，ReentranceLock中有一個內部類Sync，ReentranceLock添加鎖/釋放鎖等關鍵操做都是由它完成的，而且它繼承了AQS（AbstractQueuedSynchronizer，這是一個很重要的能學到不少知識的須要好好分析源碼的類，以後會抽時間好好分析），源碼註釋有有這麼一句話：Synchronizer providing all implementation mechanics。

　（2）ReentrantLock它還有公平鎖FairSync和非公平鎖NonfairSync兩個子類，ReentrantLock默認使用非公平鎖，也能夠經過構造器來顯示的指定使用公平鎖。

接下來咱們分別看公平鎖與非公平鎖加鎖的實現對比：

公平鎖加鎖方法:　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　非公平鎖加鎖方法：

咱們能夠清晰的看出有一個公平鎖中有一個hasQueuePredecessors()方法：判斷當前線程是不是隊頭，不是的話不會去處理。這也就是公平鎖與非公平鎖最大的區別。

四、可重入鎖與非可重入鎖

　　可重入鎖又名遞歸鎖，是指在同一個線程在外層方法獲取鎖的時候，再進入該線程的內層方法會自動獲取鎖（前提鎖對象得是同一個對象或者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;
        }
    }