這麼一輪操作結束之後，雖然我們在兩個線程中分別對count累加了一次，總共是兩次，但是count的值只變大了1，這時結果就出現了問題。這種在多個線程中對共享數據進行競爭性訪問的情況就被稱為數據競爭，可以理解為對共享數據的並發訪問會導致問題的情況就是數據競爭。

那麼我們如何解決這樣的數據競爭問題呢？

synchronized關鍵字

相信大多數讀者應該都知道synchronized這個關鍵字，它可以被用在方法定義或者是塊結構上，那麼它到底能發揮怎樣的作用呢？我們把它以塊結構的形式把count += 1;語句包圍起來看看。

for (int i = 0; i < 1000000; ++i) {
synchronized (this) {
count += 1;
}
}

運行之後可以看到，這次的輸出是兩百萬整了。在這裡，synchronized發揮的作用就是讓兩個線程互斥地執行count += 1;語句。所謂互斥也就是同一時間只能有一個線程執行，如果另一個線程同時也要執行的話則必須等到前一個線程完成操作退出synchronized語句塊之後才能進入。

這種同一時間只能被一個線程訪問的代碼塊就被稱為臨界區，而synchronized這樣的保護臨界區同時只能被一個線程進入的機制就被稱為互斥鎖。當一個線程因為另外一個線程已經獲取了鎖而陷入等待時，我們可以稱該線程被這個鎖阻塞了。

在Java中，synchronized的背後是對象鎖，每個不同的對象都會對應一個不同的鎖，同一個對象對應同一個鎖。只有獲取同一個鎖才能達到互斥訪問的作用，如果兩個線程分別獲取不同的鎖，那麼互相就不會影響了。所以在使用synchronized時，區分背後對應的是哪一個對象鎖就至關重要了。synchronized關鍵字可以被用在方法定義和塊結構兩種情況中，具體對應的鎖如下：

1. 以塊結構形式使用synchronized關鍵字，則獲取的就是synchronized關鍵字後小括弧中的對象所對應的鎖；
2. synchronized被標記在實例方法上，則獲取的就是this引用指向對象所對應的鎖；
3. synchronized被標記在類方法（靜態方法）上時，獲取的就是方法所在類的「類對象」所對應的鎖，這裡的類對象就可以理解為是每個類一個用於存放靜態欄位和靜態方法的對象。

因為synchronized一定要有一個對應的對象，所以我們自然不能將基本類型的變數傳入到synchronized後面的括弧中。

ReentrantLock

在Java 5中JDK引入了java.util.concurrent包，也許大家都或多或少聽說過這個包，在這個包中提供了大量使用的並發工具類，例如線程池、鎖、原子數據類等等，對Java語言的並發編程易用性和實際效率產生了跨越性的提高。而ReentrantLock就是這個包中的一員。

ReentrantLock發揮的作用與synchronized相同，都是作為互斥鎖使用的。下面是把之前的累加代碼改為使用ReentrantLock鎖的版本：

final ReentrantLock lock = new ReentrantLock();

Runnable task = new Runnable() {
public void run() {
for (int i = 0; i < 1000000; ++i) {
lock.lock();
try {
count += 1;
} finally {
lock.unlock();
}
}
}
};

運行之後的結果依然是兩百萬，說明ReentrantLock確實能起到保障互斥訪問臨界區的作用。但是既然ReentrantLock和synchronized的作用相同，而且從代碼來看使用synchronized還更方便，為什麼還要專門定義一個ReentrantLock這樣的類呢？

上面的代碼中，雖然使用ReentrantLock還要專門寫一個try..finally塊來保證鎖釋放，比較麻煩，但是也能從中看到一個好處就是我們可以決定加鎖的位置和釋放鎖的位置。我們甚至可以在一個方法中加鎖，而在另一個方法中解鎖，雖然這樣做會有風險。相對於傳統的synchronized，ReentrantLock還有下面的一些好處：

