CPU內部也會有自己的快取，內部的快取單位是行，叫做快取行。在多核環境下會出現CPU之間的記憶體同步問題（比如一個核載入了一份快取，另外一個核也要用到同一份資料），如果每個核每次需要時都往記憶體中存取，這會帶來比較大的效能損耗，這個問題一般是通過MESI協議來解決的。

          MESI協議中包含M、E、S、I四個狀態，分別的意思是：

• M(修改, Modified): 本地處理器已經修改快取行, 即是髒行, 它的內容與記憶體中的內容不一樣. 並且此cache只有本地一個拷貝(專有).
• E(專有, Exclusive): 快取行內容和記憶體中的一樣, 而且其它處理器都沒有這行資料
• S(共享, Shared): 快取行內容和記憶體中的一樣, 有可能其它處理器也存在此快取行的拷貝
• I(無效, Invalid): 快取行失效, 不能使用

                    cpu在對快取行進行了不同的操作後，在cpu快取行中會記錄快取的不同狀態。當一個核要對共享的資料進行寫操作時，需要給其他核發送RFO(REQUEST FOR OWNER)訊息並把其他核的資料改成I態。這是一種比較消耗效能的操作。           cpu的偽共享問題本質是：幾個在邏輯上並不包含在同一個記憶體單元內的資料，由於被cpu載入在同一個快取行當中，當在多執行緒環境下，被不同的cpu執行，導致快取行失效而引起的大量的快取命中率降低。           例如：當兩個執行緒分別對一個數組中的兩份資料進行寫操作，每個執行緒操作不同index上的資料，看上去，兩份資料之間是不存在同步問題的，但是，由於他們可能在同一個cpu快取行當中，這就會使這一份快取行出現大量的快取失效，如前所述當一份執行緒更新時要給另一份執行緒傳送RFO訊息並把它的快取失效掉。           解決這個問題的一個辦法是讓這個陣列中不同index的資料在不同的快取行：因為快取行的大小是64個位元組，那我們只要讓陣列中沒份資料的大小大於64個位元組，就可以保證他們在不同的快取行當中，就能避免這樣的偽共享問題。           比如一個類當中原本只有一個long型別的屬性。這樣這個型別的物件只佔了16個位元組（java物件頭有8位元組），如果這個型別被定義成一個長度為4的陣列，這個陣列的所有資料都可能在一個快取行當中，就可能出現偽共享問題，那麼這個時候，就可以採用補齊(padding)的辦法，在這個型別中加上public long a,b,c,d,e,f,g;這六個無用的屬性定義，使得這個型別的一個例項佔用記憶體達到64位元組，這樣這個型別的偽共享問題就得到了解決，在多執行緒當中對這個型別的陣列進行寫操作就能避免偽共享問題。 轉載自：http://blog.csdn.net/e5945/article/details/8010779 感謝！