Java併發編程（二）： Java併發機制的底層實現原理

Java併發編程（二）： Java併發機制的底層實現原理

本文主要內容出自《Java併發編程的藝術》一書，是對該書內容的歸納和理解，有興趣的朋友請購買正版閱讀全部內容。

Java代碼在編譯後會變成Java字節碼，字節碼被類加載器加載到JVM裏，JVM執行字節碼，最終需要轉化爲彙編指令在CPU上執行，Java中所使用的併發機制依賴於JVM的實現和CPU的指令。本章我們將深入底層一起探索下Java併發機制的底層實現原理。

1. volatile的應用

在多線程併發編程中synchronized和volatile都扮演着重要的角色，volatile是輕量級的synchronized，它在多處理器開發中保證了共享變量的“可見性”。可見性的意思是當一個線程修改一個共享變量時，另外一個線程能讀到這個修改的值。如果volatile變量修飾符使用恰當的話，它比synchronized的使用和執行成本更低，因爲它不會引起線程上下文的切換和調度。本文將深入分析在硬件層面上Intel處理器是如何實現volatile的，通過深入分析幫助我們正確地使用volatile變量。

我們先從瞭解volatile的定義開始。

1.1 volatile的定義與實現原理

Java語言規範第3版中對volatile的定義如下：Java編程語言允許線程訪問共享變量，爲了確保共享變量能被準確和一致地更新，線程應該確保通過排他鎖單獨獲得這個變量。Java語言提供了volatile，在某些情況下比鎖要更加方便。如果一個字段被聲明成volatile，Java線程內存模型確保所有線程看到這個變量的值是一致的。

volatile是如何來保證可見性的呢？讓我們在X86處理器下通過工具獲取JIT編譯器生成的彙編指令來查看對volatile進行寫操作時，CPU會做什麼事情。
Java代碼如下:

instance = new Singleton(); // instance是volatile變量

轉變成彙編代碼，如下:

0x01a3de1d: movb $0×0,0×1104800(%esi);0x01a3de24: lock addl $0×0,(%esp);

有volatile變量修飾的共享變量進行寫操作的時候會多出第二行彙編代碼，通過查IA-32架構軟件開發者手冊可知，Lock前綴的指令在多核處理器下會引發了兩件事情[1]。
1）將當前處理器緩存行的數據寫回到系統內存。
2）這個寫回內存的操作會使在其他CPU裏緩存了該內存地址的數據無效。

爲了提高處理速度，處理器不直接和內存進行通信，而是先將系統內存的數據讀到內部緩存（L1，L2或其他）後再進行操作，但操作完不知道何時會寫到內存。如果對聲明瞭volatile的變量進行寫操作，JVM就會向處理器發送一條Lock前綴的指令，將這個變量所在緩存行的數據寫回到系統內存。但是，就算寫回到內存，如果其他處理器緩存的值還是舊的，再執行計算操作就會有問題。所以，在多處理器下，爲了保證各個處理器的緩存是一致的，就會實現緩存一致性協議，每個處理器通過嗅探在總線上傳播的數據來檢查自己緩存的值是不是過期了，當處理器發現自己緩存行對應的內存地址被修改，就會將當前處理器的緩存行設置成無效狀態，當處理器對這個數據進行修改操作的時候，會重新從系統內存中把數據讀到處理器緩存裏。

下面來具體講解volatile的兩條實現原則。
1）Lock前綴指令會引起處理器緩存回寫到內存。Lock前綴指令導致在執行指令期間，聲言處理器的LOCK#信號。在多處理器環境中，LOCK#信號確保在聲言該信號期間，處理器可以獨佔任何共享內存[2]。但是，在最近的處理器裏，LOCK＃信號一般不鎖總線，而是鎖緩存，畢竟鎖總線開銷的比較大。在8.1.4節有詳細說明鎖定操作對處理器緩存的影響，對於Intel486和Pentium處理器，在鎖操作時，總是在總線上聲言LOCK#信號。但在P6和目前的處理器中，如果訪問的內存區域已經緩存在處理器內部，則不會聲言LOCK#信號。相反，它會鎖定這塊內存區域的緩存並回寫到內存，並使用緩存一致性機制來確保修改的原子性，此操作被稱爲“緩存鎖定”，緩存一致性機制會阻止同時修改由兩個以上處理器緩存的內存區域數據。

