上篇文章我們講了synchronized的用法和實作原理,我們總愛說synchronized是重量級鎖,volatile是輕量級鎖,為什么volatile是輕量級鎖,體現在哪些方面?以及volatile的作用和實作原理是怎樣的?本篇帶你一塊學習一下,
1. volatile是什么?
volatile是Java提供的一種輕量級的同步機制,與synchronized修飾方法、代碼塊不同,volatile只用來修飾變數,并且與synchronized、ReentrantLock等重量級鎖不同的是,volatile更輕量級,因為它不會引起執行緒背景關系的切換和調度,
2. volatile的作用
說volatile作用之前,先說一下并發編程的三大特性:原子性、可見性和有序性,
-
原子性
即一個或者多個操作作為一個整體,要么全部執行,要么都不執行,并且操作在執行程序中不會被執行緒調度機制打斷;而且這種操作一旦開始,就一直運行到結束,中間不會有任何背景關系切換,
-
可見性
可見性是指當多個執行緒訪問同一個變數時,一個執行緒修改了這個變數的值,其他執行緒能夠立即看得到修改的值,
-
有序性
為了提高程式的執行效率,編譯器會對編譯后的指令進行重排序,即代碼的撰寫順序不一定就是代碼的執行順序,
并發編程中只有同時滿足這三大特性,才能保證程式正確的執行,而volatile的只保證了可見性和有序性,不保證原子性,
volatile的作用只有兩個:
-
保證記憶體的可見性
-
禁止JVM記憶體重排序(保證有序性)
在并發多執行緒情況下,為什么會有可見性問題?如果不做控制,為什么一個執行緒修改了共享變數的值,其他執行緒不能立即看到?這就需要聊到JMM(Java記憶體模型,Java Memory Model),
3. JMM是什么
JMM(Java記憶體模型,Java Memory Model)定義程式訪問變數的規范,為了屏蔽不同作業系統之間的差異,
由于Java共享變數是存盤在主記憶體中,而Java執行緒無法直接訪問主記憶體中資料,只能把主記憶體中的資料讀到本地記憶體(相當于拷貝一份副本),修改完本地記憶體的資料,再寫回主記憶體,而此時另一個執行緒也把主記憶體的資料拷貝到自己私有的本地記憶體中,雖然執行緒1已經修改了主記憶體從資料,執行緒2卻無法感知到,所以就出現了記憶體可見性問題,

4. 可見性問題
JMM定義的這套模型,會有可見性問題,當執行緒1修改了本地記憶體的資料,并刷會主記憶體中,其他執行緒中本地記憶體的資料并沒有變化,也就是一個執行緒修改了共享變數的值,其他執行緒無法立即感知到,

