Java中的鎖

在學習或者使用Java的過程中程序會遇到各種各樣的鎖的概念：公平鎖、非公平鎖、自旋鎖、可重入鎖、偏向鎖、輕量級鎖、重量級鎖、讀寫鎖、互斥鎖等待。這裡整理了Java中的各種鎖，若有不足之處希望大家在下方留言探讨。

WARNING：本文适合有一定JAVA基礎的同學閱讀。

##公平鎖和非公平鎖

公平鎖是指多個線程在等待同一個鎖時，必須按照申請鎖的先後順序來一次獲得鎖。

公平鎖的好處是等待鎖的線程不會餓死，但是整體效率相對低一些；非公平鎖的好處是整體效率相對高一些，但是有些線程可能會餓死或者說很早就在等待鎖，但要等很久才會獲得鎖。其中的原因是公平鎖是嚴格按照請求所的順序來排隊獲得鎖的，而非公平鎖時可以搶占的，即如果在某個時刻有線程需要擷取鎖，而這個時候剛好鎖可用，那麼這個線程會直接搶占，而這時阻塞在等待隊列的線程則不會被喚醒。

公平鎖可以使用new ReentrantLock(true)實作。

##自旋鎖

Java的線程是映射到作業系統的原生線程之上的，如果要阻塞或喚醒一個線程，都需要作業系統來幫忙完成，這就需要從使用者态轉換到核心态中，是以狀态裝換需要耗費很多的處理器時間，對于代碼簡單的同步塊（如被synchronized修飾的getter()和setter()方法），狀态轉換消耗的時間有可能比使用者代碼執行的時間還要長。

虛拟機的開發團隊注意到在許多應用上，共享資料的鎖定狀态隻會持續很短的一段時間，為了這段時間取挂起和恢複現場并不值得。如果實體機器有一個以上的處理器，能讓兩個或以上的線程同時并行執行，我們就可以讓後面請求鎖的那個線程“稍等一下“，但不放棄處理器的執行時間，看看持有鎖的線程是否很快就會釋放鎖。為了讓線程等待，我們隻需讓線程執行一個忙循環（自旋），這項技術就是所謂的自旋鎖。

自旋等待不能代替阻塞。自旋等待本身雖然避免了線程切換的開銷，但它是要占用處理器時間的，是以，如果鎖被占用的時間很短，自旋等待的效果就會非常好，反之，如果鎖被占用的時間很長，那麼自旋的線程隻會拜拜浪費處理器資源。是以，自旋等待的時間必須要有一定的限度，如果自旋超過了限定次數（預設是10次，可以使用-XX:PreBlockSpin來更改）沒有成功獲得鎖，就應當使用傳統的方式去挂起線程了。

自旋鎖在JDK1.4.2中引入，使用-XX:+UseSpinning來開啟。JDK6中已經變為預設開啟，并且引入了自适應的自旋鎖。自适應意味着自旋的時間不在固定了，而是由前一次在同一個鎖上的自旋時間及鎖的擁有者的狀态來決定。

自旋是在輕量級鎖中使用的，在重量級鎖中，線程不使用自旋。

如果在同一個鎖對象上，自旋等待剛剛成功獲得過鎖，并且持有鎖的線程正在運作中，那麼虛拟機就會認為這次自旋也是很有可能再次成功，進而它将允許自旋等待持續相對更長的時間，比如100次循環。另外，如果對于某個鎖，自旋很少成功獲得過，那在以後要擷取這個鎖時将可能省略掉自旋過程，以避免浪費處理器資源。

##鎖消除

鎖消除是虛拟機JIT在運作時，對一些代碼上要求同步，但是被檢測到不可能存在共享資料競争的鎖進行消除。鎖消除的主要判斷依據是來源于逃逸分析的資料支援，如果判斷在一段代碼中，堆上的所有資料都不會逃逸出去進而能被其他線程通路到，那就可以把他們當做棧上資料對待，認為他們是線程私有的，同步加鎖自然就無需進行。

來看這樣一個方法：

public String concatString(String s1, String s2, String s3)
    {
        StringBuffer sb = new StringBuffer();
        sb.append(s1);
        sb.append(s2);
        sb.append(s3);
        return sb.toString();
    }
           

