在目前主流的計算機中，cpu執行計算的主要流程如圖所示：
數據加載的流程如下：
1.將程序和數據從硬盤加載到內存中
2.將程序和數據從內存加載到緩存中(目前多三級緩存，數據加載順序:L3->L2->L1)
3.CPU將緩存中的數據加載到寄存器中，並進行運算
4.CPU會將數據刷新回緩存，並在一定的時間周期之后刷新回內存
緩存一致性協議發展背景
現在的CPU基本都是多核CPU，服務器更是提供了多CPU的支持，而每個核心也都有自己獨立的緩存，當多個核心同時操作多個線程對同一個數據進行更新時，如果核心2在核心1還未將更新的數據刷回內存之前讀取了數據，並進行操作，就會造成程序的執行結果造成隨機性的影響，這對於我們來說是無法容忍的。
而總線加鎖是對整個內存進行加鎖，在一個核心對一個數據進行修改的過程中，其他的核心也無法修改內存中的其他數據，這樣對導致CPU處理性能嚴重下降。
緩存一致性協議提供了一種高效的內存數據管理方案，它只會對單個緩存行（緩存行是緩存中數據存儲的基本單元）的數據進行加鎖，不會影響到內存中其他數據的讀寫。
因此，我們引入了緩存一致性協議來對內存數據的讀寫進行管理。
MESI協議
緩存一致性協議有MSI，MESI，MOSI，Synapse，Firefly及DragonProtocol等等，接下來我們主要介紹MESI協議。
MESI分別代表緩存行數據所處的四種狀態，通過對這四種狀態的切換，來達到對緩存數據進行管理的目的。
| 狀態 | 描述 | 監聽任務 |
| M 修改（Modify） | 該緩存行有效，數據被修改了，和內存中的數據不一致，數據只存在於本緩存行中 | 緩存行必須時刻監聽所有試圖讀該緩存行相對應的內存的操作，其他緩存須在本緩存行寫回內存並將狀態置為E之后才能操作該緩存行對應的內存數據 |
| E 獨享、互斥（Exclusive） | 該緩存行有效，數據和內存中的數據一致，數據只存在於本緩存行中 | 緩存行必須監聽其他緩存讀主內存中該緩存行相對應的內存的操作，一旦有這種操作，該緩存行需要變成S狀態 |
| S 共享（Shared） | 該緩存行有效，數據和內存中的數據一致，數據同時存在於其他緩存中 | 緩存行必須監聽其他緩存是該緩存行無效或者獨享該緩存行的請求，並將該緩存行置為I狀態 |
| I 無效（Invalid） | 該緩存行數據無效 | 無 |
備注：
1.MESI協議只對匯編指令中執行加鎖操作的變量有效，表現到java中為使用voliate關鍵字定義變量或使用加鎖操作
2.對於匯編指令中執行加鎖操作的變量，MESI協議在以下兩種情況中也會失效：
一、CPU不支持緩存一致性協議。
二、該變量超過一個緩存行的大小，緩存一致性協議是針對單個緩存行進行加鎖，此時，緩存一致性協議無法再對該變量進行加鎖，只能改用總線加鎖的方式。
MESI工作原理：（此處統一默認CPU為單核CPU，在多核CPU內部執行過程和一下流程一致）
1、CPU1從內存中將變量a加載到緩存中，並將變量a的狀態改為E（獨享），並通過總線嗅探機制對內存中變量a的操作進行嗅探
2、此時，CPU2讀取變量a，總線嗅探機制會將CPU1中的變量a的狀態置為S（共享），並將變量a加載到CPU2的緩存中，狀態為S
3、CPU1對變量a進行修改操作，此時CPU1中的變量a會被置為M（修改）狀態，而CPU2中的變量a會被通知，改為I（無效）狀態，此時CPU2中的變量a做的任何修改都不會被寫回內存中（高並發情況下可能出現兩個CPU同時修改變量a，並同時向總線發出將各自的緩存行更改為M狀態的情況，此時總線會采用相應的裁決機制進行裁決，將其中一個置為M狀態，另一個置為I狀態，且I狀態的緩存行修改無效）
4、CPU1將修改后的數據寫回內存，並將變量a置為E（獨占）狀態
5、此時，CPU2通過總線嗅探機制得知變量a已被修改，會重新去內存中加載變量a，同時CPU1和CPU2中的變量a都改為S狀態
在上述過程第3步中，CPU2的變量a被置為I（無效）狀態后，只是保證變量a的修改不會被寫回內存，但CPU2有可能會在CPU1將變量a置為E（獨占）狀態之前重新讀取內存中的變量a，這個取決於匯編指令是否要求CPU2重新加載內存。
總結
以上就是MESI的執行原理，MESI協議只能保證並發編程中的可見性，並未解決原子性和有序性的問題，所以只靠MESI協議是無法完全解決多線程中的所有問題。
————————————————
版權聲明：本文為CSDN博主「生煮雞蛋」的原創文章，遵循 CC 4.0 BY-SA 版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/alignjava/article/details/99070162