緩存一致性協議給緩存行（通常為64位元組）定義了個狀態：獨占（exclusive）、共用（share）、修改（modified）、失效（invalid），用來描述該緩存行是否被多處理器共用、是否修改。所以緩存一致性協議也稱MESI。 ...
在前面記憶體系統重排序提到，“寫緩存沒有及時刷新到記憶體，導致不同處理器緩存的值不一樣”，出現這種情況是糟糕的，所幸處理器遵循緩存一致性協議能夠保證足夠的可見性又不過多的損失性能。
緩存一致性協議給緩存行（通常為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。