2）一個處理器的緩存回寫到內存會導致其他處理器的緩存無效。IA-32處理器和Intel 64處理器使用MESI（修改、獨佔、共享、無效）控制協議去維護內部緩存和其他處理器緩存的一致性。在多核處理器系統中進行操作的時候，IA-32和Intel 64處理器能嗅探其他處理器訪問系統內存和它們的內部緩存。處理器使用嗅探技術保證它的內部緩存、系統內存和其他處理器的緩存的數據在總線上保持一致。例如，在Pentium和P6 family處理器中，如果通過嗅探一個處理器來檢測其他處理器打算寫內存地址，而這個地址當前處於共享狀態，那麼正在嗅探的處理器將使它的緩存行無效，在下次訪問相同內存地址時，強制執行緩存行填充。

1.2 volatile的使用優化

著名的Java併發編程大師Doug lea在JDK 7的併發包裏新增一個隊列集合類LinkedTransferQueue，它在使用volatile變量時，用一種追加字節的方式來優化隊列出隊和入隊的性能。LinkedTransferQueue的代碼如下。

/** 隊列中的頭部節點 */
private transient final PaddedAtomicReference<QNode> head;
/** 隊列中的尾部節點 */
private transient final PaddedAtomicReference<QNode> tail;
    static f?inal class PaddedAtomicReference <T> extends AtomicReference T> {
        // 使用很多4個字節的引用追加到64個字節
        Object p0, p1, p2, p3, p4, p5, p6, p7, p8, p9, pa, pb, pc, pd, pe;
        PaddedAtomicReference(T r) {
            super(r);
        }
    }