可以知道StringBuffer 的append方法定義如下：

public synchronized StringBuffer append(StringBuffer sb) {
        super.append(sb);
        return this;
    }
           

也就是說在concatString()方法中涉及了同步操作。但是可以觀察到sb對象它的作用域被限制在方法的内部，也就是sb對象不會“逃逸”出去，其他線程無法通路。是以，雖然這裡有鎖，但是可以被安全的消除，在即時編譯之後，這段代碼就會忽略掉所有的同步而直接執行了。

##鎖粗化

原則上，我們在編寫代碼的時候，總是推薦将同步塊的作用範圍限制的盡量小——隻在共享資料的實際作用域中才進行同步，這樣是為了使得需要同步的操作數量盡可能變小，如果存在鎖禁止，那等待的線程也能盡快拿到鎖。大部分情況下，這些都是正确的。但是，如果一些列的聯系操作都是同一個對象反複加上和解鎖，甚至加鎖操作是出現在循環體中的，那麼即使沒有線程競争，頻繁地進行互斥同步操作也導緻不必要的性能損耗。

舉個案例，類似鎖消除的concatString()方法。如果StringBuffer sb = new StringBuffer();定義在方法體之外，那麼就會有線程競争，但是每個append()操作都對同一個對象反複加鎖解鎖，那麼虛拟機探測到有這樣的情況的話，會把加鎖同步的範圍擴充到整個操作序列的外部，即擴充到第一個append()操作之前和最後一個append()操作之後，這樣的一個鎖範圍擴充的操作就稱之為鎖粗化。

##可重入鎖

可重入鎖，也叫做遞歸鎖，指的是同一線程外層函數獲得鎖之後 ，内層遞歸函數仍然有擷取該鎖的代碼，但不受影響。

在JAVA環境下 ReentrantLock 和synchronized 都是可重入鎖。可重入鎖最大的作用是避免死鎖。

##類鎖和對象鎖

類鎖：在方法上加上static synchronized的鎖，或者synchronized(xxx.class)的鎖。如下代碼中的method1和method2：

對象鎖：參考method4, method5,method6.

public class LockStrategy
{
    public Object object1 = new Object();

    public static synchronized void method1(){}
    public void method2(){
        synchronized(LockStrategy.class){}
    }

    public synchronized void method4(){}
    public void method5()
    {
        synchronized(this){}
    }
    public void method6()
    {
        synchronized(object1){}
    }
}
           

下面做一道習題來加深一下對對象鎖和類鎖的了解.

有一個類這樣定義:

public class SynchronizedTest
{
    public synchronized void method1(){}
    public synchronized void method2(){}
    public static synchronized void method3(){}
    public static synchronized void method4(){}
}
           

那麼，有SynchronizedTest的兩個執行個體a和b，對于一下的幾個選項有哪些能被一個以上的線程同時通路呢？

A. a.method1() vs. a.method2()

B. a.method1() vs. b.method1()

C. a.method3() vs. b.method4()

D. a.method3() vs. b.method3()

E. a.method1() vs. a.method3()

答案是什麼呢？BE

##偏向鎖、輕量級鎖和重量級鎖

synchronized的偏向鎖、輕量級鎖以及重量級鎖是通過Java對象頭實作的。部落客在Java對象大小内幕淺析中提到了Java對象的記憶體布局分為：對象頭、執行個體資料和對齊填充，而對象頭又可以分為"Mark Word"和類型指針klass。"Mark Word"是關鍵，預設情況下，其存儲對象的HashCode、分代年齡和鎖标記位。

這裡說的都是以HotSpot虛拟機為基準的。首先來看一下"Mark Word"的内容：

鎖狀态	存儲内容	标志位
無鎖	對象的hashCode、對象分代年齡、是否是偏向鎖（0）	01
輕量級	指向棧中鎖記錄的指針	00
重量級	指向互斥量（重量級鎖）的指針	10
GC标記	（空）	11
偏向鎖	偏向線程ID、偏向時間戳、對象分代年齡、是否是偏向鎖（1）

