Java內(nèi)存模型（JMM）是基于多線程的嗎

這個問題按我的思路轉(zhuǎn)換了下，其實就是在問：為什么需要Java內(nèi)存模型

總結(jié)起來可以由幾個角度來看待「可見性」、「有序性」和「原子性」

面試官：今天想跟你聊聊Java內(nèi)存模型，這塊你了解過嗎？

候選者：嗯，我簡單說下我的理解吧。那我就從為什么要有Java內(nèi)存模型開始講起吧

面試官：開始你的表演吧。

候選者：那我先說下背景吧

候選者：1. 現(xiàn)有計算機往往是多核的，每個核心下會有高速緩存。高速緩存的誕生是由于「CPU與內(nèi)存(主存)的速度存在差異」，L1和L2緩存一般是「每個核心獨占」一份的。

候選者：2. 為了讓CPU提高運算效率，處理器可能會對輸入的代碼進(jìn)行「亂序執(zhí)行」，也就是所謂的「指令重排序」

候選者：3. 一次對數(shù)值的修改操作往往是非原子性的（比如i++實際上在計算機執(zhí)行時就會分成多個指令）

候選者：在永遠(yuǎn)單線程下，上面所講的均不會存在什么問題，因為單線程意味著無并發(fā)。并且在單線程下，編譯器/runtime/處理器都必須遵守as-if-serial語義，遵守as-if-serial意味著它們不會對「數(shù)據(jù)依賴關(guān)系的操作」做重排序。

候選者：CPU為了效率，有了高速緩存、有了指令重排序等等，整塊架構(gòu)都變得復(fù)雜了。我們寫的程序肯定也想要「充分」利用CPU的資源??！于是乎，我們使用起了多線程

候選者：多線程在意味著并發(fā)，并發(fā)就意味著我們需要考慮線程安全問題

候選者：1. 緩存數(shù)據(jù)不一致：多個線程同時修改「共享變量」，CPU核心下的高速緩存是「不共享」的，那多個cache與內(nèi)存之間的數(shù)據(jù)同步該怎么做？

候選者：2. CPU指令重排序在多線程下會導(dǎo)致代碼在非預(yù)期下執(zhí)行，最終會導(dǎo)致結(jié)果存在錯誤的情況。

候選者：針對于「緩存不一致」問題，CPU也有其解決辦法，常被大家所認(rèn)識的有兩種：

候選者：1.使用「總線鎖」：某個核心在修改數(shù)據(jù)的過程中，其他核心均無法修改內(nèi)存中的數(shù)據(jù)。（類似于獨占內(nèi)存的概念，只要有CPU在修改，那別的CPU就得等待當(dāng)前CPU釋放）

候選者：2.緩存一致性協(xié)議（MESI協(xié)議，其實協(xié)議有很多，只是舉個大家都可能見過的）。MESI拆開英文是（Modified （修改狀態(tài)）、Exclusive （獨占狀態(tài)）、Share（共享狀態(tài)）、Invalid（無效狀態(tài)））

候選者：緩存一致性協(xié)議我認(rèn)為可以理解為「緩存鎖」，它針對的是「緩存行」(Cache line) 進(jìn)行”加鎖”，所謂「緩存行」其實就是 高速緩存 存儲的最小單位。

面試官：嗯…

候選者：MESI協(xié)議的原理大概就是：當(dāng)每個CPU讀取共享變量之前，會先識別數(shù)據(jù)的「對象狀態(tài)」(是修改、還是共享、還是獨占、還是無效)。

候選者：如果是獨占，說明當(dāng)前CPU將要得到的變量數(shù)據(jù)是最新的，沒有被其他CPU所同時讀取

候選者：如果是共享，說明當(dāng)前CPU將要得到的變量數(shù)據(jù)還是最新的，有其他的CPU在同時讀取，但還沒被修改

候選者：如果是修改，說明當(dāng)前CPU正在修改該變量的值，同時會向其他CPU發(fā)送該數(shù)據(jù)狀態(tài)為invalid(無效)的通知，得到其他CPU響應(yīng)后（其他CPU將數(shù)據(jù)狀態(tài)從共享(share)變成invalid(無效)），會當(dāng)前CPU將高速緩存的數(shù)據(jù)寫到主存，并把自己的狀態(tài)從modify(修改)變成exclusive(獨占)

候選者：如果是無效，說明當(dāng)前數(shù)據(jù)是被改過了，需要從主存重新讀取最新的數(shù)據(jù)。

