面試官想到，一個Volatile，敖丙都能吹半小時

鷹兔牛熊眼 2020-04-29

展開全文

Volatile可能是面試?yán)锩姹貑柕囊粋€話題吧，對他的認(rèn)知很多朋友也僅限于會用階段，今天我們換個角度去看看。

先來跟著丙丙來看一段demo的代碼：

你會發(fā)現(xiàn)，永遠(yuǎn)都不會輸出有點東西這一段代碼，按道理線程改了flag變量，主線程也能訪問到的呀？

為會出現(xiàn)這個情況呢？那我們就需要聊一下另外一個東西了。

JMM（JavaMemoryModel）

JMM：Java內(nèi)存模型，是java虛擬機(jī)規(guī)范中所定義的一種內(nèi)存模型，Java內(nèi)存模型是標(biāo)準(zhǔn)化的，屏蔽掉了底層不同計算機(jī)的區(qū)別（注意這個跟JVM完全不是一個東西，只有還有小伙伴搞錯的）。

那正式聊之前，丙丙先大概科普一下現(xiàn)代計算機(jī)的內(nèi)存模型吧。

現(xiàn)代計算機(jī)的內(nèi)存模型

其實早期計算機(jī)中cpu和內(nèi)存的速度是差不多的，但在現(xiàn)代計算機(jī)中，cpu的指令速度遠(yuǎn)超內(nèi)存的存取速度，由于計算機(jī)的存儲設(shè)備與處理器的運算速度有幾個數(shù)量級的差距，所以現(xiàn)代計算機(jī)系統(tǒng)都不得不加入一層讀寫速度盡可能接近處理器運算速度的高速緩存（Cache）來作為內(nèi)存與處理器之間的緩沖。

將運算需要使用到的數(shù)據(jù)復(fù)制到緩存中，讓運算能快速進(jìn)行，當(dāng)運算結(jié)束后再從緩存同步回內(nèi)存之中，這樣處理器就無須等待緩慢的內(nèi)存讀寫了。

基于高速緩存的存儲交互很好地解決了處理器與內(nèi)存的速度矛盾，但是也為計算機(jī)系統(tǒng)帶來更高的復(fù)雜度，因為它引入了一個新的問題：緩存一致性（CacheCoherence）。

在多處理器系統(tǒng)中，每個處理器都有自己的高速緩存，而它們又共享同一主內(nèi)存（MainMemory）。

然后我們可以聊一下JMM了。

JMM

Java內(nèi)存模型(JavaMemoryModel)描述了Java程序中各種變量(線程共享變量)的訪問規(guī)則，以及在JVM中將變量，存儲到內(nèi)存和從內(nèi)存中讀取變量這樣的底層細(xì)節(jié)。

JMM有以下規(guī)定：

所有的共享變量都存儲于主內(nèi)存，這里所說的變量指的是實例變量和類變量，不包含局部變量，因為局部變量是線程私有的，因此不存在競爭問題。

每一個線程還存在自己的工作內(nèi)存，線程的工作內(nèi)存，保留了被線程使用的變量的工作副本。

線程對變量的所有的操作(讀，取)都必須在工作內(nèi)存中完成，而不能直接讀寫主內(nèi)存中的變量。

不同線程之間也不能直接訪問對方工作內(nèi)存中的變量，線程間變量的值的傳遞需要通過主內(nèi)存中轉(zhuǎn)來完成。

本地內(nèi)存和主內(nèi)存的關(guān)系：

正是因為這樣的機(jī)制，才導(dǎo)致了可見性問題的存在，那我們就討論下可見性的解決方案。

可見性的解決方案

加鎖

為啥加鎖可以解決可見性問題呢？

因為某一個線程進(jìn)入synchronized代碼塊前后，線程會獲得鎖，清空工作內(nèi)存，從主內(nèi)存拷貝共享變量最新的值到工作內(nèi)存成為副本，執(zhí)行代碼，將修改后的副本的值刷新回主內(nèi)存中，線程釋放鎖。

而獲取不到鎖的線程會阻塞等待，所以變量的值肯定一直都是最新的。

Volatile修飾共享變量

開頭的代碼優(yōu)化完之后應(yīng)該是這樣的：

Volatile做了啥？

每個線程操作數(shù)據(jù)的時候會把數(shù)據(jù)從主內(nèi)存讀取到自己的工作內(nèi)存，如果他操作了數(shù)據(jù)并且寫會了，他其他已經(jīng)讀取的線程的變量副本就會失效了，需要都數(shù)據(jù)進(jìn)行操作又要再次去主內(nèi)存中讀取了。

volatile保證不同線程對共享變量操作的可見性，也就是說一個線程修改了volatile修飾的變量，當(dāng)修改寫回主內(nèi)存時，另外一個線程立即看到最新的值。

