緩存一致性協議給緩存行（通常為64字節）定義了個狀態：獨占（exclusive）、共享（share）、修改（modified）、失效（invalid），用來描述該緩存行是否被多處理器共享、是否修改。所以緩存一致性協議也稱MESI協議。
- 獨占（exclusive）：僅當前處理器擁有該緩存行，並且沒有修改過，是最新的值。
- 共享（share）：有多個處理器擁有該緩存行，每個處理器都沒有修改過緩存，是最新的值。
- 修改（modified）：緩存行被修改過了，需要寫回主存，並通知其他擁有者 “該緩存已失效”。
- 失效（invalid）：緩存行被其他處理器修改過，該值不是最新的值，需要讀取主存上最新的值。
優化
處理修改狀態是比較耗時的操作，既要發送失效消息給其他擁有者並寫回主存，還要等待其他擁有者處理失效信息，直到收到失效消息的響應。如果在這一段時間，處理器都處於空等，那是奢侈的。所以引入緩存和失效緩存來讓處理器不再“等”。
存儲緩存
存儲緩存（Store Buffers），也就是常說的寫緩存，當處理器修改緩存時，把新值放到存儲緩存中，處理器就可以去干別的事了，把剩下的事交給存儲緩存。
失效隊列
處理失效的緩存也不是簡單的，需要讀取主存。並且存儲緩存也不是無限大的，那么當存儲緩存滿的時候，處理器還是要等待失效響應的。為了解決上面兩個問題，引進了失效隊列（invalidate queue0）。
處理失效的工作如下：
- 收到失效消息時，放到失效隊列中去。
- 為了不讓處理器久等失效響應，收到失效消息需要馬上回復失效響應。
- 為了不頻繁阻塞處理器，不會馬上讀主存以及設置緩存為invlid，合適的時候再一塊處理失效隊列。
引發內存重排序
下面是處理器A、B，依次寫、讀內存a的時序圖。A、B都緩存了a。
可以看到即使遵守緩存一致性協議，也會有一段時間緩存不一致（①-⑥）。
要是讀取a的操作在這段時間內，那么處理器B看到的a將是0。處理器執行順序為寫a>讀a，而在內存上的順序為讀a>寫a，造成了重排序。重排序可能會導致不可見性，要是此時線程A、B分別在處理器A、B上執行，那么線程A執行了寫操作后，線程B看不到線程A執行的結果，共享內存a不可見，改變了程序運行結果。
避免內存重排序
引發重排序是糟糕的，可能造成共享內存不可見，改變程序結果。那么該怎么辦，不進行MESI優化嗎？既不能追求性能，造成重排序，也不能追求可見性（非共享數據可見是不需要的），降低性能。
處理器還是使用提供了個武器——內存屏障指令（Memory Barrier）：
- 寫內存屏障（Store Memory Barrier）：處理器將當前存儲緩存的值寫回主存，以阻塞的方式。
- 讀內存屏障（Load Memory Barrier）：處理器處理失效隊列，以阻塞的方式。
可以看到內存屏障可以阻止內存系統重排序，保證可見性。但其開銷也很大，處理器需要阻塞等待，一般應用在鎖的獲取和釋放中。
上面那段處理器A、B，依次寫、讀內存a，加了內存屏障后，就不會被重排序了。
boolean finish = false;
int a = 0;
//處理器A:
a = 1;
storeMemoryBarrer(); //保證a一定在主存中，且處理器B中a為invlid
finish = true;
//處理器B:
while(!finish);
loadMemoryBarrier(); //保證緩存到a最新的值，執行后a為share
assert a == 1;
JMM中抽象內存屏障
為了更好的理解如何實現同步的可見性，JMM抽象出了內存屏障Memory Barrier。