1. ReentrantLock可以實現帶有超時時間的鎖等待，我們可以通過tryLock方法進行加鎖，並傳入超時時間參數。如果超過了超時時間還麼有獲得鎖的話，那麼就tryLock方法就會返回false；
2. ReentrantLock可以使用公平性機制，讓先申請鎖的線程先獲得鎖，防止線程一直等待鎖但是獲取不到；
3. ReentrantLock可以實現讀寫鎖等更豐富的類型。

更簡便的方式——AtomicInteger

在java.util.concurrent包中，我們可以找到一個很有趣的子包atomic，在這個包中我們看到有很多以Atomic開頭的「包裝類型」，這些類會有什麼用呢？我們先來看一下前面的累加程序使用AtomicInteger該如何實現。

public class AtomicIntegerDemo {

private static AtomicInteger count = new AtomicInteger(0);

public static void main(String[] args) throws Exception {
Runnable task = new Runnable() {
public void run() {
for (int i = 0; i < 1000000; ++i) {
count.incrementAndGet();
}
}
};

Thread t1 = new Thread(task);
Thread t2 = new Thread(task);

t1.start();
t2.start();

t1.join();
t2.join();

System.out.println("count = " + count);
}

}

運行這個程序，我們也可以得到正確的結果兩百萬。在這個版本的代碼中我們主要改了兩處地方，一個是把count變數的類型修改為了AtomicInteger類型，然後把Runnable對象中的累加方式修改為了count.incrementAndGet()。

AtomicInteger提供了原子性的變數值修改方式，原子性保證了整個累加操作可以被看成是一個操作，不會出現更細粒度的操作之間互相穿插導致錯誤結果的情況。在底層AtomicInteger是基於硬體的CAS原語來實現的，CAS是「Compare and Swap」的縮寫，意思是在修改一個變數時會同時指定新值和舊值，只有在舊值等於變數的當前值時，才會把變數的值修改為新值。這個CAS操作在硬體層面是可以保證原子性的。

我們既可以用Atomic類來實現一些簡單的並發修改功能，也可以使用它來對一些關鍵的控制變數進行控制，起到控制並發過程的目的。線程池類ThreadPoolExecutor中用於控制線程池狀態和線程數的控制變數ctl就是一個AtomicInteger類型的欄位。

內存可見性問題

看完了如何解決數據競爭問題，我們再來看一個略顯神奇的例子。

public class MemoryVisibilityDemo {

private static boolean flag;

public static void main(String[] args) throws Exception {

for (int i = 0; i < 10000; ++i) {
flag = false;
final int no = i;

Thread t1 = new Thread(new Runnable() {
@Override
public void run() {
flag = true;
System.out.println(String.format("No.%d loop, t1 is done.", no));
}
});

Thread t2 = new Thread(new Runnable() {
@Override
public void run() {
while (!flag) ;

System.out.println(String.format("No.%d loop, t2 is done.", no));
}
});

t2.start();
t1.start();

t1.join();
t2.join();
}
}

}

這段程序在我的電腦上輸出是這樣的：

No.0 loop, t2 is done.
No.0 loop, t1 is done.
No.1 loop, t1 is done.
No.1 loop, t2 is done.
No.2 loop, t2 is done.
No.2 loop, t1 is done.
No.3 loop, t2 is done.
No.3 loop, t1 is done.
No.4 loop, t1 is done.

在上面的程序輸出中我們可以看到，代碼中的循環是10000次，但是在程序輸出結果中到第五次就結束了。而且第五次運行中只有t1執行完了，t2的結束語句一直沒輸出。這說明程序被卡在了while (!flag) ;上，但是t1明明已經運行結束了，說明此時flag = true已經執行了，為什麼t2還會被卡住呢？

這是因為內存可見性在作祟，在計算機中，我們的存儲會分為很多不同的層次，大家比較常見的就是內存和外存，外存就是比如磁碟、SSD這樣的持久性存儲。其實在內存之上還有多個層次，較完整的計算機存儲體系從下到上依次有外存、內存、「L3、L2、L1三層高速緩存」、寄存器這幾層。在這個存儲體系中從下到上是一個速度從慢到快的結構，越上層速度越快，所以當CPU操作內存數據時會盡量把數據讀取到內存之上的高速緩存中再進行讀寫。