public class AtomicReference <V> implements java.io.Serializable {
    private volatile V value;
    // 省略其他代碼
｝

追加字節能優化性能？這種方式看起來很神奇，但如果深入理解處理器架構就能理解其中的奧祕。讓我們先來看看LinkedTransferQueue這個類，它使用一個內部類類型來定義隊列的頭節點（head）和尾節點（tail），而這個內部類PaddedAtomicReference相對於父類AtomicReference只做了一件事情，就是將共享變量追加到64字節。我們可以來計算下，一個對象的引用佔4個字節，它追加了15個變量（共佔60個字節），再加上父類的value變量，一共64個字節。

爲什麼追加64字節能夠提高併發編程的效率呢？因爲對於英特爾酷睿i7、酷睿、Atom和NetBurst，以及Core Solo和Pentium M處理器的L1、L2或L3緩存的高速緩存行是64個字節寬，不支持部分填充緩存行，這意味着，如果隊列的頭節點和尾節點都不足64字節的話，處理器會將它們都讀到同一個高速緩存行中，在多處理器下每個處理器都會緩存同樣的頭、尾節點，當一個處理器試圖修改頭節點時，會將整個緩存行鎖定，那麼在緩存一致性機制的作用下，會導致其他處理器不能訪問自己高速緩存中的尾節點，而隊列的入隊和出隊操作則需要不停修改頭節點和尾節點，所以在多處理器的情況下將會嚴重影響到隊列的入隊和出隊效率。Doug lea使用追加到64字節的方式來填滿高速緩衝區的緩存行，避免頭節點和尾節點加載到同一個緩存行，使頭、尾節點在修改時不會互相鎖定。

那麼是不是在使用volatile變量時都應該追加到64字節呢？不是的。在兩種場景下不應該使用這種方式。

• 緩存行非64字節寬的處理器。如P6系列和奔騰處理器，它們的L1和L2高速緩存行是32個字節寬。
• 共享變量不會被頻繁地寫。因爲使用追加字節的方式需要處理器讀取更多的字節到高速緩衝區，這本身就會帶來一定的性能消耗，如果共享變量不被頻繁寫的話，鎖的機率也非常小，就沒必要通過追加字節的方式來避免相互鎖定。

不過這種追加字節的方式在Java 7下可能不生效，因爲Java 7變得更加智慧，它會淘汰或重新排列無用字段，需要使用其他追加字節的方式。除了volatile，Java併發編程中應用較多的是synchronized，下面一起來看一下。

2. synchronized的實現原理與應用

在多線程併發編程中synchronized一直是元老級角色，很多人都會稱呼它爲重量級鎖。但是，隨着Java SE 1.6對synchronized進行了各種優化之後，有些情況下它就並不那麼重了。本文詳細介紹Java SE 1.6中爲了減少獲得鎖和釋放鎖帶來的性能消耗而引入的偏向鎖和輕量級鎖，以及鎖的存儲結構和升級過程。

先來看下利用synchronized實現同步的基礎：Java中的每一個對象都可以作爲鎖。具體表現爲以下3種形式。

• 對於普通同步方法，鎖是當前實例對象。
• 對於靜態同步方法，鎖是當前類的Class對象。
• 對於同步方法塊，鎖是Synchonized括號裏配置的對象。

當一個線程試圖訪問同步代碼塊時，它首先必須得到鎖，退出或拋出異常時必須釋放鎖。那麼鎖到底存在哪裏呢？鎖裏面會存儲什麼信息呢？

從JVM規範中可以看到Synchonized在JVM裏的實現原理，JVM基於進入和退出Monitor對象來實現方法同步和代碼塊同步，但兩者的實現細節不一樣。代碼塊同步是使用monitorenter和monitorexit指令實現的，而方法同步是使用另外一種方式實現的，細節在JVM規範裏並沒有詳細說明。但是，方法的同步同樣可以使用這兩個指令來實現。

monitorenter指令是在編譯後插入到同步代碼塊的開始位置，而monitorexit是插入到方法結束處和異常處，JVM要保證每個monitorenter必須有對應的monitorexit與之配對。任何對象都有一個monitor與之關聯，當且一個monitor被持有後，它將處於鎖定狀態。線程執行到monitorenter指令時，將會嘗試獲取對象所對應的monitor的所有權，即嘗試獲得對象的鎖。

2.1 鎖的升級與對比

Java SE 1.6爲了減少獲得鎖和釋放鎖帶來的性能消耗，引入了“偏向鎖”和“輕量級鎖”，在Java SE 1.6中，鎖一共有4種狀態，級別從低到高依次是：無鎖狀態、偏向鎖狀態、輕量級鎖狀態和重量級鎖狀態，這幾個狀態會隨着競爭情況逐漸升級。鎖可以升級但不能降級，意味着偏向鎖升級成輕量級鎖後不能降級成偏向鎖。這種鎖升級卻不能降級的策略，目的是爲了提高獲得鎖和釋放鎖的效率，下文會詳細分析。

1. 偏向鎖
HotSpot[1]的作者經過研究發現，大多數情況下，鎖不僅不存在多線程競爭，而且總是由同一線程多次獲得，爲了讓線程獲得鎖的代價更低而引入了偏向鎖。當一個線程訪問同步塊並獲取鎖時，會在對象頭和棧幀中的鎖記錄裏存儲鎖偏向的線程ID，以後該線程在進入和退出同步塊時不需要進行CAS操作來加鎖和解鎖，只需簡單地測試一下對象頭的Mark Word裏是否存儲着指向當前線程的偏向鎖。如果測試成功，表示線程已經獲得了鎖。如果測試失敗，則需要再測試一下Mark Word中偏向鎖的標識是否設置成1（表示當前是偏向鎖）：如果沒有設置，則使用CAS競爭鎖；如果設置了，則嘗試使用CAS將對象頭的偏向鎖指向當前線程。

（1）偏向鎖的撤銷
偏向鎖使用了一種等到競爭出現才釋放鎖的機制，所以當其他線程嘗試競爭偏向鎖時，持有偏向鎖的線程纔會釋放鎖。偏向鎖的撤銷，需要等待全局安全點（在這個時間點上沒有正在執行的字節碼）。它會首先暫停擁有偏向鎖的線程，然後檢查持有偏向鎖的線程是否活着，如果線程不處於活動狀態，則將對象頭設置成無鎖狀態；如果線程仍然活着，擁有偏向鎖的棧會被執行，遍歷偏向對象的鎖記錄，棧中的鎖記錄和對象頭的Mark Word要麼重新偏向於其他線程，要麼恢復到無鎖或者標記對象不適合作爲偏向鎖，最後喚醒暫停的線程。下圖中的線程1演示了偏向鎖初始化的流程，線程2演示了偏向鎖撤銷的流程。

（2）關閉偏向鎖
偏向鎖在Java 6和Java 7裏是默認啓用的，但是它在應用程序啓動幾秒鐘之後才激活，如有必要可以使用JVM參數來關閉延遲：-XX:BiasedLockingStartupDelay=0。如果你確定應用程序裏所有的鎖通常情況下處於競爭狀態，可以通過JVM參數關閉偏向鎖：-XX:-UseBiasedLocking=false，那麼程序默認會進入輕量級鎖狀態。

2.2 輕量級鎖

（1）輕量級鎖加鎖
線程在執行同步塊之前，JVM會先在當前線程的棧楨中創建用於存儲鎖記錄的空間，並將對象頭中的Mark Word複製到鎖記錄中，官方稱爲Displaced Mark Word。然後線程嘗試使用CAS將對象頭中的Mark Word替換爲指向鎖記錄的指針。如果成功，當前線程獲得鎖，如果失敗，表示其他線程競爭鎖，當前線程便嘗試使用自旋來獲取鎖。

（2）輕量級鎖解鎖
輕量級解鎖時，會使用原子的CAS操作將Displaced Mark Word替換回到對象頭，如果成功，則表示沒有競爭發生。如果失敗，表示當前鎖存在競爭，鎖就會膨脹成重量級鎖。下圖是兩個線程同時爭奪鎖，導致鎖膨脹的流程圖。

因爲自旋會消耗CPU，爲了避免無用的自旋（比如獲得鎖的線程被阻塞住了），一旦鎖升級成重量級鎖，就不會再恢復到輕量級鎖狀態。當鎖處於這個狀態下，其他線程試圖獲取鎖時，都會被阻塞住，當持有鎖的線程釋放鎖之後會喚醒這些線程，被喚醒的線程就會進行新一輪的奪鎖之爭。

2.3 鎖的優缺點對比

鎖	優點	缺點	適用場景
偏向鎖	加鎖和解鎖不需要額外的消耗,和執行非同步方法相比僅存在納秒級的差距	如果線程間存在鎖競爭,會帶來額外的鎖撤銷的消耗	適用於只有一個線程訪問同步塊場景
輕量級鎖	競爭的線程不會阻塞,提高了程序的響應速度	如果始終得不到鎖競爭的線程,使用自旋會消耗CPU	追求響應時間,同步塊執行速度非常快
重量級鎖	線程競爭不使用自旋,不會消耗CPU	線程阻塞,響應時間緩慢	追求吞吐量,同步塊執行速度較長

3. 原子操作的實現原理

原子（atomic）本意是“不能被進一步分割的最小粒子”，而原子操作（atomic operation）意爲“不可被中斷的一個或一系列操作”。在多處理器上實現原子操作就變得有點複雜。讓我們一起來聊一聊在Intel處理器和Java裏是如何實現原子操作的。

3.1 處理器如何實現原子操作

32位IA-32處理器使用基於對緩存加鎖或總線加鎖的方式來實現多處理器之間的原子操作。首先處理器會自動保證基本的內存操作的原子性。處理器保證從系統內存中讀取或者寫入一個字節是原子的，意思是當一個處理器讀取一個字節時，其他處理器不能訪問這個字節的內存地址。Pentium 6和最新的處理器能自動保證單處理器對同一個緩存行裏進行16/32/64位的操作是原子的，但是複雜的內存操作處理器是不能自動保證其原子性的，比如跨總線寬度、跨多個緩存行和跨頁表的訪問。但是，處理器提供總線鎖定和緩存鎖定兩個機制來保證複雜內存操作的原子性。

（1）使用總線鎖保證原子性
第一個機制是通過總線鎖保證原子性。如果多個處理器同時對共享變量進行讀改寫操作（i++就是經典的讀改寫操作），那麼共享變量就會被多個處理器同時進行操作，這樣讀改寫操作就不是原子的，操作完之後共享變量的值會和期望的不一致。舉個例子，如果i=1，我們進行兩次i++操作，我們期望的結果是3，但是有可能結果是2，如下圖所示。

原因可能是多個處理器同時從各自的緩存中讀取變量i，分別進行加1操作，然後分別寫入系統內存中。那麼，想要保證讀改寫共享變量的操作是原子的，就必須保證CPU1讀改寫共享變量的時候，CPU2不能操作緩存了該共享變量內存地址的緩存。

處理器使用總線鎖就是來解決這個問題的。所謂總線鎖就是使用處理器提供的一個
LOCK＃信號，當一個處理器在總線上輸出此信號時，其他處理器的請求將被阻塞住，那麼該處理器可以獨佔共享內存。

（2）使用緩存鎖保證原子性
第二個機制是通過緩存鎖定來保證原子性。在同一時刻，我們只需保證對某個內存地址的操作是原子性即可，但總線鎖定把CPU和內存之間的通信鎖住了，這使得鎖定期間，其他處理器不能操作其他內存地址的數據，所以總線鎖定的開銷比較大，目前處理器在某些場合下使用緩存鎖定代替總線鎖定來進行優化。

頻繁使用的內存會緩存在處理器的L1、L2和L3高速緩存裏，那麼原子操作就可以直接在處理器內部緩存中進行，並不需要聲明總線鎖，在Pentium 6和目前的處理器中可以使用“緩存鎖定”的方式來實現複雜的原子性。所謂“緩存鎖定”是指內存區域如果被緩存在處理器的緩存行中，並且在Lock操作期間被鎖定，那麼當它執行鎖操作回寫到內存時，處理器不在總線上聲言LOCK＃信號，而是修改內部的內存地址，並允許它的緩存一致性機制來保證操作的原子性，因爲緩存一致性機制會阻止同時修改由兩個以上處理器緩存的內存區域數據，當其他處理器回寫已被鎖定的緩存行的數據時，會使緩存行無效，在如圖2-3所示的例子中，當CPU1修改緩存行中的i時使用了緩存鎖定，那麼CPU2就不能同時緩存i的緩存行。

但是有兩種情況下處理器不會使用緩存鎖定。
第一種情況是：當操作的數據不能被緩存在處理器內部，或操作的數據跨多個緩存行（cache line）時，則處理器會調用總線鎖定。

第二種情況是：有些處理器不支持緩存鎖定。對於Intel 486和Pentium處理器，就算鎖定的內存區域在處理器的緩存行中也會調用總線鎖定。

針對以上兩個機制，我們通過Intel處理器提供了很多Lock前綴的指令來實現。例如，位測試和修改指令：BTS、BTR、BTC；交換指令XADD、CMPXCHG，以及其他一些操作數和邏輯指令（如ADD、OR）等，被這些指令操作的內存區域就會加鎖，導致其他處理器不能同時訪問它。

3.2 Java如何實現原子操作

在Java中可以通過鎖和循環CAS的方式來實現原子操作。

（1）使用循環CAS實現原子操作

JVM中的CAS操作正是利用了處理器提供的CMPXCHG指令實現的。自旋CAS實現的基本
思路就是循環進行CAS操作直到成功爲止，以下代碼實現了一個基於CAS線程安全的計數器方法safeCount和一個非線程安全的計數器count。

public class Counter {

