深入理解JVM虛擬機讀書筆記——鎖優化

注：本文參考自周志明老師的著作《深入理解Java虛擬機（第3版）》，相關電子書可以關注WX公眾號：興趣使然的草帽路飛，回復 001 獲取，

1. Java語言中的執行緒安全

按照執行緒安全的“安全程度”由強至弱來排序，可以將Java語言中各種操作共享的資料分為以下五類：不可變、絕對執行緒安全、相對執行緒安全、執行緒兼容和執行緒對立，

1.1 不可變

不可變的物件一定是執行緒安全的，無論是物件的方法實作還是方法的呼叫者，都不需要再進行任何執行緒安全保障措施，

Java語言中，如果多執行緒共享的資料是一個基本資料型別，那么只要定義時使用 final 關鍵字修飾他就可以保證它是不可變的，如果共享資料是一個物件型別，由于Java語言目前暫時還沒有提供值型別的支持，那就需要物件自行保證其行為不會對其狀態產生任何影響才行，

例如：java.lang.String 類的物件實體，它是一個典型的不可變物件，用戶呼叫它的 substring()、replace() 和 concat() 這些方法都不會影響它原來的值，只會回傳一個新構造的字串物件，

保證物件行為不影響自己狀態的途徑有很多種，最簡單的一種就是把物件里面帶有狀態的變數都宣告為 final，這樣在建構式結束之后，它就是不可變的，例如下面代碼中 java.lang.Integer 的建構式，它通過將內部狀態變數 value 定義為 final 來保障狀態不變 ：

/**
 * The value of the <code>Integer</code>.
 * @serial 
 */ 
private final int value;
/**
 * Constructs a newly allocated <code>Integer</code> object that 
 * represents the specified <code>int</code> value. 
 *
 * @param value the value to be represented by the 
 * <code>Integer</code> object. 
 */ 
public Integer(int value) { 
  	this.value = value; 
}

在Java類別庫API中符合不可變要求的型別，除了上面提到的 String 之外，常用的還有列舉型別及 java.lang.Number 的部分子類，如 Long 和 Double 等數值包裝型別、BigInteger 和 BigDecimal 等大資料型別，但同為Number子型別的原子類 AtomicInteger 和 AtomicLong 則是可變的，

1.2 絕對執行緒安全

Java API中標注自己是執行緒安全的類，大多數都不是絕對的執行緒安全，java.util.Vector 是個執行緒安全的容器，add()、get()、size() 等方法都是被synchronized修飾的，保證了具備原子性、可見性和有序性，不過，就算是所有方法都被synchronized修飾，那也不意味著呼叫它的時候就不需要同步手段了，

如下代碼，對 Vector 執行緒安全性的測驗 ：

