Java中的鎖

標籤：

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

公平鎖和非公平鎖

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

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

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

自旋鎖

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

虛擬機器的Team Dev注意到在許多應用上，共用資料的鎖定狀態只會持續很短的一段時間，為了這段時間取掛起和恢複現場並不值得。如果物理機器有一個以上的處理器，能讓兩個或以上的線程同時並存執行，我們就可以讓後面請求鎖的那個線程“稍等一下“，但不放棄處理器的執行時間，看看持有鎖的線程是否很快就會釋放鎖。為了讓線程等待，我們只需讓線程執行一個忙迴圈（自旋），這項技術就是所謂的自旋鎖。

自旋等待不能代替阻塞。自旋等待本身雖然避免了線程切換的開銷，但它是要佔用處理器時間的，因此，如果鎖被佔用的時間很短，自旋當代的效果就會非常好，反之，如果鎖被佔用的時間很長，那麼自旋的線程只會拜拜浪費處理器資源。因此，自旋等待的時間必須要有一定的限度，如果自旋超過了限定次數（預設是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）	01

注意到這裡的無鎖和偏向鎖在”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. 協程：在單線程裡實現多任務的調度，並在單線程裡維持多個任務間的切換。

參考資料
1. 《深入理解Java虛擬機器》周志明著
2. 《Java並發編程的藝術》方騰飛等著
3. Java對象大小內幕淺析
4. JVM內部細節之一：synchronized關鍵字及實現細節（輕量級鎖Lightweight Locking）
5. JVM內部細節之二：偏向鎖（Biased Locking）

Java中的鎖