    private AtomicInteger atomicI = new AtomicInteger(0);
    private int           i       = 0;

    public static void main(String[] args) {
        final Counter cas = new Counter();
        List<Thread> ts = new ArrayList<Thread>(600);
        long start = System.currentTimeMillis();
        for (int j = 0; j < 100; j++) {
            Thread t = new Thread(new Runnable() {
                @Override
                public void run() {
                    for (int i = 0; i < 10000; i++) {
                        cas.count();
                        cas.safeCount();
                    }
                }
            });
            ts.add(t);
        }
        for (Thread t : ts) {
            t.start();

        }
        // 等待所有線程執行完成
        for (Thread t : ts) {
            try {
                t.join();
            } catch (InterruptedException e) {
                e.printStackTrace();
            }

        }
        System.out.println(cas.i);
        System.out.println(cas.atomicI.get());
        System.out.println(System.currentTimeMillis() - start);
    }

    /**
     * 使用CAS實現線程安全計數器
     */
    private void safeCount() {
        for (;;) {
            int i = atomicI.get();
            boolean suc = atomicI.compareAndSet(i, ++i);
            if (suc) {
                break;
            }
        }
    }

    /**
     * 非線程安全計數器
     */
    private void count() {
        i++;
    }
}

從Java 1.5開始，JDK的併發包裏提供了一些類來支持原子操作，如AtomicBoolean（用原子
方式更新的boolean值）、AtomicInteger（用原子方式更新的int值）和AtomicLong（用原子方式更新的long值）。這些原子包裝類還提供了有用的工具方法，比如以原子的方式將當前值自增1和自減1。

（2）CAS實現原子操作的三大問題

在Java併發包中有一些併發框架也使用了自旋CAS的方式來實現原子操作，比如
LinkedTransferQueue類的Xfer方法。CAS雖然很高效地解決了原子操作，但是CAS仍然存在三大問題。ABA問題，循環時間長開銷大，以及只能保證一個共享變量的原子操作。

