1. Java語言中的線程安全

按照線程安全的“安全程度”由強(qiáng)至弱來排序，可以將Java語言中各種操作共享的數(shù)據(jù)分為以下五類：不可變、絕對(duì)線程安全、相對(duì)線程安全、線程兼容和線程對(duì)立。

1.1 不可變

不可變的對(duì)象一定是線程安全的，無論是對(duì)象的方法實(shí)現(xiàn)還是方法的調(diào)用者，都不需要再進(jìn)行任何線程安全保障措施。

Java語言中，如果多線程共享的數(shù)據(jù)是一個(gè)基本數(shù)據(jù)類型，那么只要定義時(shí)使用 final 關(guān)鍵字修飾他就可以保證它是不可變的，如果共享數(shù)據(jù)是一個(gè)對(duì)象類型，由于Java語言目前暫時(shí)還沒有提供值類型的支持，那就需要對(duì)象自行保證其行為不會(huì)對(duì)其狀態(tài)產(chǎn)生任何影響才行。

例如：java.lang.String 類的對(duì)象實(shí)例，它是一個(gè)典型的不可變對(duì)象，用戶調(diào)用它的 substring()、replace() 和 concat() 這些方法都不會(huì)影響它原來的值，只會(huì)返回一個(gè)新構(gòu)造的字符串對(duì)象。

保證對(duì)象行為不影響自己狀態(tài)的途徑有很多種，最簡單的一種就是把對(duì)象里面帶有狀態(tài)的變量都聲明為 final，這樣在構(gòu)造函數(shù)結(jié)束之后，它就是不可變的，例如下面代碼中 java.lang.Integer 的構(gòu)造函數(shù)，它通過將內(nèi)部狀態(tài)變量 value 定義為 final 來保障狀態(tài)不變 ：