是不是看著加一個關(guān)鍵字很簡單，但實際上他在背后含辛茹苦默默付出了不少，我從計算機(jī)層面的緩存一致性協(xié)議解釋一下這些名詞的意義。

之前我們說過當(dāng)多個處理器的運算任務(wù)都涉及同一塊主內(nèi)存區(qū)域時，將可能導(dǎo)致各自的緩存數(shù)據(jù)不一致，舉例說明變量在多個CPU之間的共享。

如果真的發(fā)生這種情況，那同步回到主內(nèi)存時以誰的緩存數(shù)據(jù)為準(zhǔn)呢？

為了解決一致性的問題，需要各個處理器訪問緩存時都遵循一些協(xié)議，在讀寫時要根據(jù)協(xié)議來進(jìn)行操作，這類協(xié)議有MSI、MESI（IllinoisProtocol）、MOSI、Synapse、Firefly及DragonProtocol等。

聊一下Intel的MESI吧

MESI（緩存一致性協(xié)議）

當(dāng)CPU寫數(shù)據(jù)時，如果發(fā)現(xiàn)操作的變量是共享變量，即在其他CPU中也存在該變量的副本，會發(fā)出信號通知其他CPU將該變量的緩存行置為無效狀態(tài)，因此當(dāng)其他CPU需要讀取這個變量時，發(fā)現(xiàn)自己緩存中緩存該變量的緩存行是無效的，那么它就會從內(nèi)存重新讀取。

至于是怎么發(fā)現(xiàn)數(shù)據(jù)是否失效呢？

嗅探

每個處理器通過嗅探在總線上傳播的數(shù)據(jù)來檢查自己緩存的值是不是過期了，當(dāng)處理器發(fā)現(xiàn)自己緩存行對應(yīng)的內(nèi)存地址被修改，就會將當(dāng)前處理器的緩存行設(shè)置成無效狀態(tài)，當(dāng)處理器對這個數(shù)據(jù)進(jìn)行修改操作的時候，會重新從系統(tǒng)內(nèi)存中把數(shù)據(jù)讀到處理器緩存里。

嗅探的缺點不知道大家發(fā)現(xiàn)了沒有？

總線風(fēng)暴

由于Volatile的MESI緩存一致性協(xié)議，需要不斷的從主內(nèi)存嗅探和cas不斷循環(huán)，無效交互會導(dǎo)致總線帶寬達(dá)到峰值。

所以不要大量使用Volatile，至于什么時候去使用Volatile什么時候使用鎖，根據(jù)場景區(qū)分。

我們再來聊一下指令重排序的問題

禁止指令重排序

什么是重排序?

為了提高性能，編譯器和處理器常常會對既定的代碼執(zhí)行順序進(jìn)行指令重排序。

重排序的類型有哪些呢？源碼到最終執(zhí)行會經(jīng)過哪些重排序呢？

一個好的內(nèi)存模型實際上會放松對處理器和編譯器規(guī)則的束縛，也就是說軟件技術(shù)和硬件技術(shù)都為同一個目標(biāo)，而進(jìn)行奮斗：在不改變程序執(zhí)行結(jié)果的前提下，盡可能提高執(zhí)行效率。

JMM對底層盡量減少約束，使其能夠發(fā)揮自身優(yōu)勢。

因此，在執(zhí)行程序時，為了提高性能，編譯器和處理器常常會對指令進(jìn)行重排序。

一般重排序可以分為如下三種：

編譯器優(yōu)化的重排序。編譯器在不改變單線程程序語義的前提下，可以重新安排語句的執(zhí)行順序;
指令級并行的重排序?，F(xiàn)代處理器采用了指令級并行技術(shù)來將多條指令重疊執(zhí)行。如果不存在數(shù)據(jù)依賴性，處理器可以改變語句對應(yīng)機(jī)器指令的執(zhí)行順序;
內(nèi)存系統(tǒng)的重排序。由于處理器使用緩存和讀/寫緩沖區(qū)，這使得加載和存儲操作看上去可能是在亂序執(zhí)行的。

這里還得提一個概念，as-if-serial。

as-if-serial

不管怎么重排序，單線程下的執(zhí)行結(jié)果不能被改變。

編譯器、runtime和處理器都必須遵守as-if-serial語義。

那Volatile是怎么保證不會被執(zhí)行重排序的呢？

內(nèi)存屏障

java編譯器會在生成指令系列時在適當(dāng)?shù)奈恢脮迦?code>內(nèi)存屏障指令來禁止特定類型的處理器重排序。

為了實現(xiàn)volatile的內(nèi)存語義，JMM會限制特定類型的編譯器和處理器重排序，JMM會針對編譯器制定volatile重排序規(guī)則表：

需要注意的是：volatile寫是在前面和后面分別插入內(nèi)存屏障，而volatile讀操作是在后面插入兩個內(nèi)存屏障。

