一、總線鎖定和緩存一致性
這是兩個操作系統層面的概念。隨着多核時代的到來，併發操作已經成了很正常的現象，操作系統必須要有一些機制和原語，以保證某些基本操作的原子性，比如處理器需要保證讀一個字節或寫一個字節是原子的，那麼它是如何實現的呢?有兩種機制：總線鎖定和緩存一致性。
我們知道，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。
二、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的特殊功能(如阻塞一段時間後放棄，而不是繼續等待)。