private static Vector<Integer> vector = new Vector<Integer>();
public static void main(String[] args) {
  	while (true) { 
    	for (int i = 0; i < 10; i++) {
        	vector.add(i); 
      }
      
      Thread removeThread = new Thread(new Runnable() {
        @Override 
        public void run() {
          for (int i = 0; i < vector.size(); i++) { 
            vector.remove(i);
          }
        }
      };
                                       
      Thread printThread = new Thread(new Runnable() { 
        @Override 
        public void run() { 
          for (int i = 0; i < vector.size(); i++) { 
            System.out.println((vector.get(i))); 
          } 
        } 
      });
                                       
      removeThread.start(); 
      printThread.start(); 
      //不要同時產生過多的執行緒，否則會導致作業系統假死 
      while (Thread.activeCount() > 20);
   }
}

運行結果如下：

Exception in thread "Thread-132" java.lang.ArrayIndexOutOfBoundsException:
Array index out of range: 17 
  at java.util.Vector.remove(Vector.java:777) 
  at org.fenixsoft.mulithread.VectorTest$1.run(VectorTest.java:21) 
  at java.lang.Thread.run(Thread.java:662)

盡管這里使用到的 Vector 的 get()、remove() 和 size() 方法都是同步的，但是在多執行緒的環境中，如果不在方法呼叫端欄位外的同步措施，使用這段代碼仍然是不安全的，因為如果另一個執行緒恰好在錯誤的時間里洗掉了一個元素，導致序號i已經不再可用，再用i訪問陣列就會拋出一個 ArrayIndexOutOfBoundsException 例外，如果要保證這段代碼能正確執行下去，我們不得不把 removeThread 和 printThread 的定義改成如下所示：

Thread removeThread = new Thread(new Runnable() { 
  	@Override 
  	public void run() { 
    	synchronized (vector) { 
      	for (int i = 0; i < vector.size(); i++) { 
        	vector.remove(i); 
      	} 
    	} 
  	} 
});

Thread printThread = new Thread(new Runnable() { 
  	@Override 
  	public void run() { 
    	synchronized (vector) { 
      	for (int i = 0; i < vector.size(); i++) { 
        	System.out.println((vector.get(i))); 
      	} 
    	} 
  	} 
});

假如Vector一定要做到絕對的執行緒安全，那就必須在它內部維護一組一致性的快照訪問才行，每次對其中元素進行改動都要產生新的快照，這樣要付出的時間和空間成本都是非常大的，

1.3 相對執行緒安全

相對執行緒安全就是我們通常意義上所講的執行緒安全，它需要保證對這個物件單次的操作是執行緒安全的，我們在呼叫的時候不需要進行額外的保障措施，但是對于一些特定順序的連續呼叫，就可能需要在呼叫端使用額外的同步手段來保證呼叫的正確性，

在Java語言中，大部分聲稱執行緒安全的類都屬于這種型別，例如Vector、HashTable、Collections的 synchronizedCollection() 方法包裝的集合等，

1.4 執行緒兼容

執行緒兼容是指物件本身并不是執行緒安全的，但是可以通過在呼叫端正確地使用同步手段來保證物件在并發環境中可以安全地使用，我們平常說一個類不是執行緒安全的，通常就是指這種情況，Java類別庫API中大部分的類都是執行緒兼容的，如與前面的 Vector 和 HashTable 相對應的集合類 ArrayList 和 HashMap 等，

1.5 執行緒對立

執行緒對立是指不管呼叫端是否采取了同步措施，都無法在多執行緒環境中并發使用代碼，由于Java 語言天生就支持多執行緒的特性，執行緒對立這種排斥多執行緒的代碼是很少出現的，而且通常都是有害的，應當盡量避免，

2. 執行緒安全的實作方法

2.1 互斥同步

互斥同步（Mutual Exclusion & Synchronization）是一種最常見也是最主要的并發正確性保障手段，同步是指在多個執行緒并發訪問共享資料時，保證共享資料在同一個時刻只被一個執行緒使用，而互斥是實作同步的一種手段，臨界區（Critical Section）、互斥量（Mutex）和信號量（Semaphore）都是常見的互斥實作方式，因此在“互斥同步”這四個字里面，互斥是因，同步是果；互斥是方法，同步是目的，

在 Java 里面，最基本的互斥同步手段就是 synchronized 關鍵字，這是一種塊結構（Block Structured）的同步語法，synchronized 關鍵字經過 Javac 編譯之后，會在同步塊的前后分別形成 monitorenter 和 monitorexit 這兩個位元組碼指令，這兩個位元組碼指令都需要一個 reference 型別的引數來指明要鎖定和解鎖的物件，

如果 Java 原始碼中的 synchronized 明確指定了物件引數，那就以這個物件的參考作為 reference；如果沒有明確指定，那將根據 synchronized 修飾的方法型別（如實體方法或類方法），來決定是取代碼所在的物件實體還是取型別對應的 Class 物件來作為執行緒要持有的鎖，

在執行 monitorenter 指令時，首先要去嘗試獲取物件的鎖，如果這個物件沒被鎖定，或者當前執行緒已經持有了那個物件的鎖，就把鎖的計數器的值增加一，而在執行 monitorexit 指令時會將鎖計數器的值減一，一旦計數器的值為零，鎖隨即就被釋放了，如果獲取物件鎖失敗，那當前執行緒就應當被阻塞等待，直到請求鎖定的物件被持有它的執行緒釋放為止，

由上面的描述，可得出 synchronized 鎖的一些特性：

• 被 synchronized 修飾的同步塊對同一條執行緒來說是可重入的，這意味著同一執行緒反復進入同步塊也不會出現自己把自己鎖死的情況，
• 被 synchronized 修飾的同步塊在持有鎖的執行緒執行完畢并釋放鎖之前，會無條件地阻塞后面其他執行緒的進入，這意味著無法像處理某些資料庫中的鎖那樣，強制已獲取鎖的執行緒釋放鎖；也無法強制正在等待鎖的執行緒中斷等待或超時退出，

從執行成本的角度看，synchronized 持有鎖是Java語言中一個重量級（Heavy-Weight）的操作，主流 Java 虛擬機實作中，Java 的執行緒是映射到作業系統的原生內核執行緒之上的，如果要阻塞或喚醒一條執行緒，則需要作業系統來幫忙完成，這就不可避免地陷入用戶態到核心態的轉換中，進行這種狀態轉換需要耗費很多的處理器時間，

實際上，虛擬機本身會對 synchronized 持鎖操作進行一些優化，譬如在通知作業系統阻塞執行緒之前加入一段自旋等待程序，以避免頻繁地切入核心態之中（這個問題下面小節再討論），

3. 鎖優化

3.1 自旋鎖與自適應自旋

自旋鎖：即，當一個執行緒去競爭共享資源時，該資源已被其他執行緒占用，這時該執行緒不會立刻進入掛起阻塞狀態，而是通過不斷自旋，等待共享資源使用權被持鎖執行緒釋放，當然，不可能讓一個執行緒一直自旋等待下去，自旋等待的時間是必須有一定的限度的，如果自旋超過了限定的次數仍然沒有成功獲得鎖，就應當使用傳統的方式去掛起執行緒，自旋次數的默認值是 10 次，用戶也可以使用引數 -XX：PreBlockSpin 來自行更改，

在JDK 6中對自旋鎖的優化，引入了自適應的自旋，自適應意味著自旋的時間不再是固定的了，而是由前一次在同一個鎖上的自旋時間及鎖的擁有者的狀態來決定的，如果在同一個鎖物件上，自旋等待剛剛成功獲得過鎖，并且持有鎖的執行緒正在運行中，那么虛擬機就會認為這次自旋也很有可能再次成功，進而允許自旋等待持續相對更長的時間，比如持續100次忙回圈，另一方面，如果對于某個鎖，自旋很少成功獲得過鎖，那在以后要獲取這個鎖時將有可能直接省略掉自旋程序，以避免浪費處理器資源，

3.2 鎖消除

鎖消除：是指虛擬機即時編譯器在運行時，對一些代碼要求同步，但是對被檢測到不可能存在共享資源競爭的鎖進行消除，

鎖消除的主要判定依據來源于逃逸分析的資料支持，如果判斷到一段代碼中，在堆上的所有資料都不會逃逸出去被其他執行緒訪問到，那就可以把它們當作堆疊上資料對待，認為它們是執行緒私有的，同步加鎖自然就無須再進行，

示例如下：（示例2-1）

public String concatString(String s1, String s2, String s3) { 
  return s1 + s2 + s3; 
}

由于 String 是一個不可變的類，對字串的連接操作總是通過生成新的 String 物件來進行的，因此 Javac 編譯器會對 String 連接做自動優化，

在JDK 5之前，字串加法會轉化為 StringBuffer 物件的連續 append() 操作，在JDK 5及以后的版本中，會轉化為 StringBuilder 物件的連續 append() 操作，

優化為如下所示：（示例2-2）

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() 方法中都有一個同步塊，鎖就是 sb 物件，虛擬機觀察變數 sb，經過逃逸分析后會發現它的動態作用域被限制在 concatString() 方法內部，也就是 sb 的所有參考都永遠不會逃逸到 concatString() 方法之外，其他執行緒無法訪問到它，所以這里雖然有鎖，但是可以被安全地消除掉，在解釋執行時這里仍然會加鎖，但在經過服務端編譯器的即時編譯之后，這段代碼就會忽略所有的同步措施而直接執行，

客觀地說，既然談到鎖消除與逃逸分析，那虛擬機就不可能是JDK 5之前的版本，所以實際上會轉化為非執行緒安全的 StringBuilder 來完成字串拼接，并不會加鎖，但是這也不影響筆者用這個例子證明 Java 物件中同步的普遍性，

3.3 鎖粗化

原則上，我們在撰寫代碼的時候，總是推薦將同步塊的作用范圍限制得盡量小——只在共享資料的實際作用域中才進行同步，這樣是為了使得需要同步的運算元量盡可能變少，即使存在鎖競爭，等待鎖的執行緒也能盡可能快地拿到鎖，

大多數情況下，上面的原則都是正確的，但是如果一系列的連續操作都對同一個物件反復加鎖和解鎖，甚至加鎖操作是出現在回圈體之中的，那即使沒有執行緒競爭，頻繁地進行互斥同步操作也會導致不必要的性能損耗，

（示例2-2）所示連續的 append() 方法就屬于這類情況，如果虛擬機探測到有這樣一串零碎的操作都對同一個物件加鎖，將會把加鎖同步的范圍擴展（粗化）到整個操作序列的外部，以（示例2-2）為例，就是擴展到第一個 append() 操作之前直至最后一個 append() 操作之后，這樣只需要加鎖一次就可以了，

總之，如果虛擬機探測到有這樣一串零碎的操作都對同一個物件加鎖，將會把加鎖同步的范圍擴展（粗化）到整個操作序列的外部，

3.4 輕量級鎖

輕量級鎖是JDK 6時加入的新型鎖機制，它名字中的“輕量級”是相對于使用作業系統互斥量來實作的傳統鎖而言的，因此傳統的鎖機制就被稱為“重量級”鎖，輕量級鎖并不是用來代替重量級鎖的，它設計的初衷是在沒有多執行緒競爭的前提下，減少傳統的重量級鎖使用作業系統互斥量產生的性能消耗，

由于物件頭資訊是與物件自身定義的資料無關的額外存盤成本，考慮到Java虛擬機的空間使用效率，Mark Word被設計成一個非固定的動態資料結構，以便在極小的空間記憶體儲盡量多的資訊，它會根據物件的狀態復用自己的存盤空間，

例如在32位的HotSpot虛擬機中，物件未被鎖定的狀態下，Mark Word的32個位元空間里的25個位元將用于存盤物件哈希碼，4個位元用于存盤物件分代年齡，2個位元用于存盤鎖標志位，還有 1 個位元固定為 0（這表示未進入偏向模式），

物件除了未被鎖定的正常狀態外，還有輕量級鎖定、重量級鎖定、GC標記、可偏向等幾種不同狀態，這些狀態下物件頭的存盤內容如下表所示：

在代碼即將進入同步塊的時候，如果此同步物件沒有被鎖定（鎖標志位為“01”狀態），虛擬機首先將在當前執行緒的堆疊幀中建立一個名為鎖記錄（Lock Record）的空間，用于存盤鎖物件目前的Mark Word的拷貝，這時候執行緒堆疊與物件頭的狀態如下圖所示：

然后，虛擬機將使用CAS操作嘗試把物件的Mark Word更新為指向Lock Record的指標，如果這個更新動作成功了，即代表該執行緒擁有了這個物件的鎖，并且物件Mark Word的鎖標志位（Mark Word的最后兩個位元）將轉變為“00”，表示此物件處于輕量級鎖定狀態，這時候執行緒堆疊與物件頭的狀態如下圖所示：

如果這個更新操作失敗了，那就意味著至少存在一條執行緒與當前執行緒競爭獲取該物件的鎖，虛擬機首先會檢查物件的Mark Word是否指向當前執行緒的堆疊幀，如果是，說明當前執行緒已經擁有了這個物件的鎖，那直接進入同步塊繼續執行就可以了，否則就說明這個鎖物件已經被其他執行緒搶占了，如果出現兩條以上的執行緒爭用同一個鎖的情況，那輕量級鎖就不再有效，必須要膨脹為重量級鎖，鎖標志的狀態值變為“10”，此時Mark Word中存盤的就是指向重量級鎖（互斥量）的指標，后面等待鎖的執行緒也必須進入阻塞狀態，

上面描述的是輕量級鎖的加鎖程序，它的解鎖程序也同樣是通過CAS操作來進行的，如果物件的Mark Word仍然指向執行緒的鎖記錄，那就用CAS操作把物件當前的Mark Word和執行緒中復制的Displaced Mark Word替換回來，假如能夠成功替換，那整個同步程序就順利完成了；如果替換失敗，則說明有其他執行緒嘗試過獲取該鎖，就要在釋放鎖的同時，喚醒被掛起的執行緒，

輕量級鎖能提升程式同步性能的依據是“對于絕大部分的鎖，在整個同步周期內都是不存在競爭的”這一經驗法則，如果沒有競爭，輕量級鎖便通過CAS操作成功避免了使用互斥量的開銷；但如果確實存在鎖競爭，除了互斥量的本身開銷外，還額外發生了CAS操作的開銷，因此在有競爭的情況下，輕量級鎖反而會比傳統的重量級鎖更慢，

3.5 偏向鎖

偏向鎖也是JDK 6中引入的一項鎖優化措施，它的目的是消除資料在無競爭情況下的同步原語，進一步提高程式的運行性能，如果說輕量級鎖是在無競爭的情況下使用CAS操作去消除同步使用的互斥量，那偏向鎖就是在無競爭的情況下把整個同步都消除掉，連CAS操作都不去做了，

偏向鎖中的“偏”，就是偏心的“偏”、偏袒的“偏”，它的意思是這個鎖會偏向于第一個獲得它的執行緒，如果在接下來的執行程序中，該鎖一直沒有被其他的執行緒獲取，則持有偏向鎖的執行緒將永遠不需要再進行同步，

假設當前虛擬機啟用了偏向鎖（啟用引數-XX：+UseBiased Locking，這是自JDK 6起HotSpot虛擬機的默認值），那么當鎖物件第一次被執行緒獲取的時候，虛擬機將會把物件頭中的標志位設定為“01”、把偏向模式設定為“1”，表示進入偏向模式，同時使用CAS操作把獲取到這個鎖的執行緒的ID記錄在物件的Mark Word之中，如果CAS操作成功，持有偏向鎖的執行緒以后每次進入這個鎖相關的同步塊時，虛擬機都可以不再進行任何同步操作（例如加鎖、解鎖及對Mark Word的更新操作 等），

一旦出現另外一個執行緒去嘗試獲取這個鎖的情況，偏向模式就馬上宣告結束，根據鎖物件目前是否處于被鎖定的狀態決定是否撤銷偏向（偏向模式設定為“0”），撤銷后標志位恢復到未鎖定（標志位為“01”）或輕量級鎖定（標志位為“00”）的狀態，后續的同步操作就按照上面介紹的輕量級鎖那樣去執行，偏向鎖、輕量級鎖的狀態轉化及物件Mark Word的關系如下圖所示：