寫

讀

上面的我提過重排序原則，為了提高處理速度，JVM會對代碼進(jìn)行編譯優(yōu)化，也就是指令重排序優(yōu)化，并發(fā)編程下指令重排序會帶來一些安全隱患：如指令重排序?qū)е碌亩鄠€線程操作之間的不可見性。

如果讓程序員再去了解這些底層的實現(xiàn)以及具體規(guī)則，那么程序員的負(fù)擔(dān)就太重了，嚴(yán)重影響了并發(fā)編程的效率。

從JDK5開始，提出了happens-before的概念，通過這個概念來闡述操作之間的內(nèi)存可見性。

happens-before

如果一個操作執(zhí)行的結(jié)果需要對另一個操作可見，那么這兩個操作之間必須存在happens-before關(guān)系。

volatile域規(guī)則：對一個volatile域的寫操作，happens-before于任意線程后續(xù)對這個volatile域的讀。

如果現(xiàn)在我的變了flag變成了false，那么后面的那個操作，一定要知道我變了。

聊了這么多，我們要知道Volatile是沒辦法保證原子性的，一定要保證原子性，可以使用其他方法。

無法保證原子性

就是一次操作，要么完全成功，要么完全失敗。

假設(shè)現(xiàn)在有N個線程對同一個變量進(jìn)行累加也是沒辦法保證結(jié)果是對的，因為讀寫這個過程并不是原子性的。

要解決也簡單，要么用原子類，比如AtomicInteger，要么加鎖(記得關(guān)注Atomic的底層)。

應(yīng)用

單例有8種寫法，我說一下里面比較特殊的一種，涉及Volatile的。

大家可能好奇為啥要雙重檢查？如果不用Volatile會怎么樣？

我先講一下禁止指令重排序的好處。

對象實際上創(chuàng)建對象要進(jìn)過如下幾個步驟：

分配內(nèi)存空間。
調(diào)用構(gòu)造器，初始化實例。
返回地址給引用

上面我不是說了嘛，是可能發(fā)生指令重排序的，那有可能構(gòu)造函數(shù)在對象初始化完成前就賦值完成了，在內(nèi)存里面開辟了一片存儲區(qū)域后直接返回內(nèi)存的引用，這個時候還沒真正的初始化完對象。

但是別的線程去判斷instance！=null，直接拿去用了，其實這個對象是個半成品，那就有空指針異常了。

可見性怎么保證的？

因為可見性，線程A在自己的內(nèi)存初始化了對象，還沒來得及寫回主內(nèi)存，B線程也這么做了，那就創(chuàng)建了多個對象，不是真正意義上的單例了。

上面提到了volatile與synchronized，那我聊一下他們的區(qū)別。

volatile與synchronized的區(qū)別

volatile只能修飾實例變量和類變量，而synchronized可以修飾方法，以及代碼塊。

volatile保證數(shù)據(jù)的可見性，但是不保證原子性(多線程進(jìn)行寫操作，不保證線程安全);而synchronized是一種排他(互斥)的機(jī)制。

volatile用于禁止指令重排序：可以解決單例雙重檢查對象初始化代碼執(zhí)行亂序問題。

volatile可以看做是輕量版的synchronized，volatile不保證原子性，但是如果是對一個共享變量進(jìn)行多個線程的賦值，而沒有其他的操作，那么就可以用volatile來代替synchronized，因為賦值本身是有原子性的，而volatile又保證了可見性，所以就可以保證線程安全了。

總結(jié)

volatile修飾符適用于以下場景：某個屬性被多個線程共享，其中有一個線程修改了此屬性，其他線程可以立即得到修改后的值，比如booleanflag;或者作為觸發(fā)器，實現(xiàn)輕量級同步。
volatile屬性的讀寫操作都是無鎖的，它不能替代synchronized，因為它沒有提供原子性和互斥性。因為無鎖，不需要花費時間在獲取鎖和釋放鎖_上，所以說它是低成本的。
volatile只能作用于屬性，我們用volatile修飾屬性，這樣compilers就不會對這個屬性做指令重排序。
volatile提供了可見性，任何一個線程對其的修改將立馬對其他線程可見，volatile屬性不會被線程緩存，始終從主存中讀取。
volatile提供了happens-before保證，對volatile變量v的寫入happens-before所有其他線程后續(xù)對v的讀操作。
volatile可以使得long和double的賦值是原子的。
volatile可以在單例雙重檢查中實現(xiàn)可見性和禁止指令重排序，從而保證安全性。

注：以上所有的內(nèi)容如果能全部掌握我想Volatile在面試官那是很加分了，但是我還沒講到很多關(guān)于計算機(jī)內(nèi)存那一塊的底層，那大家就需要后面去補課了，如果等得及，也可以等到我寫計算機(jī)基礎(chǔ)章節(jié)。