注意到這裡的無鎖和偏向鎖在"Mark Word"的倒數第三bit中分别采用0和1标記。

偏向鎖是JDK6中引入的一項鎖優化，它的目的是消除資料在無競争情況下的同步原語，進一步提高程式的運作性能。

偏向鎖會偏向于第一個獲得它的線程，如果在接下來的執行過程中，該鎖沒有被其他的線程擷取，則持有偏向鎖的線程将永遠不需要同步。大多數情況下，鎖不僅不存在多線程競争，而且總是由同一線程多次獲得，為了讓線程獲得鎖的代價更低而引入了偏向鎖。

當鎖對象第一次被線程擷取的時候，線程使用CAS操作把這個鎖的線程ID記錄再對象Mark Word之中，同時置偏向标志位1。以後該線程在進入和退出同步塊時不需要進行CAS操作來加鎖和解鎖，隻需要簡單地測試一下對象頭的Mark Word裡是否存儲着指向目前線程的偏向鎖。如果測試成功，表示線程已經獲得了鎖。

如果線程使用CAS操作時失敗則表示該鎖對象上存在競争并且這個時候另外一個線程獲得偏向鎖的所有權。當到達全局安全點（safepoint，這個時間點上沒有正在執行的位元組碼）時獲得偏向鎖的線程被挂起，膨脹為輕量級鎖（涉及Monitor Record，Lock Record相關操作，這裡不展開），同時被撤銷偏向鎖的線程繼續往下執行同步代碼。

當有另外一個線程去嘗試擷取這個鎖時，偏向模式就宣告結束。

線程在執行同步塊之前，JVM會先在目前線程的棧幀中建立用于存儲鎖記錄(Lock Record)的空間，并将對象頭中的Mard Word複制到鎖記錄中，官方稱為Displaced Mark Word。然後線程嘗試使用CAS将對象頭中的Mark Word替換為指向鎖記錄的指針。如果成功，目前線程獲得鎖，如果失敗，表示其他線程競争鎖，目前線程便嘗試使用自旋來擷取鎖。如果自旋失敗則鎖會膨脹成重量級鎖。如果自旋成功則依然處于輕量級鎖的狀态。

輕量級鎖的解鎖過程也是通過CAS操作來進行的，如果對象的Mark Word仍然指向線程的鎖記錄，那就用CAS操作把對象目前的Mark Word和線程中指派的Displaced Mark Word替換回來，如果替換成功，整個同步過程就完成了，如果替換失敗，就說明有其他線程嘗試過擷取該鎖，那就要在釋放鎖的同時，喚醒被挂起的線程。

輕量級鎖提升程式同步性能的依據是：對于絕大部分的鎖，在整個同步周期内都是不存在競争的（差別于偏向鎖）。這是一個經驗資料。如果沒有競争，輕量級鎖使用CAS操作避免了使用互斥量的開銷，但如果存在鎖競争，除了互斥量的開銷外，還額外發生了CAS操作，是以在有競争的情況下，輕量級鎖比傳統的重量級鎖更慢。

整個synchronized鎖流程如下：

1. 檢測Mark Word裡面是不是目前線程的ID，如果是，表示目前線程處于偏向鎖
2. 如果不是，則使用CAS将目前線程的ID替換Mard Word，如果成功則表示目前線程獲得偏向鎖，置偏向标志位1
3. 如果失敗，則說明發生競争，撤銷偏向鎖，進而更新為輕量級鎖。
4. 目前線程使用CAS将對象頭的Mark Word替換為鎖記錄指針，如果成功，目前線程獲得鎖
5. 如果失敗，表示其他線程競争鎖，目前線程便嘗試使用自旋來擷取鎖。
6. 如果自旋成功則依然處于輕量級狀态。
7. 如果自旋失敗，則更新為重量級鎖。

##悲觀鎖和樂觀鎖

悲觀鎖：假定會發生并發沖突，屏蔽一切可能違反資料完整性的操作。

樂觀鎖：假定不會發生并發沖突，隻在送出操作時檢測是否違反資料完整性。（使用版本号或者時間戳來配合實作）