    1）ABA問題。因爲CAS需要在操作值的時候，檢查值有沒有發生變化，如果沒有發生變化則更新，但是如果一個值原來是A，變成了B，又變成了A，那麼使用CAS進行檢查時會發現它的值沒有發生變化，但是實際上卻變化了。ABA問題的解決思路就是使用版本號。在變量前面追加上版本號，每次變量更新的時候把版本號加1，那麼A→B→A就會變成1A→2B→3A。從Java 1.5開始，JDK的Atomic包裏提供了一個類AtomicStampedReference來解決ABA問題。這個類的compareAndSet方法的作用是首先檢查當前引用是否等於預期引用，並且檢查當前標誌是否等於預期標誌，如果全部相等，則以原子方式將該引用和該標誌的值設置爲給定的更新值。

public boolean compareAndSet(
    V expectedReference,        // 預期引用
    V newReference,             // 更新後的引用
    int expectedStamp,          // 預期標誌
    int newStamp                // 更新後的標誌
)

    2）循環時間長開銷大。自旋CAS如果長時間不成功，會給CPU帶來非常大的執行開銷。如果JVM能支持處理器提供的pause指令，那麼效率會有一定的提升。pause指令有兩個作用：第一，它可以延遲流水線執行指令（de-pipeline），使CPU不會消耗過多的執行資源，延遲的時間取決於具體實現的版本，在一些處理器上延遲時間是零；第二，它可以避免在退出循環的時候因內存順序衝突（Memory Order Violation）而引起CPU流水線被清空（CPU Pipeline Flush），從而提高CPU的執行效率。

