本文轉載自聊聊內存屏障
導語
在之前文章聊聊JMM，說到了內存屏障，內存屏障在Java語言實現一致性內存模型上起到了重要的作用，本文我們一起聊一聊內存屏障
內存屏障是什么
在cpu執行指令的過程中，對於同一個線程中沒有數據依賴的指令可以重新排序優化，有數據依賴的指令按照順序串行執行，來保證單線程程序運行的正確性，同時也提升了CPU的執行效率，合理的利用了CPU等待時間，
在多核CPU的情況下，因為多核CPU上的指令同時執行，如果涉及到共享變量的修改，這種優化會影響多線程運行的正確性,而內存屏障（memory barrier/memory fence）是硬件層面提供的一系列特殊指令，當CPU處理到這些指定時，會做一些特殊的處理，可以使處理器內的內存狀態對其它處理器可見，在不同的平台上支持的內存屏障也會有差異。
解答之前的疑問
在之間的文章聊聊緩存一致性協議中，結尾提到一個問題：MESI頻繁的消息請求與響應帶來的性能問題如何解決?
MESI協議解決了緩存一致性問題，但是頻繁的請求與響應，會產生大量的等待時間，請求等待響應的返回之后才能將數據寫入高速緩存中，為了避免減少這種性能問題，硬件層面引入了寫緩存（store/write buffer）和無效化隊列（invalidate queue), 結構如下圖
寫緩沖器（store buffer也稱為 write buffer）是處理器內部的一個容量比高速緩存還小的私有高速緩存部件，每個處理器都有自己的寫緩沖器，寫緩沖器內部包含若干個條目，並且寫緩沖器之間是無法直接訪問的。引入寫緩沖器，使得處理器在執行寫操作的時候，寫入寫緩沖器中，而不需要等待response響應，來減少寫操作的延時，在節省的時間內可以執行更多其它指令，從而提高處理器的執行效率。
無效化隊列是用處理Invalidate消息的，當該消息被廣播到總線上，其它的CPU都在監聽此消息，同其它的CPU都要回復一個Invalidate Response消息，這會產生大量的廣播事件，所以在引入無效化隊列之后，處理器在收到Invalidate消息之后，並不立馬刪除地址中對應的副本數據（其實是更新緩存行的狀態為無效）,而是將消息存入無效化隊列之后就直接響應Invalidate Response消息了，從而減少了寫操作執行處理器的等待時間。
通過寫緩沖器和無效化隊列的，將消息累積起來，立馬響應請求，提高處理器執行效率，然后在特定的時間（寫緩沖滿之后或者執行到內存屏障 ），批量將寫緩沖中的數據寫回主存，將無效化隊列應用到高速緩存中，但是他們的引入，又帶來了內存重排序和可見性問題。
寫緩沖器和無效化隊列帶來的問題
-
寫緩沖器導致StoreLoad重排
-
寫緩沖器導致StoreStore重排
-
無效化隊列導致LoadLoad重排
-
CPU對共享變量的更新，到達寫緩沖器中就返回了，這就可能導致其它CPU無法讀到共享變量的最新值，因為共享變量的修改還在前一個CPU的寫緩沖器中，連高速緩存都沒到了， 無法通過MESI協議保證一致性，這個現象就是可見性問題
-
CPU對於Invalidate的請求，到達無效化隊列之后就返回了，還沒有將高速緩存中的相關副本數據刪除，這就可能導致該處理器讀了的數據是過時的數據 ，從而導致更新丟失 ，這個現象也可以理解為是可見性問題
對於上面的問題，用到的就是我們今天的主角，內存屏障
內存屏障分類與作用
在X86平台提供了幾種主要的內存屏障
- lfence - 加載屏障
- 清空無效化隊列，根據無效化隊列中內容的內存地址，將相應處理器上高速緩存中的緩存條件狀態置為I，使后續對該地址的讀取時，必須發送Read消息，具體過程可參考 聊聊緩存一致性協議
- 用在讀指令前，阻止屏障兩邊的讀指令重排
- sfence - 存儲屏障：
- 沖刷寫緩沖器中的內容，將寫緩沖器中內容的更新應用於高速緩存
- 用在寫指令之后，阻止屏障兩邊的寫指令重排（執行到該屏障時，將對緩存中的條目打標記，標識這些條目需要在該屏障之前提交，當執行到寫操作時，檢測到寫緩沖器中存在被標記的條目，不管寫操作對應的條目狀態，即使是E,M也不將寫操作的數據回寫高速緩存，而是寫入寫緩沖器的方式，使得屏障之間和屏障之后的指令修改都串行在寫緩沖器中，來保證其順序）
- mfence - 全能屏障
- 具備ifence和sfence的能力, 實現是通過加載屏障和存儲屏障的成對使用，可以保證寫緩沖的內容同步到高速緩存，無效化隊列的內容應用到高速緩存，然后再根據緩存一致性協議保證共享數據的一致性
- 阻止指令重排