一、匯流排鎖定和快取一致性

基本概念

這是兩個作業系統層面的概念。隨著多核時代的到來，併發操作已經成了很正常的現象，作業系統必須要有一些機制和原語，以保證某些基本操作的原子性，比如處理器需要保證讀一個位元組或寫一個位元組是原子的，那麼它是如何實現的呢?有兩種機制：匯流排鎖定和快取一致性。

我們知道，CPU和實體記憶體之間的通訊速度遠慢於CPU的處理速度，所以CPU有自己的內部快取，根據一些規則將記憶體中的資料讀取到內部快取中來，以加快頻繁讀取的速度。我們假設在一臺PC上只有一個CPU和一份內部快取，那麼所有程序和執行緒看到的數都是快取裡的數，不會存在問題;但現在伺服器通常是多 CPU，更普遍的是，每塊CPU裡有多個核心，而每個核心都維護了自己的快取，那麼這時候多執行緒併發就會存在快取不一致性，這會導致嚴重問題。

以 i++為例，i的初始值是0.那麼在開始每塊快取都儲存了i的值0，當第一塊核心做i++的時候，其快取中的值變成了1，即使馬上回寫到主記憶體，那麼在回寫之後第二塊核心快取中的i值依然是0，其執行i++，回寫到記憶體就會覆蓋第一塊核心的操作，使得最終的結果是1，而不是預期中的2.

那麼怎麼解決整個問題呢?作業系統提供了匯流排鎖定的機制。前端匯流排(也叫CPU匯流排)是所有CPU與晶片組連線的主幹道，負責CPU與外界所有部件的通訊，包括快取記憶體、記憶體、北橋，其控制匯流排向各個部件傳送控制訊號、通過地址匯流排傳送地址訊號指定其要訪問的部件、通過資料匯流排雙向傳輸。在CPU1要做 i++操作的時候，其在總線上發出一個LOCK#訊號，其他處理器就不能操作快取了該共享變數記憶體地址的快取，也就是阻塞了其他CPU，使該處理器可以獨享此共享記憶體。

但我們只需要對此共享變數的操作是原子就可以了，而匯流排鎖定把CPU和記憶體的通訊給鎖住了，使得在鎖定期間，其他處理器不能操作其他記憶體地址的資料，從而開銷較大，所以後來的CPU都提供了快取一致性機制，Intel的奔騰486之後就提供了這種優化。

快取一致性機制整體來說，是當某塊CPU對快取中的資料進行操作了之後，就通知其他CPU放棄儲存在它們內部的快取，或者從主記憶體中重新讀取，如下圖：

這裡以在Intel系列中廣泛使用的MESI協議詳細闡述下其原理。

MESI協議

MESI 協議是以快取行(快取的基本資料單位，在Intel的CPU上一般是64位元組)的幾個狀態來命名的(全名是Modified、Exclusive、 Share or Invalid)。該協議要求在每個快取行上維護兩個狀態位，使得每個資料單位可能處於M、E、S和I這四種狀態之一，各種狀態含義如下：

M：被修改的。處於這一狀態的資料，只在本CPU中有快取資料，而其他CPU中沒有。同時其狀態相對於記憶體中的值來說，是已經被修改的，且沒有更新到記憶體中。

E：獨佔的。處於這一狀態的資料，只有在本CPU中有快取，且其資料沒有修改，即與記憶體中一致。

S：共享的。處於這一狀態的資料在多個CPU中都有快取，且與記憶體一致。

I：無效的。本CPU中的這份快取已經無效。

這裡首先介紹該協議約定的快取上對應的監聽：

一個處於M狀態的快取行，必須時刻監聽所有試圖讀取該快取行對應的主存地址的操作，如果監聽到，則必須在此操作執行前把其快取行中的資料寫回CPU。

一個處於S狀態的快取行，必須時刻監聽使該快取行無效或者獨享該快取行的請求，如果監聽到，則必須把其快取行狀態設定為I。

一個處於E狀態的快取行，必須時刻監聽其他試圖讀取該快取行對應的主存地址的操作，如果監聽到，則必須把其快取行狀態設定為S。

當CPU需要讀取資料時，如果其快取行的狀態是I的，則需要從記憶體中讀取，並把自己狀態變成S，如果不是I，則可以直接讀取快取中的值，但在此之前，必須要等待其他CPU的監聽結果，如其他CPU也有該資料的快取且狀態是M，則需要等待其把快取更新到記憶體之後，再讀取。

當CPU需要寫資料時，只有在其快取行是M或者E的時候才能執行，否則需要發出特殊的RFO指令(Read Or Ownership，這是一種匯流排事務)，通知其他CPU置快取無效(I)，這種情況下會效能開銷是相對較大的。在寫入完成後，修改其快取狀態為M。

所以如果一個變數在某段時間只被一個執行緒頻繁地修改，則使用其內部快取就完全可以辦到，不涉及到匯流排事務，如果快取一會被這個CPU獨佔、一會被那個CPU 獨佔，這時才會不斷產生RFO指令影響到併發效能。這裡說的快取頻繁被獨佔並不是指執行緒越多越容易觸發，而是這裡的CPU協調機制，這有點類似於有時多執行緒並不一定提高效率，原因是執行緒掛起、排程的開銷比執行任務的開銷還要大，這裡的多CPU也是一樣，如果在CPU間排程不合理，也會形成RFO指令的開銷比任務開銷還要大。當然，這不是程式設計者需要考慮的事，作業系統會有相應的記憶體地址的相關判斷，這不在本文的討論範圍之內。