##共享鎖和排它鎖

共享鎖：如果事務T對資料A加上共享鎖後，則其他事務隻能對A再加共享鎖，不能加排它鎖。獲準共享鎖的事務隻能讀資料，不能修改資料。

排它鎖：如果事務T對資料A加上排它鎖後，則其他事務不能再對A加任何類型的鎖。獲得排它鎖的事務即能讀資料又能修改資料。

##讀寫鎖

讀寫鎖是一個資源能夠被多個讀線程通路，或者被一個寫線程通路但不能同時存在讀線程。Java當中的讀寫鎖通過ReentrantReadWriteLock實作。具體使用方法這裡不展開。

##互斥鎖

所謂互斥鎖就是指一次最多隻能有一個線程持有的鎖。在JDK中synchronized和JUC的Lock就是互斥鎖。

##無鎖

要保證現場安全，并不是一定就要進行同步，兩者沒有因果關系。同步隻是保證共享資料争用時的正确性的手段，如果一個方法本來就不涉及共享資料，那它自然就無須任何同步措施去保證正确性，是以會有一些代碼天生就是線程安全的。

1. 無狀态程式設計。無狀态代碼有一些共同的特征：不依賴于存儲在對上的資料和公用的系統資源、用到的狀态量都由參數中傳入、不調用非無狀态的方法等。可以參考Servlet。
2. 線程本地存儲。可以參考ThreadLocal
3. volatile
4. CAS
5. 協程：在單線程裡實作多任務的排程，并在單線程裡維持多個任務間的切換。

##分段鎖

ConcurrentHashMap中采用了分段鎖

##閉鎖

閉鎖是一種同步工具類，可以延遲線程的進度直到其到達終止狀态。閉鎖的作用相當于一扇門：在閉鎖到達結束狀态之前，這扇門一直是關閉的，并且沒有任何線程能通過，當到達結束狀态時，這扇門會打開允許所有的線程通過。當閉鎖到達結束狀态後，将不會再改變狀态，是以這扇門将永遠保持打開狀态。閉鎖可以用來確定某些活動指導其他活動都完成後才繼續執行。CountDownLatch就是一種靈活的閉鎖實作。

##死鎖

死鎖是指兩個或兩個以上的程序在執行過程中，因争奪資源而造成的一種互相等待的現象，若無外力作用，他們都将無法推進下去。這是一個嚴重的問題，因為死鎖會讓你的程式挂起無法完成任務，死鎖的發生必須滿足一下4個條件：

• 互斥條件：一個資源每次隻能被一個程序使用。
• 請求與保持條件：一個程序因請求資源而阻塞時，對已獲得的資源保持不放。
• 不剝奪條件：程序已獲得的資源，在未使用完之前，不能強行剝奪。
• 循環等待條件：若幹程序之間形成一種頭尾相接的循環等待資源關系。

避免死鎖最簡單的方法就是阻止循環等待條件，将系統中所有的資源設定标志位、排序，規定所有的程序申請資源必須以一定的順序做操作來避免死鎖。

##活鎖

LiveLock是一種形式活躍性問題，該問題盡管不會阻塞線程，但也不能繼續執行，因為線程将不斷重複執行相同的操作，而且總會失敗。活鎖通常發送在處理事務消息的應用程式中：如果不能成功地處理某個消息，那麼消息處理機制将復原整個事務，并将它重新放到隊列的開頭：如果不能成功地處理某個消息，那麼消息處理機制将復原整個事務，并将它重新放到隊列的開頭。如果消息處理器在處理某種特定類型的消息時存在錯誤并導緻它失敗，那麼每當這個消息從隊列中取出并傳遞到存在錯誤的處理器時，都會發生事務復原。由于這條消息又被放回到隊列開頭，是以處理器将被反複調用，并傳回相同的結果。

1. 《深入了解Java虛拟機》周志明著
2. 《Java并發程式設計的藝術》方騰飛等著
3. Java對象大小内幕淺析
4. JVM内部細節之一：synchronized關鍵字及實作細節（輕量級鎖Lightweight Locking）
5. JVM内部細節之二：偏向鎖（Biased Locking）