Java 併發:volatile 關鍵字解析
摘要:
在 Java 併發程式設計中,要想使併發程式能夠正確地執行,必須要保證三條原則,即:原子性、可見性和有序性。只要有一條原則沒有被保證,就有可能會導致程式執行不正確。volatile關鍵字 被用來保證可見性,即保證共享變數的記憶體可見性以解決快取一致性問題。一旦一個共享變數被 volatile關鍵字 修飾,那麼就具備了兩層語義:記憶體可見性和禁止進行指令重排序。在多執行緒環境下,volatile關鍵字 主要用於及時感知共享變數的修改,並使得其他執行緒可以立即得到變數的最新值,例如,用於 修飾狀態標記量 和 Double-Check (雙重檢查)中。
volatile關鍵字 雖然從字面上理解起來比較簡單,但是要用好不是一件容易的事情。由於 volatile關鍵字 是與 記憶體模型 緊密相關,因此在講述 volatile關鍵字 之前,我們有必要先去了解與記憶體模型相關的概念和知識,然後回頭再分析 volatile關鍵字 的實現原理,最後在給出 volatile關鍵字 的使用場景。
一. 記憶體模型的相關概念
大家都知道,計算機在執行程式時,每條指令都是在 CPU 中執行的,而執行指令過程中,勢必涉及到資料的讀取和寫入。由於程式執行過程中的臨時資料是存放在主存(實體記憶體)當中的,這時就存在一個問題:由於 CPU 執行速度很快,而從記憶體讀取資料和向記憶體寫入資料的過程跟 CPU 執行指令的速度比起來要慢的多,因此如果任何時候對資料的操作都要通過和記憶體的互動來進行,會大大降低指令執行的速度。因此,在 CPU 裡面就有了 快取記憶體(暫存器)。
也就是說,在程式執行過程中,會將運算需要的資料從主存複製一份到 CPU 的快取記憶體當中,那麼, CPU 進行計算時就可以直接從它的快取記憶體讀取資料和向其中寫入資料,當運算結束之後,再將快取記憶體中的資料重新整理到主存當中。
i = i + 1;
當執行緒執行這個語句時,會先從主存當中讀取 i 的值,然後複製一份到快取記憶體當中,然後CPU執行指令對 i 進行加1操作,然後將資料寫入快取記憶體,最後將快取記憶體中 i 最新的值重新整理到主存當中。
這個程式碼在單執行緒中執行是沒有任何問題的,但是在多執行緒中執行就會有問題了。在多核 CPU 中,每個執行緒可能運行於不同的 CPU 中,因此每個執行緒執行時有自己的快取記憶體(對單核CPU來說,其實也會出現這種問題,只不過是以執行緒排程的形式來分別執行的)。本文我們以多核CPU為例。
比如,同時有兩個執行緒執行這段程式碼,假如初始時 i 的值為 0,那麼我們希望兩個執行緒執行完之後 i 的值變為 2。但是事實會是這樣嗎?
可能存在下面一種情況:初始時,兩個執行緒分別讀取 i 的值存入各自所在的 CPU 的快取記憶體當中,然後執行緒1 進行加 1 操作,然後把 i 的最新值 1 寫入到記憶體。此時執行緒 2 的快取記憶體當中 i 的值還是 0,進行加 1 操作之後,i 的值為 1,然後執行緒 2 把 i 的值寫入記憶體。
最終結果 i 的值是 1,而不是 2 。這就是著名的 快取一致性問題 。通常稱這種被多個執行緒訪問的變數為 共享變數 。
也就是說,如果一個變數在多個 CPU 中都存在快取(一般在多執行緒程式設計時才會出現),那麼就可能存在 快取不一致 的問題。
為了解決快取不一致性問題,在 硬體層面 上通常來說有以下兩種解決方法:
1)通過在 匯流排加 LOCK# 鎖 的方式 (在軟體層面,效果等價於使用 synchronized 關鍵字);
2)通過 快取一致性協議 (在軟體層面,效果等價於使用 volatile 關鍵字)。
在早期的 CPU 當中,是通過在總線上加 LOCK# 鎖的形式來解決快取不一致的問題。因為 CPU 和其他部件進行通訊都是通過匯流排來進行的,如果對匯流排加 LOCK# 鎖的話,也就是說阻塞了其他 CPU 對其他部件訪問(如記憶體),從而使得只能有一個CPU能使用這個變數的記憶體。比如上面例子中, 如果一個執行緒在執行 i = i + 1,如果在執行這段程式碼的過程中,在總線上發出了 LCOK# 鎖的訊號,那麼只有等待這段程式碼完全執行完畢之後,其他 CPU 才能從變數 i 所在的記憶體讀取變數,然後進行相應的操作,這樣就解決了快取不一致的問題。但是上面的方式會有一個問題,由於在鎖住匯流排期間,其他 CPU 無法訪問記憶體,導致效率低下。
所以,就出現了 快取一致性協議 ,其中最出名的就是 Intel 的 MESI 協議。MESI 協議保證了每個快取中使用的共享變數的副本是一致的。它核心的思想是: 當 CPU 寫資料時,如果發現操作的變數是共享變數,即在其他 CPU 中也存在該變數的副本,會發出訊號通知其他 CPU 將該變數的快取行置為無效狀態。因此,當其他 CPU 需要讀取這個變數時,發現自己快取中快取該變數的快取行是無效的,那麼它就會從記憶體重新讀取。
二.併發程式設計中的三個概念
在併發程式設計中,我們通常會遇到以下三個問題: 原子性問題 , 可見性問題 和 有序性問題 。我們先看具體看一下這三個概念:
1、原子性
原子性: 即一個操作或者多個操作 要麼全部執行並且執行的過程不會被任何因素打斷,要麼就都不執行。
一個很經典的例子就是銀行賬戶轉賬問題:
比如從賬戶A向賬戶B轉1000元,那麼必然包括2個操作:從賬戶A減去1000元,往賬戶B加上1000元。
試想一下,如果這兩個操作不具備原子性,會造成什麼樣的後果。假如從賬戶 A 減去 1000 元之後,操作突然中止。然後又從 B 取出了 500 元,取出 500 元之後,再執行 往賬戶 B 加上 1000 元 的操作。這樣就會導致賬戶A雖然減去了 1000 元,但是賬戶 B 沒有收到這個轉過來的 1000 元。所以,這兩個操作必須要具備原子性才能保證不出現一些意外的問題。
同樣地,反映到併發程式設計中會出現什麼結果呢?
舉個最簡單的例子,大家想一下,假如為一個32位的變數賦值過程不具備原子性的話,會發生什麼後果?
i = 9;
假若一個執行緒執行到這個語句時,我們暫且假設為一個32位的變數賦值包括兩個過程:為低16位賦值,為高16位賦值。那麼就可能發生一種情況:當將低16位數值寫入之後,突然被中斷,而此時又有一個執行緒去讀取 i 的值,那麼讀取到的就是錯誤的資料,導致 資料不一致性 問題。
2、可見性
可見性 是指當多個執行緒訪問同一個共享變數時,一個執行緒修改了這個變數的值,其他執行緒能夠立即看得到修改的值。
舉個簡單的例子,看下面這段程式碼:
//執行緒1執行的程式碼
int i = 0;
i = 10;
//執行緒2執行的程式碼
j = i;
假若執行 執行緒1 的是 CPU1,執行 執行緒2 的是 CPU2。由上面的分析可知,當 執行緒1 執行 i = 10 這句時,會先把 i 的初始值載入到 CPU1 的快取記憶體中,然後賦值為10,那麼在 CPU1 的快取記憶體當中 i 的值變為 10 了,卻沒有立即寫入到主存當中。此時,執行緒2 執行 j = i,它會先去主存讀取 i 的值並載入到 CPU2 的快取當中,注意此時記憶體當中 i 的值還是 0,那麼就會使得 j 的值為 0,而不是 10。
這就是可見性問題,執行緒1 對變數 i 修改了之後,執行緒2 沒有立即看到 執行緒1 修改後的值。
3、有序性
有序性:即程式執行的順序按照程式碼的先後順序執行。舉個簡單的例子,看下面這段程式碼:
int i = 0;
boolean flag = false;
i = 1; //語句1
flag = true; //語句2
上面程式碼定義了一個 int型 變數,定義了一個 boolean型 變數,然後分別對兩個變數進行賦值操作。從程式碼順序上看,語句1 是在 語句2 前面的,那麼 JVM 在真正執行這段程式碼的時候會保證 語句1 一定會在 語句2 前面執行嗎?不一定,為什麼呢?這裡可能會發生 指令重排序(Instruction Reorder)。
下面解釋一下什麼是指令重排序,一般來說,處理器為了提高程式執行效率,可能會對輸入程式碼進行優化,它不保證程式中各個語句的執行先後順序同程式碼中的順序一致,但是它會保證程式最終執行結果和程式碼順序執行的結果是一致的(單執行緒情形下)。
比如上面的程式碼中,語句1 和 語句2 誰先執行對最終的程式結果並沒有影響,那麼就有可能在執行過程中, 語句2 先執行而 語句1 後執行。但是要注意,雖然處理器會對指令進行重排序,但是它會保證程式最終結果會和程式碼順序執行結果相同,那麼它靠什麼保證的呢?再看下面一個例子:
int a = 10; //語句1
int r = 2; //語句2
a = a + 3; //語句3
r = a*a; //語句4
這段程式碼有4個語句,那麼可能的一個執行順序是:
那麼可不可能是這個執行順序呢: 語句2 -> 語句1 -> 語句4 -> 語句3
答案是不可能,因為處理器在進行重排序時會考慮指令之間的 資料依賴性,如果一個指令 Instruction 2 必須用到 Instruction 1 的結果,那麼處理器會保證 Instruction 1 會在 Instruction 2 之前執行。
雖然 重排序不會影響單個執行緒內程式執行的結果,但是多執行緒呢?下面,看一個例子:
//執行緒1:
context = loadContext(); //語句1
inited = true; //語句2
//執行緒2:
while(!inited ){
sleep()
}
doSomethingwithconfig(context);
上面程式碼中,由於 語句1 和 語句2 沒有資料依賴性,因此可能會被重排序。假如發生了重排序,在 執行緒1 執行過程中先執行 語句2,而此時 執行緒2 會以為初始化工作已經完成,那麼就會跳出 while迴圈 ,去執行 doSomethingwithconfig(context) 方法,而此時 context 並沒有被初始化,就會導致程式出錯。
從上面可以看出,指令重排序不會影響單個執行緒的執行,但是會影響到執行緒併發執行的正確性。也就是說,要想使併發程式正確地執行,必須要保證原子性、可見性以及有序性。只要有一個沒有被保證,就有可能會導致程式執行不正確。
三. Java記憶體模型
在前面談到了一些關於記憶體模型以及併發程式設計中可能會出現的一些問題。下面我們來看一下 Java記憶體模型,研究一下 Java記憶體模型 為我們提供了哪些保證以及在 Java 中提供了哪些方法和機制來讓我們在進行多執行緒程式設計時能夠保證程式執行的正確性。
在 Java虛擬機器規範 中,試圖定義一種 Java記憶體模型(Java Memory Model,JMM) 來遮蔽各個硬體平臺和作業系統的記憶體訪問差異,以實現讓 Java 程式在各種平臺下都能達到一致的記憶體訪問效果。那麼,Java記憶體模型 規定了哪些東西呢,它定義了程式中變數的訪問規則,往大一點說是定義了程式執行的次序。注意,為了獲得較好的執行效能,Java記憶體模型並沒有限制執行引擎使用處理器的暫存器或者快取記憶體來提升指令執行速度,也沒有限制編譯器對指令進行重排序。也就是說,在 Java記憶體模型 中,也會存在快取一致性問題和指令重排序的問題。
Java記憶體模型 規定所有的變數都是存在主存當中(類似於前面說的實體記憶體),每個執行緒都有自己的工作記憶體(類似於前面的快取記憶體)。執行緒對變數的所有操作都必須在工作記憶體中進行,而不能直接對主存進行操作,並且每個執行緒不能訪問其他執行緒的工作記憶體。
舉個簡單的例子:在java中,執行下面這個語句:
i = 10;
執行執行緒必須先在自己的工作執行緒中對 變數i 所在的快取進行賦值操作,然後再寫入主存當中,而不是直接將數值10寫入主存當中。那麼,Java語言本身對原子性、可見性以及有序性 提供了哪些保證呢?
1、原子性
在 Java 中,對基本資料型別的變數的 讀取 和 賦值 操作是原子性操作,即這些操作是不可被中斷的 : 要麼執行,要麼不執行。
上面一句話雖然看起來簡單,但是理解起來並不是那麼容易。看下面一個例子,請分析以下哪些操作是原子性操作:
x = 10; //語句1
y = x; //語句2
x++; //語句3
x = x + 1; //語句4
乍一看,有些朋友可能會說上面的四個語句中的操作都是原子性操作。其實 只有 語句1 是原子性操作,其他三個語句都不是原子性操作。
語句1 是直接將數值 10 賦值給 x,也就是說執行緒執行這個語句的會直接將數值 10 寫入到工作記憶體中;
語句2 實際上包含兩個操作,它先要去讀取 x 的值,再將 x 的值寫入工作記憶體。雖然,讀取 x 的值以及 將 x 的值寫入工作記憶體這兩個操作都是原子性操作,但是合起來就不是原子性操作了;
同樣的,x++ 和 x = x+1 包括3個操作:讀取 x 的值,進行加 1 操作,寫入新的值。
所以,上面四個語句只有 語句1 的操作具備原子性。也就是說,只有簡單的讀取、賦值(而且必須是將數字賦值給某個變數,變數之間的相互賦值不是原子操作)才是原子操作。
不過,這裡有一點需要注意:在32位平臺下,對64位資料的讀取和賦值是需要通過兩個操作來完成的,不能保證其原子性。但是好像在最新的JDK中,JVM 已經保證對64位資料的讀取和賦值也是原子性操作了。
從上面可以看出,Java記憶體模型只保證了基本讀取和賦值是原子性操作,如果要實現更大範圍操作的原子性,可以通過 synchronized 和 Lock 來實現。由於 synchronized 和 Lock 能夠保證任一時刻只有一個執行緒執行該程式碼塊,那麼自然就不存在原子性問題了,從而保證了原子性。
2、可見性
對於可見性,Java 提供了 volatile關鍵字 來保證可見性。
當一個共享變數被 volatile 修飾時,它會保證修改的值會立即被更新到主存,當有其他執行緒需要讀取時,它會去記憶體中讀取新值。而普通的共享變數不能保證可見性,因為普通共享變數被修改之後,什麼時候被寫入主存是不確定的,當其他執行緒去讀取時,此時記憶體中可能還是原來的舊值,因此無法保證可見性。
另外,通過 synchronized 和 Lock 也能夠保證可見性,synchronized 和 Lock 能保證同一時刻只有一個執行緒獲取鎖然後執行同步程式碼,並且 在釋放鎖之前會將對變數的修改重新整理到主存當中,因此可以保證可見性。
3、有序性
在 Java記憶體模型中,允許編譯器和處理器對指令進行重排序,但是重排序過程不會影響到單執行緒程式的執行,卻會影響到多執行緒併發執行的正確性。
在 Java 中,可以通過 volatile 關鍵字來保證一定的“有序性”(具體原理在下一節講述)。另外,我們千萬不能想當然地認為,可以通過synchronized 和 Lock 來保證有序性,也就是說,不能由於 synchronized 和 Lock 可以讓執行緒序列執行同步程式碼,就說它們可以保證指令不會發生重排序,這根本不是一個粒度的問題。
另外,Java記憶體模型具備一些先天的“有序性”,即不需要通過任何手段就能夠得到保證的有序性,這個通常也稱為 happens-before 原則。如果兩個操作的執行次序無法從happens-before原則推匯出來,那麼它們就不能保證它們的有序性,虛擬機器可以隨意地對它們進行重排序。
下面就來具體介紹下 happens-before原則(先行發生原則):
程式次序規則:一個執行緒內,按照程式碼順序,書寫在前面的操作先行發生於書寫在後面的操作;
鎖定規則:一個unLock操作先行發生於後面對同一個鎖額lock操作;
volatile 變數規則:對一個變數的寫操作先行發生於後面對這個變數的讀操作;
傳遞規則:如果操作 A 先行發生於操作 B,而操作 B 又先行發生於操作 C,則可以得出操作 A 先行發生於操作 C ;
執行緒啟動規則:Thread物件的start()方法先行發生於此執行緒的每個一個動作;
執行緒中斷規則:對執行緒interrupt()方法的呼叫先行發生於被中斷執行緒的程式碼檢測到中斷事件的發生;
執行緒終結規則:執行緒中所有的操作都先行發生於執行緒的終止檢測,我們可以通過Thread.join()方法結束、Thread.isAlive()的返回值手段檢測到執行緒已經終止執行;
物件終結規則:一個物件的初始化完成先行發生於他的finalize()方法的開始。
這八條原則摘自《深入理解Java虛擬機器》。這八條規則中,前四條規則是比較重要的,後四條規則都是顯而易見的。下面我們來解釋一下前四條規則:
對於程式次序規則來說,我的理解就是一段程式程式碼的執行在單個執行緒中看起來是有序的。注意,雖然這條規則中提到“書寫在前面的操作先行發生於書寫在後面的操作”,這個應該是程式看起來執行的順序是按照程式碼順序執行的,因為虛擬機器可能會對程式程式碼進行指令重排序。雖然進行重排序,但是最終執行的結果是與程式順序執行的結果一致的,它只會對不存在資料依賴性的指令進行重排序。因此,在單個執行緒中,程式執行看起來是有序執行的,這一點要注意理解。事實上,這個規則是用來保證程式在單執行緒中執行結果的正確性,但無法保證程式在多執行緒中執行的正確性。
第二條規則也比較容易理解,也就是說無論在單執行緒中還是多執行緒中,同一個鎖如果出於被鎖定的狀態,那麼必須先對鎖進行了釋放操作,後面才能繼續進行 lock 操作。
第三條規則是一條比較重要的規則,也是後文將要重點講述的內容。直觀地解釋就是,如果一個執行緒先去寫一個變數,然後一個執行緒去進行讀取,那麼寫入操作肯定會先行發生於讀操作。
第四條規則實際上就是體現 happens-before 原則具備傳遞性。
四.深入剖析 volatile 關鍵字
1、volatile關鍵字的兩層語義
一旦一個共享變數(類的成員變數、類的靜態成員變數)被 volatile 修飾後,那麼就具備了兩層語義:
1)保證了不同執行緒對共享變數進行操作時的可見性,即一個執行緒修改了某個變數的值,這個新值對其他執行緒來說是 立即可見 的;
2)禁止進行指令重排序。
先看一段程式碼,假如 執行緒1 先執行,執行緒2 後執行:
//執行緒1
boolean stop = false;
while(!stop){
doSomething();
}
//執行緒2
stop = true;
這段程式碼是很典型的一段程式碼,很多人在中斷執行緒時可能都會採用這種標記辦法。但是事實上,這段程式碼會完全執行正確麼?即一定會將執行緒中斷麼?不一定,也許在大多數時候,這個程式碼能夠把執行緒中斷,但是也有可能會導致無法中斷執行緒(雖然這個可能性很小,但是隻要一旦發生這種情況就會造成死迴圈了)。
下面解釋一下這段程式碼為何有可能導致無法中斷執行緒。在前面已經解釋過,如上圖所示,每個執行緒在執行過程中都有自己的工作記憶體,那麼 執行緒1 在執行的時候,會將 stop 變數的值拷貝一份放在自己的工作記憶體當中。那麼,當 執行緒2 更改了 stop變數 的值之後,可能會出現以下兩種情形:
執行緒2 對變數的修改沒有立即刷入到主存當中;
即使 執行緒2 對變數的修改立即反映到主存中,執行緒1 也可能由於沒有立即知道 執行緒2 對stop變數的更新而一直迴圈下去。
這兩種情形都會導致 執行緒1 處於死迴圈。但是,用 volatile關鍵字 修飾後就變得不一樣了,如下圖所示:
① 使用 volatile 關鍵字會強制將修改的值立即寫入主存;
② 使用 volatile 關鍵字的話,當 執行緒2 進行修改時,會導致 執行緒1 的工作記憶體中快取變數stop的快取行無效(反映到硬體層的話,就是CPU的 L1 或者 L2 快取中對應的快取行無效);
③ 由於 執行緒1 的工作記憶體中快取變數stop的快取行無效,所以,執行緒1 再次讀取變數stop的值時會去主存讀取。
綜上,在 執行緒2 修改 stop 值時(當然這裡包括兩個操作,修改 執行緒2 工作記憶體中的值,然後將修改後的值寫入記憶體),會使得 執行緒1 的工作記憶體中快取變數 stop 的快取行無效,然後 執行緒1 讀取時,會發現自己的快取行無效從而去對應的主存讀取最新的值 。簡化一下,通過使用 volatile 關鍵字,如下圖所示,執行緒會及時將變數的新值更新到主存中,並且保證其他執行緒能夠立即讀到該值。這樣,執行緒1 讀取到的就是最新的、正確的值。
下面通過兩個例子更好地瞭解關鍵字 volatile 的作用。下面先看 示例1:
//資源類
class MyList {
// 臨界資源
private List list = new ArrayList();
// 對臨界資源的訪問
public void add() {
list.add("rico");
}
public int size() {
return list.size();
}
}
// 執行緒B
class ThreadB extends Thread {
private MyList list;
public ThreadB(MyList list) {
super();
this.list = list;
}
@Override
public void run() { // 任務 B
try {
while (true) {
if (list.size() == 2) {
System.out.println("list中的元素個數為2了,執行緒b要退出了!");
throw new InterruptedException();
}
}
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
// 執行緒A
class ThreadA extends Thread {
private MyList list;
public ThreadA(MyList list) {
super();
this.list = list;
}
@Override
public void run() { // 任務 A
try {
for (int i = 0; i < 3; i++) {
list.add();
System.out.println("添加了" + (i + 1) + "個元素");
Thread.sleep(1000);
}
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
// 測試
public class Test {
public static void main(String[] args) {
MyList service = new MyList();
ThreadA a = new ThreadA(service);
a.setName("A");
a.start();
ThreadB b = new ThreadB(service);
b.setName("B");
b.start();
}
}
執行結果如下所示:
第一個執行結果是在沒有使用volatile關鍵字的情況下產生的,第二個執行結果是在使用volatile關鍵字的情況下產生的。
特別地,博友 qq_27571221(王小軍08)提到, “若將 類ThreadA 中的 run()方法中的 Thread.sleep(1000);去掉,上述兩種執行結果都有可能出現。”事實上,之所以會出現這種情況,究其根本,是由執行緒獲得CPU執行的不確定性引起的。也就是說,在使用volatile關鍵字修飾共享變數list的前提下,去掉程式碼Thread.sleep(1000);後,之所以也會出現第一種執行結果是因為存在這樣一種情形:執行緒A 早已執行結束但執行緒B才剛剛開始執行或尚未開始執行,即序列執行的情形。總的來說,在類ThreadA 中的 run()方法中新增 Thread.sleep(1000);的原因就是 為了保證執行緒A、B 能交替執行,防止上述情形的出現。在此,感謝博友 qq_27571221(王小軍08)積極參與本問題的討論。
示例2:
public class TestVolatile {
public static void main(String[] args) {
ThreadDemo td = new ThreadDemo();
new Thread(td, "ThreadDemo").start();
while (true) {
// 加上下面三句程式碼的任意一句,程式都會正常結束:
// System.out.println("!!"); //...語句1
// synchronized (TestVolite.class) {} //...語句2
//TestVolite.test2(); //...語句3
// 若只加上下面一句程式碼,程式都會死迴圈:
// TestVolite.test1(); //...語句4
if (td.flag) {
System.out.println("執行緒 " + Thread.currentThread().getName()
+ " 即將跳出while迴圈體... ");
break;
}
}
}
public static void test1() {}
public synchronized static void test2() {}
}
class ThreadDemo implements Runnable {
public boolean flag = false;
@Override
public void run() {
try {
Thread.sleep(2000);
} catch (InterruptedException e) {
}
flag = true;
System.out.println("執行緒 " + Thread.currentThread().getName() + " 執行完畢: "
+ "置 flag= " + flag + " ...");
}
}
上述程式執行結果如下圖:
下面對該程式分以下 5 種情形進行修改並討論,如下所示:
- Case 1:只用 volatile 關鍵字修飾 類ThreadDemo 中的共享變數 flag
- 執行結果為:
- Case 2:只取消對語句1的註釋
- 執行結果為:
- Case 3:只取消對語句2的註釋
- 執行結果為:
- Case 4:只取消對語句3的註釋
- 執行結果為:
- Case 5:只取消對語句4的註釋
- 執行結果為:
關於上面五種情形,情形1 和 情形5 很容易理解,此不贅述。
但是,對於上面的 第 2、3、4 三種情形,可能有很多朋友就不能理解了,特別是 第2種情形。其實,這三種情形都反映了一個問題:在我們不使用 volatile 關鍵字修飾共享變數去保證其可見性時,那麼執行緒是不是始終一直從自己的工作記憶體中讀取變數的值呢? 什麼情況下,執行緒工作記憶體中的變數值才會與主存中的同步並取得一致狀態呢?
事實上,除了 volatile 可以保證記憶體可見性外,synchronized 也可以保證可見性,因為每次執行synchronized塊 或者 synchronized方法都會導致執行緒工作記憶體與主存的同步,使得其他執行緒可以取得共享變數的最新值。也就是說,synchronized 語義範圍不但包括 volatile 具有的可見性,也包括原子性,但不能禁止指令重排序,這是二者一個功能上的差異。說到這裡,朋友應該就理解了 情形3 和 情形4 了。但是,情形2 怎麼也會導致類似於 情形3 和 情形4 的效果呢? 因為 System.out.println() 方法裡面包含 synchronized塊, 我們看完它的原始碼就大徹大悟了,如下:
public void println(String x) {
synchronized (this) { // synchronized 塊
print(x);
newLine();
}
}
在此,特別感謝CSDN博友 Geek-k(u010395144) 所提出的問題,是他的提問,我才能更好的詮釋這個問題,更好的提升自己,更好的幫助更多的朋友。更多關於 synchronized關鍵字 的介紹請移步我的另一篇博文《Java 併發:內建鎖 Synchronized》。更多關於 Java多執行緒 方面的知識請移步我的專欄《Java併發程式設計學習筆記》。
2、volatile 保證原子性嗎?
從上面知道, volatile 關鍵字保證了操作的可見性,但是 volatile 能保證對變數的操作是原子性嗎?
下面看一個例子:
//執行緒類
class MyThread extends Thread {
// volatile 共享靜態變數,類成員
public volatile static int count;
private static void addCount() {
for (int i = 0; i < 100; i++) {
count++;
}
System.out.println("count=" + count);
}
@Override
public void run() {
addCount();
}
}
//測試類
public class Run {
public static void main(String[] args) {
//建立 100個執行緒並啟動
MyThread[] mythreadArray = new MyThread[100];
for (int i = 0; i < 100; i++) {
mythreadArray[i] = new MyThread();
}
for (int i = 0; i < 100; i++) {
mythreadArray[i].start();
}
}
}/* Output(迴圈):
... ...
count=9835
*///:~
大家想一下這段程式的輸出結果是多少?也許有些朋友認為是 10000。但是事實上執行它會發現每次執行結果都不一致,都是一個 小於 10000 的數字。可能有的朋友就會有疑問,不對啊,上面是對變數 count 進行自增操作,由於 volatile 保證了可見性,那麼在每個執行緒中對 count 自增完之後,在其他執行緒中都能看到修改後的值啊,所以有 100個 執行緒分別進行了 100 次操作,那麼最終 count 的值應該是 100*100=10000。
這裡面就有一個誤區了,volatile 關鍵字能保證可見性沒有錯,但是上面的程式錯在沒能保證原子性。可見性只能保證每次讀取的是最新的值,但是 volatile 沒辦法保證對變數的操作的原子性。在前面已經提到過,自增操作是不具備原子性的,它包括 讀取變數的原始值、進行加1操作 和 寫入工作記憶體 三個原子操作。那麼就是說,這三個子操作可能會分割開執行,所以就有可能導致下面這種情況出現:
假如某個時刻 變數count 的值為 10,執行緒1 對變數進行自增操作,執行緒1 先讀取了 變數count 的原始值,然後 執行緒1 被阻塞了;然後,執行緒2 對變數進行自增操作,執行緒2 也去讀取 變數count 的原始值,由於 執行緒1 只是對 變數count 進行讀取操作,而沒有對變數進行修改操作,所以不會導致 執行緒2 的工作記憶體中快取變數 count 的快取行無效,所以 執行緒2 會直接去主存讀取 count的值 ,發現 count 的值是 10,然後進行加 1 操作。注意,此時 執行緒2 只是執行了 count + 1 操作,還沒將其值寫到 執行緒2 的工作記憶體中去!此時執行緒2 被阻塞,執行緒1 進行加 1 操作時,注意運算元count仍然是 10!然後,執行緒2 把 11 寫入工作記憶體並刷到主記憶體。雖然此時 執行緒1 能感受到 執行緒2 對count的修改,但由於執行緒1只剩下對count的寫操作了,而不必對count進行讀操作了,所以此時 執行緒2 對count的修改並不能影響到 執行緒1。於是,執行緒1 也將 11 寫入工作記憶體並刷到主記憶體。也就是說,兩個執行緒分別進行了一次自增操作後,count 只增加了 1。下圖演示了這種情形:
進一步地,將上述程式碼修改成下面示例的樣子以後,這個問題就迎刃而解:
//執行緒類
class MyThread extends Thread {
// 既然使用 synchronized關鍵字 ,就沒必要使用 volatile關鍵字了
public static int count;
//注意必須新增 static 關鍵字,這樣synchronized 與 static 鎖的就是 Mythread.class 物件了,
//也就達到同步效果了
private synchronized static void addCount() {
for (int i = 0; i < 100; i++) {
count++;
}
System.out.println("count=" + count);
}
@Override
public void run() {
addCount();
}
}
//測試類
public class Run {
public static void main(String[] args) {
//建立 100個執行緒並啟動
MyThread[] mythreadArray = new MyThread[100];
for (int i = 0; i < 100; i++) {
mythreadArray[i] = new MyThread();
}
for (int i = 0; i < 100; i++) {
mythreadArray[i].start();
}
}
}
使用 Lock 和 Java 1.5 所提供的 java.util.concurrent.atomic 包來保證執行緒安全性將在後面的博文中進行介紹。
五. 使用 volatile 關鍵字的場景
synchronized 關鍵字是防止多個執行緒同時執行一段程式碼,那麼就會很影響程式執行效率;而 volatile 關鍵字在某些情況下效能要優於 synchronized,但是要注意 volatile 關鍵字是無法替代 synchronized 關鍵字的,因為 volatile 關鍵字無法保證操作的原子性。通常來說,使用 volatile 必須具備以下兩個條件:
1)對變數的寫操作不依賴於當前值;
2)該變數沒有包含在具有其他變數的不變式中。
實際上,這些條件表明,可以被寫入 volatile 變數的這些有效值 獨立於任何程式的狀態,包括變數的當前狀態。事實上,上面的兩個條件就是保證對 該volatile變數 的操作是原子操作,這樣才能保證使用 volatile關鍵字 的程式在併發時能夠正確執行。
特別地,關鍵字 volatile 主要使用的場合是:
在多執行緒環境下及時感知共享變數的修改,並使得其他執行緒可以立即得到變數的最新值。
1、狀態標記量
// 示例 1
volatile boolean flag = false;
while(!flag){
doSomething();
}
public void setFlag() {
flag = true;
}
// 示例 2
volatile boolean inited = false;
//執行緒1:
context = loadContext();
inited = true;
//執行緒2:
while(!inited ){
sleep()
}
doSomethingwithconfig(context);
更多關於 volatile 在狀態標記量方面的應用,請移步我的博文《Java 併發:執行緒間通訊與協作》。
2、Double-Check (雙重檢查)
class Singleton{
private volatile static Singleton instance = null;
private Singleton() {
}
public static Singleton getInstance() {
if(instance==null) {
synchronized (Singleton.class) {
if(instance==null)
instance = new Singleton();
}
}
return instance;
}
}
更多關於 Double-Check (雙重檢查)的定義與應用場景 的介紹,請移步我的博文《徹頭徹尾理解單例模式與多執行緒》。
六. 小結
關鍵字volatile 與記憶體模型緊密相關,是執行緒同步的輕量級實現,其效能要比 synchronized關鍵字 好。在作用物件和作用範圍上, volatile 用於修飾變數,而 synchronized關鍵字 用於修飾方法和程式碼塊,而且 synchronized 語義範圍不但包括 volatile擁有的可見性,還包括volatile 所不具有的原子性,但不包括 volatile 擁有的有序性,即允許指令重排序。因此,在多執行緒環境下,volatile關鍵字 主要用於及時感知共享變數的修改,並保證其他執行緒可以及時得到變數的最新值。可用以下文氏圖表示 synchronized 和 volatile語義範圍:
更多關於 synchronized關鍵字 的介紹請移步我的另一篇博文《Java 併發:內建鎖 Synchronized》。
更多關於 Java多執行緒 方面的知識請移步我的專欄《Java併發程式設計學習筆記》。
更多關於 Double-Check (雙重檢查)的定義與應用場景 的介紹,請移步我的博文《徹頭徹尾理解單例模式與多執行緒》。
更多關於 volatile 在狀態標記量方面的應用,請移步我的博文《Java 併發:執行緒間通訊與協作》。
七. 鳴謝
特別感謝 Geek-k(u010395144) 和 qq_27571221(王小軍08) 兩位CSDN博友對本文章的關注與積極討論,同時感謝其他朋友對有關內容的關注。