所以如果程序想要修改一個變數的值，那麼系統會先把新值寫到L1緩存中，之後在合適的時間才會將緩存中的數據寫回內存當中。雖然這樣的設置使系統的總體效率得到了提升，但是也帶來了一個問題，那就是L1、L2兩級高速緩存是核內緩存，也就是說多核處理器的每一個核心都有自己獨立的L1、L2高速緩存。那麼如果我們在一個核中運行的線程上修改了變數的值而沒有寫回內存的話，其他核心上運行的線程就看不到這個變數的最新值了。

結合我們前面的程序例子，因為修改和讀取靜態變數flag的代碼在兩個不同的線程中，所以在多核處理器上運行這段程序時，就有可能在兩個不同的處理器核心上運行這兩段代碼。最終就會導致線程t1雖然已經把flag變數的值修改為true了，但是因為這個值還沒有寫回內存，所以線程t2看到的flag變數的值仍然是false，這就是之前的代碼會被卡住的罪魁禍首。

那麼我們如何解決這個問題呢？

volatile變數

最簡單的方式是使用volatile變數，即把flag變數標記為volatile，如下所示：

private static volatile boolean flag;

這下程序就可以穩定地跑完了，那麼volatile做了什麼解決了內存可見性問題呢？根據編號為JSR-133的Java語言規範所定義的Java內存模型(JMM)，volatile變數保證了對該變數的寫入操作和在其之後的讀取操作之間存在同步關係，這個同步關係保證了對volatile變數的讀取一定可以獲取到該變數的最新值。在底層，對volatile變數的寫入會觸發高速緩存強制寫回內存，該操作會使其他處理器核心中的同一個數據塊無效化，必須從內存中重新讀取。Java內存模型的具體內容在下一節中會有簡單的介紹。

從上面的內存可見性問題我們可以發現，多線程程序中會出現的一些問題涉及一些非常底層的知識，而且不瞭解的人是很難事先預防和事後排查的。所以對於希望真正掌握多線程編程的朋友來說，這必然會是一場非常奇妙與漫長的旅程，希望大家都能堅持到最後。

Java內存模型

Java語言規範中的JSR-133定義了一系列決定不同線程之間指令的邏輯順序，從而保證了不會出現內存可見性和指令重排序所引發的並發問題，這對完全掌握多線程程序的正確性至關重要。

在程序中，我們一般會認定程序語句是按代碼中的順序執行的，比如下面這段代碼：

a = 0;
a = 1;
b = 2;
c = 3;

我們當然會認為程序的執行順序是a = 0; -> a = 1; -> b = 2; -> c = 3;，但實際上會有兩種情況可能會破壞語句的執行順序，一是編譯器對指令的重排序可能會導致語句的順序發生改變，二是前面提到的內存可見性。

對於編譯器的指令重排序來說，雖然編譯器會保證單個線程內語句的執行效果與順序執行相同，但是在上面的代碼中三個語句之間是沒有依賴關係的，任意順序執行的效果都是相同的，所以編譯器是有可能對其中的語句進行重排序的。在單線程程序中這當然沒有問題，任意順序執行上面代碼中的語句都是一樣的，但是在多線程情況下，問題就複雜了。如果另外一個線程在變數b的值變為2後會列印變數a的值，那麼按我們的期望這段程序應該列印出的1。但是如果b = 2;語句被重排序到了a = 1;之前和a = 0;之後，那麼我們列印出的值就是0了。

對於內存可見性，如果b = 2;對變數b的修改結果先於a = 1;寫回了內存中。那麼在另一個線程中，當看到變數b的值變為2時還不能看到變數a的新值1，這同樣會導致程序列印出不符合我們期望的值。

從上面的介紹我們可以看出，在這個問題中最重要的是語句的執行順序，在默認情況下，我們可以保證單線程內的執行順序所產生的結果一定是符合我們的期望的，但一旦進入多線程情況下，我們就不能做出這樣的保證了。那麼我們如何保證多個線程之間語句的執行順序關係呢？這就要說到我們之前說到的Java內存模型了。