並非所有情況都會使用快取一致性的，如被操作的資料不能被快取在CPU內部或操作資料跨越多個快取行(狀態無法標識)，則處理器會呼叫匯流排鎖定;另外當CPU不支援快取鎖定時，自然也只能用匯流排鎖定了，比如說奔騰486以及更老的CPU。

二、CAS(Compare and Swap)

有了上一章的匯流排鎖定和快取一致性的介紹，對CAS就比較好理解了，這不是java特有的，而是作業系統需要保證的。CAS指令在Intel CPU上稱為CMPXCHG指令，它的作用是將指定記憶體地址的內容與所給的某個值相比，如果相等，則將其內容替換為指令中提供的新值，如果不相等，則更新失敗。這一比較並交換的操作是原子的，不可以被中斷，而其保證原子性的原理就是上一節提到的“匯流排鎖定和快取一致性”。初一看，CAS也包含了讀取、比較 (這也是種操作)和寫入這三個操作，和之前的i++並沒有太大區別，是的，的確在操作上沒有區別，但CAS是通過硬體命令保證了原子性，而i++沒有，且硬體級別的原子性比i++這樣高階語言的軟體級別的執行速度要快地多。雖然CAS也包含了多個操作，但其的運算是固定的(就是個比較)，這樣的鎖定效能開銷很小。

隨著網際網路行業的興起和硬體多CPU/多核心的進步，高併發已經成為越來越普遍的現象，CAS已經被越來越廣泛地使用，在Java領域也是如此。JDK1.4是2002年2月釋出的，當時的硬體裝置遠沒有如今這麼先進，多CPU和多核還沒有普及，所以在JDK1.5之前的synchronized是使用掛起執行緒、等待排程的方式來實現執行緒同步，開銷較大;而隨著硬體的不斷升級，在2004年9月釋出的JDK5中引入了CAS機制——比較並交換——來徹底解決此問題，在一般情況下不再需要掛起(參考後文對鎖級別的描述，只有進入重量級鎖的時候才會使用掛起)，而是多次嘗試，其利用底層CPU命令實現的樂觀鎖機制。從記憶體領域來說這是樂觀鎖，因為它在對共享變數更新之前會先比較當前值是否與更新前的值一致，如果是，則更新，如果不是，則無限迴圈執行(稱為自旋)，直到當前值與更新前的值一致為止，才執行更新。

以concurrent中的AtomicInteger的程式碼為例，其的getAndIncrement()方法(獲得並且自增，即i++)原始碼如下：

/**
      * Atomically increments by one the current value.
      *
      * @return the previous value
      */
     public final int getAndIncrement() {
         for (;;) {
             int current = get();
             int next = current + 1 ;
             if (compareAndSet(current, next))
                 return current;
         }
     }

     /**
      * Atomically sets the value to the given updated value
      * if the current value {@code ==} the expected value.
      *
      * @param expect the expected value
      * @param update the new value
      * @return true if successful. False return indicates that
      * the actual value was not equal to the expected value.
      */
     public final boolean compareAndSet( int expect, int update) {
         return unsafe.compareAndSwapInt( this , valueOffset, expect, update);
     }

其呼叫了compareAndSet(int expect,int update)方法，其中expect是期望值，即操作前的原始值，而update是操作後的值，以i=2為例，則這裡的 expect=2，update=3，它呼叫了sun.misc.Unsafe的compareAndSwapInt方法來執行，此方法程式碼如下：

 /***
    * Compares the value of the integer field at the specified offset
    * in the supplied object with the given expected value, and updates
    * it if they match.  The operation of this method should be atomic,
    * thus providing an uninterruptible way of updating an integer field.
    *
    * @param obj the object containing the field to modify.
    * @param offset the offset of the integer field within <code>obj</code>.
    * @param expect the expected value of the field.
    * @param update the new value of the field if it equals <code>expect</code>.
    * @return true if the field was changed.
    */
   public native boolean compareAndSwapInt(Object obj, long offset,
                                           int expect, int update);

這是一個本地方法，即利用CAS保證其原子性，同時如果失敗了則通過迴圈不斷地進行運算直到成功為止，這是和JDK5以前最大的區別，失敗的執行緒不再需要被掛起、重新排程，而是可以無障礙地再度執行，這又極大減少了掛起排程的開銷(當然如果CAS長時間不成功，也會造成耗費CPU，這取決於具體應用場景)。

CAS策略有如下需要注意的事項：

線上程搶佔資源特別頻繁的時候(相對於CPU執行效率而言)，會造成長時間的自旋，耗費CPU效能。

有ABA問題(即在更新前的值是A，但在操作過程中被其他執行緒更新為B，又更新為 A)，這時當前執行緒認為是可以執行的，其實是發生了不一致現象，如果這種不一致對程式有影響(真正有這種影響的場景很少，除非是在變數操作過程中以此變數為標識位做一些其他的事，比如初始化配置)，則需要使用AtomicStampedReference(除了對更新前的原值進行比較，也需要用更新前的 stamp標誌位來進行比較)。

只能對一個變數進行原子性操作。如果需要把多個變數作為一個整體來做原子性操作，則應該使用AtomicReference來把這些變數放在一個物件裡，針對這個物件做原子性操作。

CAS在JDK5中被J.U.C包廣泛使用，在JDK6中被應用到synchronized的 JVM實現中，因此在JDK5中J.U.C的效率是比synchronized高不少的，而到了JDK6，兩者效率相差無幾，而synchronized 使用更簡單、更不容易出錯，所以其是專家組推薦的首選，除非需要用到J.U.C的特殊功能(如阻塞一段時間後放棄，而不是繼續等待)。