上篇文章我們講了synchronized的用法和實現原理,我們總愛說synchronized是重量級鎖,volatile是輕量級鎖。為什麼volatile是輕量級鎖,體現在哪些方面?以及volatile的作用和實現原理是怎樣的?本篇帶你一塊學習一下。
volatile是Java提供的一種輕量級的同步機制。與synchronized修飾方法、程式碼塊不同,volatile只用來修飾變數。並且與synchronized、ReentrantLock等重量級鎖不同的是,volatile更輕量級,因為它不會引起執行緒上下文的切換和排程。
說volatile作用之前,先說一下並行程式設計的三大特性:原子性、可見性和有序性。
原子性
即一個或者多個操作作為一個整體,要麼全部執行,要麼都不執行,並且操作在執行過程中不會被執行緒排程機制打斷;而且這種操作一旦開始,就一直執行到結束,中間不會有任何上下文切換。
可見性
可見性是指當多個執行緒存取同一個變數時,一個執行緒修改了這個變數的值,其他執行緒能夠立即看得到修改的值。
有序性
為了提高程式的執行效率,編譯器會對編譯後的指令進行重排序,即程式碼的編寫順序不一定就是程式碼的執行順序。
並行程式設計中只有同時滿足這三大特性,才能保證程式正確的執行。而volatile的只保證了可見性和有序性,不保證原子性。
volatile的作用只有兩個:
保證記憶體的可見性
禁止JVM記憶體重排序(保證有序性)
在並行多執行緒情況下,為什麼會有可見性問題?如果不做控制,為什麼一個執行緒修改了共用變數的值,其他執行緒不能立即看到?這就需要聊到JMM(Java記憶體模型,Java Memory Model)。
JMM(Java記憶體模型,Java Memory Model)定義程式存取變數的規範,為了遮蔽不同作業系統之間的差異。
由於Java共用變數是儲存在主記憶體中,而Java執行緒無法直接存取主記憶體中資料,只能把主記憶體中的資料讀到本地記憶體(相當於拷貝一份副本),修改完本地記憶體的資料,再寫回主記憶體。而此時另一個執行緒也把主記憶體的資料拷貝到自己私有的本地記憶體中,雖然執行緒1已經修改了主記憶體從資料,執行緒2卻無法感知到,所以就出現了記憶體可見性問題。
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收到通知後,再根據原生的情況進行響應。
虛擬機器器在進行程式碼編譯時,對改變順序後不會對最終結果造成影響的程式碼,虛擬機器器不一定會按我們寫的程式碼順序執行,有可能進行重排序。實際上雖然重排後不會對變數值有影響,但會造成執行緒安全問題。
重排序又可以分為三種:
不過重排序也不是隨便重排的,發生指令重排序的前提是:在單執行緒下不影響執行結果、對沒有數值依賴的程式碼進行重排序。這就是as-if-serial語意。在多執行緒情況下有一套更具體的規則,那就是happens-before原則。
happens-before由以下八大原則組成:
如果兩個操作不滿足上述八大原則中的任意一個,那麼這兩個操作就沒有順序保證,虛擬機器器可以對這兩個操作進行重排序。如果操作A happens-before 操作B,那麼A在記憶體所做的修改對B都是可見的。
而volatile是通過插入記憶體屏障(Memory Barrier),在記憶體屏障前後禁止重排序優化,以此實現有序性。
記憶體屏障有兩個作用:一是保證特定操作的執行順序,二是保證某些變數的記憶體可見性。
volatile記憶體語意的實現: JMM 針對編譯器制定的 volatile 重排序規則表
操作 | 普通讀寫 | volatile讀 | volatile寫 |
---|---|---|---|
普通讀寫 | 可以重排 | 可以重排 | 不可以重排 |
volatile讀 | 不可以重排 | 不可以重排 | 不可以重排 |
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的資料安全性。
我是「一燈架構」,如果本文對你有幫助,歡迎各位小夥伴點贊、評論和關注,感謝各位老鐵,我們下期見