Java的多線程機制:緩存一致性和CAS

Java的多線程機制:緩存一致性和CAS

1、總線鎖定和緩存一致性

這是兩個操做系統層面的概念。隨着多核時代的到來，併發操做已經成了很正常的現象，操做系統必需要有一些機制和原語，以保證某些基本操做的原子性，好比處理器須要保證讀一個字節或寫一個字節是原子的，那麼它是如何實現的呢?有兩種機制：總線鎖定和緩存一致性。

咱們知道，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 協議是以緩存行(緩存的基本數據單位，在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。

2、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++)源代碼以下：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26

/**       * 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方法來執行，此方法代碼以下：

1 2 3 4 5 6 7 8 9 10 11 12 13 14

/***     * 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的特殊功能(如阻塞一段時間後放棄，而不是繼續等待)。