/**
 * 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 等數(shù)值包裝類型、BigInteger 和 BigDecimal 等大數(shù)據(jù)類型。但同為Number子類型的原子類 AtomicInteger 和 AtomicLong 則是可變的。

1.2 絕對(duì)線程安全

Java API中標(biāo)注自己是線程安全的類，大多數(shù)都不是絕對(duì)的線程安全。java.util.Vector 是個(gè)線程安全的容器，add()、get()、size() 等方法都是被synchronized修飾的，保證了具備原子性、可見性和有序性。不過，就算是所有方法都被synchronized修飾，那也不意味著調(diào)用它的時(shí)候就不需要同步手段了。

如下代碼，對(duì) Vector 線程安全性的測(cè)試 ：

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(); 
      //不要同時(shí)產(chǎn)生過多的線程，否則會(huì)導(dǎo)致操作系統(tǒng)假死 
      while (Thread.activeCount() > 20);
   }
}

運(yùn)行結(jié)果如下：

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() 方法都是同步的，但是在多線程的環(huán)境中，如果不在方法調(diào)用端做額外的同步措施，使用這段代碼仍然是不安全的。因?yàn)槿绻硪粋€(gè)線程恰好在錯(cuò)誤的時(shí)間里刪除了一個(gè)元素，導(dǎo)致序號(hào)i已經(jīng)不再可用，再用i訪問數(shù)組就會(huì)拋出一個(gè) ArrayIndexOutOfBoundsException 異常。如果要保證這段代碼能正確執(zhí)行下去，我們不得不把 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一定要做到絕對(duì)的線程安全，那就必須在它內(nèi)部維護(hù)一組一致性的快照訪問才行，每次對(duì)其中元素進(jìn)行改動(dòng)都要產(chǎn)生新的快照，這樣要付出的時(shí)間和空間成本都是非常大的。

1.3 相對(duì)線程安全

相對(duì)線程安全就是我們通常意義上所講的線程安全，它需要保證對(duì)這個(gè)對(duì)象單次的操作是線程安全的，我們?cè)谡{(diào)用的時(shí)候不需要進(jìn)行額外的保障措施，但是對(duì)于一些特定順序的連續(xù)調(diào)用，就可能需要在調(diào)用端使用額外的同步手段來保證調(diào)用的正確性。

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

1.4 線程兼容

線程兼容是指對(duì)象本身并不是線程安全的，但是可以通過在調(diào)用端正確地使用同步手段來保證對(duì)象在并發(fā)環(huán)境中可以安全地使用。我們平常說一個(gè)類不是線程安全的，通常就是指這種情況。Java類庫API中大部分的類都是線程兼容的，如與前面的 Vector 和 HashTable 相對(duì)應(yīng)的集合類 ArrayList 和 HashMap 等。

1.5 線程對(duì)立

線程對(duì)立是指不管調(diào)用端是否采取了同步措施，都無法在多線程環(huán)境中并發(fā)使用代碼。由于Java 語言天生就支持多線程的特性，線程對(duì)立這種排斥多線程的代碼是很少出現(xiàn)的，而且通常都是有害的，應(yīng)當(dāng)盡量避免。

2. 線程安全的實(shí)現(xiàn)方法

2.1 互斥同步

互斥同步（Mutual Exclusion & Synchronization）是一種最常見也是最主要的并發(fā)正確性保障手段。同步是指在多個(gè)線程并發(fā)訪問共享數(shù)據(jù)時(shí)，保證共享數(shù)據(jù)在同一個(gè)時(shí)刻只被一個(gè)線程使用。而互斥是實(shí)現(xiàn)同步的一種手段，臨界區(qū)（Critical Section）、互斥量（Mutex）和信號(hào)量（Semaphore）都是常見的互斥實(shí)現(xiàn)方式。因此在“互斥同步”這四個(gè)字里面，互斥是因，同步是果；互斥是方法，同步是目的。

在 Java 里面，最基本的互斥同步手段就是 synchronized 關(guān)鍵字，這是一種塊結(jié)構(gòu)（Block Structured）的同步語法。synchronized 關(guān)鍵字經(jīng)過 Javac 編譯之后，會(huì)在同步塊的前后分別形成 monitorenter 和 monitorexit 這兩個(gè)字節(jié)碼指令。這兩個(gè)字節(jié)碼指令都需要一個(gè) reference 類型的參數(shù)來指明要鎖定和解鎖的對(duì)象。

如果 Java 源碼中的 synchronized 明確指定了對(duì)象參數(shù)，那就以這個(gè)對(duì)象的引用作為 reference；如果沒有明確指定，那將根據(jù) synchronized 修飾的方法類型（如實(shí)例方法或類方法），來決定是取代碼所在的對(duì)象實(shí)例還是取類型對(duì)應(yīng)的 Class 對(duì)象來作為線程要持有的鎖。

在執(zhí)行 monitorenter 指令時(shí)，首先要去嘗試獲取對(duì)象的鎖。如果這個(gè)對(duì)象沒被鎖定，或者當(dāng)前線程已經(jīng)持有了那個(gè)對(duì)象的鎖，就把鎖的計(jì)數(shù)器的值增加一，而在執(zhí)行 monitorexit 指令時(shí)會(huì)將鎖計(jì)數(shù)器的值減一。一旦計(jì)數(shù)器的值為零，鎖隨即就被釋放了。如果獲取對(duì)象鎖失敗，那當(dāng)前線程就應(yīng)當(dāng)被阻塞等待，直到請(qǐng)求鎖定的對(duì)象被持有它的線程釋放為止。

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

被 synchronized 修飾的同步塊對(duì)同一條線程來說是可重入的。這意味著同一線程反復(fù)進(jìn)入同步塊也不會(huì)出現(xiàn)自己把自己鎖死的情況。被 synchronized 修飾的同步塊在持有鎖的線程執(zhí)行完畢并釋放鎖之前，會(huì)無條件地阻塞后面其他線程的進(jìn)入。這意味著無法像處理某些數(shù)據(jù)庫中的鎖那樣，強(qiáng)制已獲取鎖的線程釋放鎖；也無法強(qiáng)制正在等待鎖的線程中斷等待或超時(shí)退出。

從執(zhí)行成本的角度看，synchronized 持有鎖是Java語言中一個(gè)重量級(jí)（Heavy-Weight）的操作。主流 Java 虛擬機(jī)實(shí)現(xiàn)中，Java 的線程是映射到操作系統(tǒng)的原生內(nèi)核線程之上的，如果要阻塞或喚醒一條線程，則需要操作系統(tǒng)來幫忙完成，這就不可避免地陷入用戶態(tài)到核心態(tài)的轉(zhuǎn)換中，進(jìn)行這種狀態(tài)轉(zhuǎn)換需要耗費(fèi)很多的處理器時(shí)間。

實(shí)際上，虛擬機(jī)本身會(huì)對(duì) synchronized 持鎖操作進(jìn)行一些優(yōu)化，譬如在通知操作系統(tǒng)阻塞線程之前加入一段自旋等待過程，以避免頻繁地切入核心態(tài)之中（這個(gè)問題下面小節(jié)再討論）。

3. 鎖優(yōu)化

3.1 自旋鎖與自適應(yīng)自旋

自旋鎖：即，當(dāng)一個(gè)線程去競爭共享資源時(shí)，該資源已被其他線程占用，這時(shí)該線程不會(huì)立刻進(jìn)入掛起阻塞狀態(tài)，而是通過不斷自旋，等待共享資源使用權(quán)被持鎖線程釋放。當(dāng)然，不可能讓一個(gè)線程一直自旋等待下去，自旋等待的時(shí)間是必須有一定的限度的，如果自旋超過了限定的次數(shù)仍然沒有成功獲得鎖，就應(yīng)當(dāng)使用傳統(tǒng)的方式去掛起線程。自旋次數(shù)的默認(rèn)值是 10 次，用戶也可以使用參數(shù) -XX：PreBlockSpin 來自行更改。

在JDK 6中對(duì)自旋鎖的優(yōu)化，引入了自適應(yīng)的自旋。自適應(yīng)意味著自旋的時(shí)間不再是固定的了，而是由前一次在同一個(gè)鎖上的自旋時(shí)間及鎖的擁有者的狀態(tài)來決定的。如果在同一個(gè)鎖對(duì)象上，自旋等待剛剛成功獲得過鎖，并且持有鎖的線程正在運(yùn)行中，那么虛擬機(jī)就會(huì)認(rèn)為這次自旋也很有可能再次成功，進(jìn)而允許自旋等待持續(xù)相對(duì)更長的時(shí)間，比如持續(xù)100次忙循環(huán)。另一方面，如果對(duì)于某個(gè)鎖，自旋很少成功獲得過鎖，那在以后要獲取這個(gè)鎖時(shí)將有可能直接省略掉自旋過程，以避免浪費(fèi)處理器資源。

3.2 鎖消除

鎖消除：是指虛擬機(jī)即時(shí)編譯器在運(yùn)行時(shí)，對(duì)一些代碼要求同步，但是對(duì)被檢測(cè)到不可能存在共享資源競爭的鎖進(jìn)行消除。

鎖消除的主要判定依據(jù)來源于逃逸分析的數(shù)據(jù)支持，如果判斷到一段代碼中，在堆上的所有數(shù)據(jù)都不會(huì)逃逸出去被其他線程訪問到，那就可以把它們當(dāng)作棧上數(shù)據(jù)對(duì)待，認(rèn)為它們是線程私有的，同步加鎖自然就無須再進(jìn)行。

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

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

由于 String 是一個(gè)不可變的類，對(duì)字符串的連接操作總是通過生成新的 String 對(duì)象來進(jìn)行的，因此 Javac 編譯器會(huì)對(duì) String 連接做自動(dòng)優(yōu)化。

在JDK 5之前，字符串加法會(huì)轉(zhuǎn)化為 StringBuffer 對(duì)象的連續(xù) append() 操作，在JDK 5及以后的版本中，會(huì)轉(zhuǎn)化為 StringBuilder 對(duì)象的連續(xù) append() 操作。

優(yōu)化為如下所示：（示例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(); 
}

現(xiàn)在大家還認(rèn)為這段代碼沒有涉及同步嗎？每個(gè) StringBuffer.append() 方法中都有一個(gè)同步塊，鎖就是 sb 對(duì)象。虛擬機(jī)觀察變量 sb，經(jīng)過逃逸分析后會(huì)發(fā)現(xiàn)它的動(dòng)態(tài)作用域被限制在 concatString() 方法內(nèi)部。也就是 sb 的所有引用都永遠(yuǎn)不會(huì)逃逸到 concatString() 方法之外，其他線程無法訪問到它，所以這里雖然有鎖，但是可以被安全地消除掉。在解釋執(zhí)行時(shí)這里仍然會(huì)加鎖，但在經(jīng)過服務(wù)端編譯器的即時(shí)編譯之后，這段代碼就會(huì)忽略所有的同步措施而直接執(zhí)行。

客觀地說，既然談到鎖消除與逃逸分析，那虛擬機(jī)就不可能是JDK 5之前的版本，所以實(shí)際上會(huì)轉(zhuǎn)化為非線程安全的 StringBuilder 來完成字符串拼接，并不會(huì)加鎖。但是這也不影響筆者用這個(gè)例子證明 Java 對(duì)象中同步的普遍性。

3.3 鎖粗化

原則上，我們?cè)诰帉懘a的時(shí)候，總是推薦將同步塊的作用范圍限制得盡量小——只在共享數(shù)據(jù)的實(shí)際作用域中才進(jìn)行同步，這樣是為了使得需要同步的操作數(shù)量盡可能變少，即使存在鎖競爭，等待鎖的線程也能盡可能快地拿到鎖。

大多數(shù)情況下，上面的原則都是正確的，但是如果一系列的連續(xù)操作都對(duì)同一個(gè)對(duì)象反復(fù)加鎖和解鎖，甚至加鎖操作是出現(xiàn)在循環(huán)體之中的，那即使沒有線程競爭，頻繁地進(jìn)行互斥同步操作也會(huì)導(dǎo)致不必要的性能損耗。

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

總之，如果虛擬機(jī)探測(cè)到有這樣一串零碎的操作都對(duì)同一個(gè)對(duì)象加鎖，將會(huì)把加鎖同步的范圍擴(kuò)展（粗化）到整個(gè)操作序列的外部。

3.4 輕量級(jí)鎖

輕量級(jí)鎖是JDK 6時(shí)加入的新型鎖機(jī)制，它名字中的“輕量級(jí)”是相對(duì)于使用操作系統(tǒng)互斥量來實(shí)現(xiàn)的傳統(tǒng)鎖而言的，因此傳統(tǒng)的鎖機(jī)制就被稱為“重量級(jí)”鎖。輕量級(jí)鎖并不是用來代替重量級(jí)鎖的，它設(shè)計(jì)的初衷是在沒有多線程競爭的前提下，減少傳統(tǒng)的重量級(jí)鎖使用操作系統(tǒng)互斥量產(chǎn)生的性能消耗。

由于對(duì)象頭信息是與對(duì)象自身定義的數(shù)據(jù)無關(guān)的額外存儲(chǔ)成本，考慮到Java虛擬機(jī)的空間使用效率，Mark Word被設(shè)計(jì)成一個(gè)非固定的動(dòng)態(tài)數(shù)據(jù)結(jié)構(gòu)，以便在極小的空間內(nèi)存儲(chǔ)盡量多的信息。它會(huì)根據(jù)對(duì)象的狀態(tài)復(fù)用自己的存儲(chǔ)空間。

例如在32位的HotSpot虛擬機(jī)中，對(duì)象未被鎖定的狀態(tài)下，Mark Word的32個(gè)比特空間里的25個(gè)比特將用于存儲(chǔ)對(duì)象哈希碼，4個(gè)比特用于存儲(chǔ)對(duì)象分代年齡，2個(gè)比特用于存儲(chǔ)鎖標(biāo)志位，還有 1 個(gè)比特固定為 0（這表示未進(jìn)入偏向模式）。

對(duì)象除了未被鎖定的正常狀態(tài)外，還有輕量級(jí)鎖定、重量級(jí)鎖定、GC標(biāo)記、可偏向等幾種不同狀態(tài)，這些狀態(tài)下對(duì)象頭的存儲(chǔ)內(nèi)容如下表所示：

在代碼即將進(jìn)入同步塊的時(shí)候，如果此同步對(duì)象沒有被鎖定（鎖標(biāo)志位為“01”狀態(tài)），虛擬機(jī)首先將在當(dāng)前線程的棧幀中建立一個(gè)名為鎖記錄（Lock Record）的空間，用于存儲(chǔ)鎖對(duì)象目前的Mark Word的拷貝，這時(shí)候線程堆棧與對(duì)象頭的狀態(tài)如下圖所示：

然后，虛擬機(jī)將使用CAS操作嘗試把對(duì)象的Mark Word更新為指向Lock Record的指針。如果這個(gè)更新動(dòng)作成功了，即代表該線程擁有了這個(gè)對(duì)象的鎖，并且對(duì)象Mark Word的鎖標(biāo)志位（Mark Word的最后兩個(gè)比特）將轉(zhuǎn)變?yōu)椤?0”，表示此對(duì)象處于輕量級(jí)鎖定狀態(tài)。這時(shí)候線程堆棧與對(duì)象頭的狀態(tài)如下圖所示：

如果這個(gè)更新操作失敗了，那就意味著至少存在一條線程與當(dāng)前線程競爭獲取該對(duì)象的鎖。虛擬機(jī)首先會(huì)檢查對(duì)象的Mark Word是否指向當(dāng)前線程的棧幀，如果是，說明當(dāng)前線程已經(jīng)擁有了這個(gè)對(duì)象的鎖，那直接進(jìn)入同步塊繼續(xù)執(zhí)行就可以了，否則就說明這個(gè)鎖對(duì)象已經(jīng)被其他線程搶占了。如果出現(xiàn)兩條以上的線程爭用同一個(gè)鎖的情況，那輕量級(jí)鎖就不再有效，必須要膨脹為重量級(jí)鎖，鎖標(biāo)志的狀態(tài)值變?yōu)椤?0”，此時(shí)Mark Word中存儲(chǔ)的就是指向重量級(jí)鎖（互斥量）的指針，后面等待鎖的線程也必須進(jìn)入阻塞狀態(tài)。

上面描述的是輕量級(jí)鎖的加鎖過程，它的解鎖過程也同樣是通過CAS操作來進(jìn)行的，如果對(duì)象的Mark Word仍然指向線程的鎖記錄，那就用CAS操作把對(duì)象當(dāng)前的Mark Word和線程中復(fù)制的Displaced Mark Word替換回來。假如能夠成功替換，那整個(gè)同步過程就順利完成了；如果替換失敗，則說明有其他線程嘗試過獲取該鎖，就要在釋放鎖的同時(shí)，喚醒被掛起的線程。

輕量級(jí)鎖能提升程序同步性能的依據(jù)是“對(duì)于絕大部分的鎖，在整個(gè)同步周期內(nèi)都是不存在競爭的”這一經(jīng)驗(yàn)法則。如果沒有競爭，輕量級(jí)鎖便通過CAS操作成功避免了使用互斥量的開銷；但如果確實(shí)存在鎖競爭，除了互斥量的本身開銷外，還額外發(fā)生了CAS操作的開銷。因此在有競爭的情況下，輕量級(jí)鎖反而會(huì)比傳統(tǒng)的重量級(jí)鎖更慢。

3.5 偏向鎖

偏向鎖也是JDK 6中引入的一項(xiàng)鎖優(yōu)化措施，它的目的是消除數(shù)據(jù)在無競爭情況下的同步原語，進(jìn)一步提高程序的運(yùn)行性能。如果說輕量級(jí)鎖是在無競爭的情況下使用CAS操作去消除同步使用的互斥量，那偏向鎖就是在無競爭的情況下把整個(gè)同步都消除掉，連CAS操作都不去做了。

偏向鎖中的“偏”，就是偏心的“偏”、偏袒的“偏”。它的意思是這個(gè)鎖會(huì)偏向于第一個(gè)獲得它的線程，如果在接下來的執(zhí)行過程中，該鎖一直沒有被其他的線程獲取，則持有偏向鎖的線程將永遠(yuǎn)不需要再進(jìn)行同步。

假設(shè)當(dāng)前虛擬機(jī)啟用了偏向鎖（啟用參數(shù)-XX：+UseBiased Locking，這是自JDK 6起HotSpot虛擬機(jī)的默認(rèn)值），那么當(dāng)鎖對(duì)象第一次被線程獲取的時(shí)候，虛擬機(jī)將會(huì)把對(duì)象頭中的標(biāo)志位設(shè)置為“01”、把偏向模式設(shè)置為“1”，表示進(jìn)入偏向模式。同時(shí)使用CAS操作把獲取到這個(gè)鎖的線程的ID記錄在對(duì)象的Mark Word之中。如果CAS操作成功，持有偏向鎖的線程以后每次進(jìn)入這個(gè)鎖相關(guān)的同步塊時(shí)，虛擬機(jī)都可以不再進(jìn)行任何同步操作（例如加鎖、解鎖及對(duì)Mark Word的更新操作 等）。

一旦出現(xiàn)另外一個(gè)線程去嘗試獲取這個(gè)鎖的情況，偏向模式就馬上宣告結(jié)束。根據(jù)鎖對(duì)象目前是否處于被鎖定的狀態(tài)決定是否撤銷偏向（偏向模式設(shè)置為“0”），撤銷后標(biāo)志位恢復(fù)到未鎖定（標(biāo)志位為“01”）或輕量級(jí)鎖定（標(biāo)志位為“00”）的狀態(tài)，后續(xù)的同步操作就按照上面介紹的輕量級(jí)鎖那樣去執(zhí)行。偏向鎖、輕量級(jí)鎖的狀態(tài)轉(zhuǎn)化及對(duì)象Mark Word的關(guān)系如下圖所示：

總結(jié)

本篇文章就到這里了，希望能夠給你帶來幫助，也希望您能夠多多關(guān)注腳本之家的更多內(nèi)容！