像上圖的流程,兩個執行緒都把count=0的變數拷貝到自己私有的本地記憶體中,執行緒1把count的值修改為1,并寫回主記憶體,而執行緒2本地記憶體的count值還是0,
那么volatile是怎么解決可見性問題呢?
volatile主要通過匯編lock前綴指令,它會鎖定當前記憶體區域的快取(快取行),并且立即將當前快取行資料寫入主記憶體(耗時非常短),回寫主記憶體的時候會通過MESI協議使其他執行緒快取了該變數的地址失效,從而導致其他執行緒需要重新去主記憶體中重新讀取資料到其作業執行緒中,
什么是MESI協議?
MESI協議(Modified Exclusive Shared Or Invalid)是各處理器訪問快取時都遵循一致性協議,核心思想是:
當CPU寫資料時,如果發現操作的變數是共享變數,即在其他CPU中也存在該變數的副本,會發出信號通知其他CPU將該變數的快取行置為無效狀態,因此當其他CPU需要讀取這個變數時,發現自己快取中快取該變數的快取行是無效的,那么它就會從記憶體重新讀取,
MESI分別代表快取行資料所處的四種狀態,通過對這四種狀態的切換,來達到對快取資料進行管理的目的,
| 狀態 | 描述 | 監聽任務 |
|---|---|---|
| M 修改(Modify) | 該快取行有效,資料被修改了,和記憶體中的資料不一致,資料只存在于本快取行中 | 快取行必須時刻監聽所有試圖讀該快取行相對應的記憶體的操作,其他快取須在本快取行寫回記憶體并將狀態置為E之后才能操作該快取行對應的記憶體資料 |
| E 獨享、互斥(Exclusive) | 該快取行有效,資料和記憶體中的資料一致,資料只存在于本快取行中 | 快取行必須監聽其他快取讀主記憶體中該快取行相對應的記憶體的操作,一旦有這種操作,該快取行需要變成S狀態 |
| S 共享(Shared) | 該快取行有效,資料和記憶體中的資料一致,資料同時存在于其他快取中 | 快取行必須監聽其他快取是該快取行無效或者獨享該快取行的請求,并將該快取行置為I狀態 |
| I 無效(Invalid) | 該快取行資料無效 | 無 |
而MESI協議是通過總線嗅探技術實作的:
總線嗅探是通過CPU偵聽總線上發生的資料交換操作,當總線上發生了資料操作,那么總線就會廣播對應的通知,CPU收到通知后,再根據本地的情況進行回應,
5. 有序性問題
虛擬機在進行代碼編譯時,對改變順序后不會對最終結果造成影響的代碼,虛擬機不一定會按我們寫的代碼順序運行,有可能進行重排序,實際上雖然重排后不會對變數值有影響,但會造成執行緒安全問題,
重排序又可以分為三種:
- 編譯器優化的重排序,編譯器在不改變單執行緒程式語意的前提下,可以重新安排陳述句的執行順序
- 指令級并行的重排序,現代CPU采用了指令級并行技術來將多條指令重疊執行,對于不存在資料依賴的指令,CPU可以改變陳述句對應機器指令的執行順序
- 記憶體系統的重排序,由于CPU使用三級快取結構,這使得資料加載和存盤操作看上去可能是在亂序執行的
不過重排序也不是隨便重排的,發生指令重排序的前提是:在單執行緒下不影響執行結果、對沒有數值依賴的代碼進行重排序,這就是as-if-serial語意,在多執行緒情況下有一套更具體的規則,那就是happens-before原則,
happens-before由以下八大原則組成:
- 程式次序規則:一個執行緒內,按照代碼順序,書寫在前面的操作先行發生于書寫在后面的操作(執行緒的執行結果有序)
- 鎖定規則:一個unlock操作先行發生于后面對同一個鎖的lock操作
- volatile變數規則:對一個volatile變數的寫操作先行發生于后面對這個變數的讀操作
- 傳遞規則:如果操作A先行發生于操作B,操作B先行發生于操作C,則可以得出操作A先行發生于操作C
- 執行緒啟動規則:Thread物件的start()方法先行發生于該執行緒的其他任何操作
- 執行緒中斷規則:對執行緒中斷方法interrupt()的呼叫先行發生于被中斷執行緒檢測到中斷事件的發生
- 執行緒終結規則:執行緒中所有操作先行發生于執行緒的終止檢測,通過Thread.join()方法結束、Thread.isAlive()方法的回傳值等手段檢測到執行緒已經終止執行,比如在A執行緒中呼叫B.join()方法,B執行緒執行完成后,B對共享變數的修改,對A來說是可見的
- 物件終結規則:一個物件的初始化方法完成先行發生于該物件的finalize()方法的開始
如果兩個操作不滿足上述八大原則中的任意一個,那么這兩個操作就沒有順序保證,虛擬機可以對這兩個操作進行重排序,如果操作A happens-before 操作B,那么A在記憶體所做的修改對B都是可見的,
而volatile是通過插入記憶體屏障(Memory Barrier),在記憶體屏障前后禁止重排序優化,以此實作有序性,
記憶體屏障有兩個作用:一是保證特定操作的執行順序,二是保證某些變數的記憶體可見性,
volatile記憶體語意的實作: JMM 針對編譯器制定的 volatile 重排序規則表
| 操作 | 普通讀寫 | volatile讀 | volatile寫 |
|---|---|---|---|
| 普通讀寫 | 可以重排 | 可以重排 | 不可以重排 |
| volatile讀 | 不可以重排 | 不可以重排 | 不可以重排 |
| volatile寫 | 可以重排 | 不可以重排 | 不可以重排 |
編譯器在生成位元組碼時,會在指令序列中插入記憶體屏障來禁止特定型別的處理器重排序:
- 在每個volatile寫操作的前面插入一個StoreStore屏障
- 在每個volatile寫操作的后面插入一個StoreLoad屏障
- 在每個volatile讀操作的后面插入一個LoadLoad屏障
- 在每個volatile讀操作的后面插入一個LoadStore屏障
6. volatile應用場景
volatile可以保證可見性和有序性,但無法保證原子性,所以它的應用場景就不如synchronized廣泛,主要有兩個場景:一是做狀態變數,二是做需要重新賦值的共享物件,
比如:第二種場景常見的就有修飾單例模式的物件,
public class Singleton {
// 使用volatile修飾,賦值后,其他執行緒能立即感知到
private static volatile Singleton instance;
private Singleton() {
}
public static Singleton getInstance() {
if (instance == null) {
synchronized (Singleton.class) {
if (instance == null) {
instance = new Singleton();
}
}
}
return instance;
}
}
還有就是CopyOnWriteArrayList的底層實作就是用volatile修飾的陣列,因為CopyOnWriteArrayList每次修改資料后都會陣列重新賦值,而不是只修改資料中的一個值,這樣才能保證了CopyOnWriteArrayList的資料安全性,

我是「一燈架構」,如果本文對你有幫助,歡迎各位小伙伴點贊、評論和關注,感謝各位老鐵,我們下期見

轉載請註明出處,本文鏈接:https://www.uj5u.com/houduan/523855.html
標籤:Java
上一篇:騰訊員工曬出薪資:真實 985 畢業薪資,大家看我還有救嗎??
下一篇:SpringMVC詳解