    3）只能保證一個共享變量的原子操作。當對一個共享變量執行操作時，我們可以使用循環CAS的方式來保證原子操作，但是對多個共享變量操作時，循環CAS就無法保證操作的原子性，這個時候就可以用鎖。還有一個取巧的辦法，就是把多個共享變量合併成一個共享變量來操作。比如，有兩個共享變量i＝2，j=a，合併一下ij=2a，然後用CAS來操作ij。從Java 1.5開始，JDK提供了AtomicReference類來保證引用對象之間的原子性，就可以把多個變量放在一個對象裏來進行CAS操作。

（3）使用鎖機制實現原子操作
鎖機制保證了只有獲得鎖的線程才能夠操作鎖定的內存區域。JVM內部實現了很多種鎖機制，有偏向鎖、輕量級鎖和互斥鎖。有意思的是除了偏向鎖，JVM實現鎖的方式都用了循環CAS，即當一個線程想進入同步塊的時候使用循環CAS的方式來獲取鎖，當它退出同步塊的時候使用循環CAS釋放鎖。

4. 小結

本文我們一起研究了volatile、synchronized和原子操作的實現原理。Java中的大部分容器和框架都依賴於本章介紹的volatile和原子操作的實現原理，瞭解這些原理對我們進行併發編程會更有幫助。