Java內存模型中定義了不同線程中的語句的順序關係，這被稱為Happens-Before關係，以下簡稱HB。這個關係指的是如果「操作A」HB於「操作B」，那麼如果「操作A」確實在「操作B」之前已經發生了，那麼「操作B」一定會像在「操作A」之後發生一樣：看到「操作A」發生後所產生的所有結果，比如變數值的修改。如果「操作A」把變數a的值修改為了2，那麼所有「操作B」都一定能看到變數a的值為2，不論是編譯器對指令的重排序還是不同處理器核心之間的內存可見性都不能破壞這個結果。

正是因為這種指令執行先後關係的核心就是看到之前執行指令在內存中體現的結果，所以這個規範才被稱為Java內存模型。

常用的Happens-Before關係規則：

1. 同一個線程中，「先執行的語句」 HB於 「之後執行的所有語句」；
2. 「對volatile變數的寫操作」 HB於 「對同一個變數的讀操作」；
3. 「對鎖的釋放操作」 HB於 「對同一個鎖的加鎖操作」；
4. 「對Thread對象的start操作」 HB於 「該線程任務中的第一行語句」；
5. 「線程任務中的最後一行語句」 HB於 「對該線程對應的Thread對象的join操作」；
6. 傳遞性規則：如果「操作B」 HB於 「操作A」，「操作C」 HB於 「操作B」，那麼「操作C」 也HB於 「操作A」。

通過第一條規則我們就確定了單線程內的語句的執行順序，而通過規則2到規則4，我們就可以線程間確定具體的語句執行順序了。最後的規則6傳遞性規則是整個規則體系的補充，利用這條規則我們就可以把規則1中的線程內順序和規則2到4的線程間規則進行結合，得到最終的完整順序體繫了。

在下圖中，左邊一列和右邊一列分別是兩條不同的線程中執行的語句及其順序。如果變數c是一個volatile變數，那麼根據規則2，我們可以知道操作c = 3 HB於 操作print c，下圖中用紅線標明瞭這個關係。所以根據JMM的定義，print c將可以看到變數c的值已經被修改為3了，列印結果將是3，如果在print c語句下方繼續執行對變數a和b的列印，那麼結果必然分別是1和2。

但是我們不能保證右側的第一條print b語句一定會列印出2的值，即使它在時間上發生於b = 2之後。因為指令重排序或者內存可見性問題都有可能會使它只能看到變數b在b = 2之前的原值。也就是說HB關係是沒辦法指定兩條線程中在HB關係之前的語句相互之間的順序關係的，在下圖的例子中就是print b並不能保證一定可以列印出值2，也有可能列印出變數b原來的值。

總結

在這篇文章中我們主要介紹瞭如何保證多線程程序的正確性，使運行過程和結果符合我們的預期。通過對多線程程序正確性問題的探索，我們介紹了三種常用的線程同步方式，分別是鎖、CAS與volatile變數。其中，鎖有synchronized關鍵字和ReentrantLock兩種實現方式。

在這個過程中，我們深入到了計算機系統的底層，瞭解了計算機存儲體系結構和volatile對高速緩存與內存的影響。多線程編程是一個非常好的切入口，讓我們可以將以前曾經學過的計算機理論知識與編程實踐結合起來，這種結合對非常多的高級知識領域都是至關重要的。

因為錯誤的程序是沒有價值的，所以對一個程序來說最重要的當然是正確性。但是在實現了正確性的前提下，我們也必須要想辦法提升程序的性能。因為多線程的目標就是通過多個線程的協作來提升程序的性能，如果達不到這個目標的話我們辛辛苦苦寫的多線程代碼就沒有意義了。在下一篇文章中我們將會具體測試多線程程序的性能，通過發現多線程中那些會讓多線程程序運行得比單線程程序更慢的性能陷阱，最終我們將找到解決這些陷阱的性能優化方法。下一篇文章將在下週發布，有興趣的讀者可以關注一下。

推薦閱讀：