在前面記憶體系統重排序提到，“寫快取沒有及時重新整理到記憶體，導致不同處理器快取的值不一樣”，出現這種情況是糟糕的，所幸處理器遵循快取一致性協議能夠保證足夠的可見性又不過多的損失效能。

 快取一致性協議給快取行（通常為64位元組）定義了個狀態：獨佔（exclusive）、共享（share）、修改（modified）、失效（invalid），用來描述該快取行是否被多處理器共享、是否修改。所以快取一致性協議也稱MESI協議。

• 獨佔（exclusive）：僅當前處理器擁有該快取行，並且沒有修改過，是最新的值。
• 共享（share）：有多個處理器擁有該快取行，每個處理器都沒有修改過快取，是最新的值。
• 修改（modified）：快取行被修改過了，需要寫回主存，並通知其他擁有者 “該快取已失效”。
• 失效（invalid）：快取行被其他處理器修改過，該值不是最新的值，需要讀取主存上最新的值。

MESI優化

 處理修改狀態是比較耗時的操作，既要傳送失效訊息給其他擁有者並寫回主存，還要等待其他擁有者處理失效資訊，直到收到失效訊息的響應。如果在這一段時間，處理器都處於空等，那是奢侈的。所以引入快取和失效快取來讓處理器不再“等”。

儲存快取

 儲存快取（Store Buffers），也就是常說的寫快取，當處理器修改快取時，把新值放到儲存快取中，處理器就可以去幹別的事了，把剩下的事交給儲存快取。

失效佇列

 處理失效的快取也不是簡單的，需要讀取主存。並且儲存快取也不是無限大的，那麼當儲存快取滿的時候，處理器還是要等待失效響應的。為了解決上面兩個問題，引進了失效佇列（invalidate queue0）。

 處理失效的工作如下：
1. 收到失效訊息時，放到失效佇列中去。
2. 為了不讓處理器久等失效響應，收到失效訊息需要馬上回復失效響應。
3. 為了不頻繁阻塞處理器，不會馬上讀主存以及設定快取為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）：
1. 寫記憶體屏障（Store Memory Barrier）：處理器將當前儲存快取的值寫回主存，以阻塞的方式。
2. 讀記憶體屏障（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。