一、總線鎖定和緩存一致性
這是兩個操作系統層面的概念。隨着多核時代的到來，並發操作已經成了很正常的現象，操作系統必須要有一些機制和原語，以保證某些基本操作的原子性。首先處理器需要保證讀一個字節或寫一個字節是無條件原子的，不存在讀/寫了一半被中斷的情況(那樣就會產生亂七八糟的值)，但這還不夠，在並發環境下，為了滿足多線程的一致性，還必須提供更大范圍原子性的操作，比如Compare And Swap操作(見后面CAS章節)。操作系統有兩種保證操作原子性的機制：總線鎖定和緩存一致性。
我們知道，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++)源代碼如下：
/** * 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); }
/*** * 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的特殊功能(如阻塞一段時間后放棄，而不是繼續等待)。
三、內存屏障
我們知道一個線程是由一個CPU核來處理的，但現代CPU為了繼續挖掘並行運算能力，出現了流水線技術，即每個內核有多個電路，調度器將串行指令分解為多步，並將不同指令的各步操作結果疊加，從而實現並行處理，指令的每步都由各自獨立的電路來處理，最后匯總處理。這在相當程度上提高了並發能力。那么指令該如何分解？指令的前后執行順序是否有關系？如何保證結果正確？這又是一個復雜的課題：重排序。
作為CPU來說，為了提高執行效率，允許將一段程序代碼分發到各個流水線去執行，但我們的程度代碼可能是有前后邏輯關系的，比如int a=10;int b=a*2;這里如果將第二行移到第一行前面執行，則產生了錯誤結果，這里的計算b的代碼我們稱之為與前面的a存在數據依賴。下面是不同處理器對不同重排序類型的支持程度
從上面可以看到，各種處理器均不對“數據依賴”類型的語句進行重排序。那這里的一堆Load-Load、Load-Store是什么意思呢？
Load指的是從內存中讀取數據的操作，即if(a<1)這樣的語句(只讀不寫)；Store指的是向內存中寫入數據的操作，即a=10這樣的語句(只寫不讀)。Load-Load指先讀后讀的操作是否允許重排序；Load-Store指先讀后寫是否允許重排序；Store-Store指先寫后寫的兩個語句是否允許重排序；Store-Load指先寫后讀的兩個語句是否允許重排序。
從上表可以看到，對於我們常用的Intel和AMD所使用的x86架構，只支持Store-Load重排序，這是因為CPU在寫入的時候是首先寫入寄存器，包括各級緩存，此時並沒有刷新到內存中，如果等待其完成再讀則太慢了，所以允許重排序。只要理解了寫入是通過緩存批量執行的，那就不難理解。
說了這么多，還是沒有提到內存屏障，它究竟是什么？仍然以ia64為例，它是允許Store-Store重排序的，但未必能保證在多線程環境下准確，比如這樣的程序
1: static class ThreadA extends Thread{
2: public void run(){
3: a=1;
4: flag=true;
5: }
6: }
7:
8: static class ThreadB extends Thread{
9: public void run(){
10: if(flag){
11: a=a*1;
12: }
13: if(a==0){
14: System.out.println("ha,a==0");
15: }
16: }
17: }
當ThreadA執行的時候，按照順序執行的邏輯，當flag=true的時候，a必然等於1；那么ThreadB在if(flag)為真時，會用a=1的值去計算a*1，但CPU對Store-Load重排序后，ThreadA中的a=1可能會在flag=true后面執行，如此就造成ThreadB中a=a*1沒有根據預期的a=1來執行，所以操作系統需要提供一種機制，以禁用重排序，將決定是否重排序的選擇權交給應用程序。如果應用程序不允許重排序，則插入相應的內存屏障指令將其禁用。
Java為了能在不同平台下都能正確運行，提出了自己的內存模型，其中就定義了幾種內存屏障指令(間接調用的都是底層操作系統的內存屏障指令)
StoreLoad Barriers是一個“全能型”的屏障，它同時具有其他三個屏障的效果。現代的多處理器大都支持該屏障（其他類型的屏障不一定被所有處理器支持）。執行該屏障開銷會很昂貴，因為當前處理器通常要把寫緩沖區中的數據全部刷新到內存中（buffer fully flush）