摘要：多線程編程就像一個沼澤，中間遍布各種各樣的陷阱。但是在多線程編程或者說是并發(fā)編程中，有非常多的陷阱被埋在底層細節(jié)當中。線程池類中用于控制線程池狀態(tài)和線程數(shù)的控制變量就是一個類型的字段。

多線程編程就像一個沼澤，中間遍布各種各樣的陷阱。大多數(shù)開發(fā)者絕大部分時間都是在做上層應用的開發(fā)，并不需要過多地涉入底層細節(jié)。但是在多線程編程或者說是并發(fā)編程中，有非常多的陷阱被埋在底層細節(jié)當中。如果不知道這些底層知識，可能在編寫過程中完全意識不到程序已經出現(xiàn)了漏洞，甚至在漏洞爆發(fā)之后也很難排查出具體原因進而解決漏洞。雖然前面提到的漏洞聽起來很嚇人，但是相信通過我們逐步的抽絲剝繭，在最后一定能掌握大量的實用工具來幫助我們解決這些問題，實現(xiàn)可靠的并發(fā)程序。

閱讀本文需要了解并發(fā)的基本概念和Java多線程編程基礎知識，還不了解的讀者可以參考一下下面兩篇文章：

并發(fā)的基本概念——當我們在說“并發(fā)、多線程”，說的是什么？

Java多線程編程基礎——這一次，讓我們完全掌握Java多線程

為了了解多線程程序有什么隱藏的陷阱，我們先來看一段代碼：

public class AccumulateWrong {

    private static int count = 0;

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

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

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

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

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

這段代碼實現(xiàn)的基本功能就是在兩個線程中分別對一個整型累加一百萬次，那么我們期望的輸出應該總共是兩百萬。但在我的電腦上運行的結果只有1799369，而且每次都不一樣，相信在你的電腦上也會運行得到一個不同的結果，但是肯定會達不到兩百萬。

這段代碼出現(xiàn)問題的原因就在于，我們在執(zhí)行count += 1;這行代碼時，實際在CPU上運行的會是多條指令：

獲取count變量的當前值

計算count + 1的值

將count + 1的結果值存到count變量中

所以就有可能會發(fā)生下面的執(zhí)行順序：

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

那么我們如何解決這樣的數(shù)據競爭問題呢？

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

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

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

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

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

以塊結構形式使用synchronized關鍵字，則獲取的就是synchronized關鍵字后小括號中的對象所對應的鎖；

synchronized被標記在實例方法上，則獲取的就是this引用指向對象所對應的鎖；

synchronized被標記在類方法（靜態(tài)方法）上時，獲取的就是方法所在類的“類對象”所對應的鎖，這里的類對象就可以理解為是每個類一個用于存放靜態(tài)字段和靜態(tài)方法的對象。

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

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

ReentrantLock發(fā)揮的作用與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確實能起到保障互斥訪問臨界區(qū)的作用。但是既然ReentrantLock和synchronized的作用相同，而且從代碼來看使用synchronized還更方便，為什么還要專門定義一個ReentrantLock這樣的類呢？

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

ReentrantLock可以實現(xiàn)帶有超時時間的鎖等待，我們可以通過tryLock方法進行加鎖，并傳入超時時間參數(shù)。如果超過了超時時間還么有獲得鎖的話，那么就tryLock方法就會返回false；

ReentrantLock可以使用公平性機制，讓先申請鎖的線程先獲得鎖，防止線程一直等待鎖但是獲取不到；

ReentrantLock可以實現(xiàn)讀寫鎖等更豐富的類型。

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

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提供了原子性的變量值修改方式，原子性保證了整個累加操作可以被看成是一個操作，不會出現(xiàn)更細粒度的操作之間互相穿插導致錯誤結果的情況。在底層AtomicInteger是基于硬件的CAS原語來實現(xiàn)的，CAS是“Compare and Swap”的縮寫，意思是在修改一個變量時會同時指定新值和舊值，只有在舊值等于變量的當前值時，才會把變量的值修改為新值。這個CAS操作在硬件層面是可以保證原子性的。

我們既可以用Atomic類來實現(xiàn)一些簡單的并發(fā)修改功能，也可以使用它來對一些關鍵的控制變量進行控制，起到控制并發(fā)過程的目的。線程池類ThreadPoolExecutor中用于控制線程池狀態(tài)和線程數(shù)的控制變量ctl就是一個AtomicInteger類型的字段。

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

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.

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

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

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

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

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

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

private static volatile boolean flag;

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

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

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

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

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

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

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

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

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

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

正是因為這種指令執(zhí)行先后關系的核心就是看到之前執(zhí)行指令在內存中體現(xiàn)的結果，所以這個規(guī)范才被稱為Java內存模型。

常用的Happens-Before關系規(guī)則：

同一個線程中，“先執(zhí)行的語句” HB于 “之后執(zhí)行的所有語句”；

“對volatile變量的寫操作” HB于 “對同一個變量的讀操作”；

“對鎖的釋放操作” HB于 “對同一個鎖的加鎖操作”；

“對Thread對象的start操作” HB于 “該線程任務中的第一行語句”；

“線程任務中的最后一行語句” HB于 “對該線程對應的Thread對象的join操作”；

傳遞性規(guī)則：如果“操作B” HB于 “操作A”，“操作C” HB于 “操作B”，那么“操作C” 也HB于 “操作A”。

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

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

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

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

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

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