候選者：其實MESI協(xié)議做的就是判斷「對象狀態(tài)」，根據(jù)「對象狀態(tài)」做不同的策略。關(guān)鍵就在于某個CPU在對數(shù)據(jù)進(jìn)行修改時，需要「同步」通知其他CPU，表示這個數(shù)據(jù)被我修改了，你們不能用了。

候選者：比較于「總線鎖」，MESI協(xié)議的”鎖粒度”更小了，性能那肯定會更高咯

面試官：但據(jù)我了解，CPU還有優(yōu)化，你還知道嗎？

候選者：嗯，還是了解那么一點點的。

候選者：從前面講到的，可以發(fā)現(xiàn)的是：當(dāng)CPU修改數(shù)據(jù)時，需要「同步」告訴其他的CPU，等待其他CPU響應(yīng)接收到invalid(無效)后，它才能將高速緩存數(shù)據(jù)寫到主存。

候選者：同步，意味著等待，等待意味著什么都干不了。CPU肯定不樂意啊，所以又優(yōu)化了一把。

候選者：優(yōu)化思路就是從「同步」變成「異步」。

候選者：在修改時會「同步」告訴其他CPU，而現(xiàn)在則把最新修改的值寫到「[store buffer](https://www.zhihu.com/search?q=store buffer&search_source=Entity&hybrid_search_source=Entity&hybrid_search_extra={"sourceType"%3A"answer"%2C"sourceId"%3A2215772844})」中，并通知其他CPU記得要改狀態(tài)，隨后CPU就直接返回干其他事了。等到收到其它CPU發(fā)過來的響應(yīng)消息，再將數(shù)據(jù)更新到高速緩存中。

候選者：其他CPU接收到invalid(無效)通知時，也會把接收到的消息放入「invalid queue」中，只要寫到「invalid queue」就會直接返回告訴修改數(shù)據(jù)的CPU已經(jīng)將狀態(tài)置為「invalid」

候選者：而異步又會帶來新問題：那我現(xiàn)在CPU修改完A值，寫到「store buffer」了，CPU就可以干其他事了。那如果該CPU又接收指令需要修改A值，但上一次修改的值還在「store buffer」中呢，沒修改至高速緩存呢。

候選者：所以CPU在讀取的時候，需要去「store buffer」看看存不存在，存在則直接取，不存在才讀主存的數(shù)據(jù)?！維tore Forwarding】

候選者：好了，解決掉第一個異步帶來的問題了。（相同的核心對數(shù)據(jù)進(jìn)行讀寫，由于異步，很可能會導(dǎo)致第二次讀取的還是舊值，所以首先讀「store buffer」。

面試官：還有其他？

候選者：那當(dāng)然啊，那「異步化」會導(dǎo)致相同核心讀寫共享變量有問題，那當(dāng)然也會導(dǎo)致「不同」核心讀寫共享變量有問題啊

候選者：CPU1修改了A值，已把修改后值寫到「store buffer」并通知CPU2對該值進(jìn)行invalid(無效)操作，而CPU2可能還沒收到invalid(無效)通知，就去做了其他的操作，導(dǎo)致CPU2讀到的還是舊值。

候選者：即便CPU2收到了invalid(無效)通知，但CPU1的值還沒寫到主存，那CPU2再次向主存讀取的時候，還是舊值…

候選者：變量之間很多時候是具有「相關(guān)性」(a=1;b=0;b=a)，這對于CPU又是無感知的…

候選者：總體而言，由于CPU對「緩存一致性協(xié)議」進(jìn)行的異步優(yōu)化「store buffer」「invalid queue」，很可能導(dǎo)致后面的指令很可能查不到前面指令的執(zhí)行結(jié)果（各個指令的執(zhí)行順序非代碼執(zhí)行順序），這種現(xiàn)象很多時候被稱作「CPU亂序執(zhí)行」

候選者：為了解決亂序問題（也可以理解為可見性問題，修改完沒有及時同步到其他的CPU），又引出了「內(nèi)存屏障」的概念。

面試官：嗯…

候選者：「內(nèi)存屏障」其實就是為了解決「異步優(yōu)化」導(dǎo)致「CPU亂序執(zhí)行」/「緩存不及時可見」的問題，那怎么解決的呢？嗯，就是把「異步優(yōu)化」給”禁用“掉（：

候選者：內(nèi)存屏障可以分為三種類型：寫屏障，讀屏障以及全能屏障（包含了讀寫屏障），屏障可以簡單理解為：在操作數(shù)據(jù)的時候，往數(shù)據(jù)插入一條”特殊的指令”。只要遇到這條指令，那前面的操作都得「完成」。

候選者：那寫屏障就可以這樣理解：CPU當(dāng)發(fā)現(xiàn)寫屏障的指令時，會把該指令「之前」存在于「store Buffer」所有寫指令刷入高速緩存。

候選者：通過這種方式就可以讓CPU修改的數(shù)據(jù)可以馬上暴露給其他CPU，達(dá)到「寫操作」可見性的效果。

候選者：那讀屏障也是類似的：CPU當(dāng)發(fā)現(xiàn)讀屏障的指令時，會把該指令「之前」存在于「invalid queue」所有的指令都處理掉

候選者：通過這種方式就可以確保當(dāng)前CPU的緩存狀態(tài)是準(zhǔn)確的，達(dá)到「讀操作」一定是讀取最新的效果。

候選者：由于不同CPU架構(gòu)的緩存體系不一樣、緩存一致性協(xié)議不一樣、重排序的策略不一樣、所提供的內(nèi)存屏障指令也有差異，為了簡化Java開發(fā)人員的工作。Java封裝了一套規(guī)范，這套規(guī)范就是「Java內(nèi)存模型」

候選者：再詳細(xì)地說，「Java內(nèi)存模型」希望 屏蔽各種硬件和操作系統(tǒng)的訪問差異，保證了Java程序在各種平臺下對內(nèi)存的訪問都能得到一致效果。目的是解決多線程存在的原子性、可見性（緩存一致性）以及有序性問題。

面試官：那要不簡單聊聊Java內(nèi)存模型的規(guī)范和內(nèi)容吧？

候選者：不了，怕一聊就是一個下午，下次吧？

本文總結(jié)：

• 并發(fā)問題產(chǎn)生的三大根源是「可見性」「有序性」「原子性」

• 可見性：CPU架構(gòu)下存在高速緩存，每個核心下的L1/L2高速緩存不共享（不可見）

• 有序性：主要有三方面可能導(dǎo)致打破

• • 編譯器優(yōu)化導(dǎo)致重排序（編譯器可以在不改變單線程程序語義的情況下，可以對代碼語句順序進(jìn)行調(diào)整重新排序）
  • 指令集并行重排序（CPU原生就有可能將指令進(jìn)行重排）
  • 內(nèi)存系統(tǒng)重排序（CPU架構(gòu)下很可能有store buffer /invalid queue 緩沖區(qū)，這種「異步」很可能會導(dǎo)致指令重排）

• 原子性：Java的一條語句往往需要多條 CPU 指令完成(i++)，由于操作系統(tǒng)的線程切換很可能導(dǎo)致 i++ 操作未完成，其他線程“中途”操作了共享變量 i ，導(dǎo)致最終結(jié)果并非我們所期待的。

• 在CPU層級下，為了解決「緩存一致性」問題，有相關(guān)的“鎖”來保證，比如“總線鎖”和“緩存鎖”。

• • 總線鎖是鎖總線，對共享變量的修改在相同的時刻只允許一個CPU操作。
  • 緩存鎖是鎖緩存行(cache line)，其中比較出名的是MESI協(xié)議，對緩存行標(biāo)記狀態(tài)，通過“同步通知”的方式，來實現(xiàn)(緩存行)數(shù)據(jù)的可見性和有序性
  • 但“同步通知”會影響性能，所以會有內(nèi)存緩沖區(qū)(store buffer/invalid queue)來實現(xiàn)「異步」進(jìn)而提高CPU的工作效率
  • 引入了內(nèi)存緩沖區(qū)后，又會存在「可見性」和「有序性」的問題，平日大多數(shù)情況下是可以享受「異步」帶來的好處的，但少數(shù)情況下，需要強「可見性」和「有序性」，只能”禁用”緩存的優(yōu)化。
  • “禁用”緩存優(yōu)化在CPU層面下有「內(nèi)存屏障」，讀屏障/寫屏障/全能屏障，本質(zhì)上是插入一條”屏障指令”，使得緩沖區(qū)(store buffer/[invalid queue](https://www.zhihu.com/search?q=invalid queue&search_source=Entity&hybrid_search_source=Entity&hybrid_search_extra={"sourceType"%3A"answer"%2C"sourceId"%3A2215772844}))在屏障指令之前的操作均已被處理，進(jìn)而達(dá)到 讀寫 在CPU層面上是可見和有序的。

• 不同的CPU實現(xiàn)的架構(gòu)和優(yōu)化均不一樣，Java為了屏蔽硬件和操作系統(tǒng)訪問內(nèi)存的各種差異，提出了「Java內(nèi)存模型」的規(guī)范，保證了Java程序在各種平臺下對內(nèi)存的訪問都能得到一致效果

本文由博客一文多發(fā)平臺 OpenWrite 發(fā)布！