Java volatile关键字
Java 語言中的volatile變量可以被看作是一種“程度較輕的synchronized”,與synchronized相比,volatile變量所需的編碼較少,并且運行時開銷也較少,但是它所能實現(xiàn)的功能也僅是synchronized的一部分。本文介紹了幾種有效使用volatile變量的模式,并強調(diào)了幾種不適合使用 volatile 變量的情形。
鎖提供了兩種主要特性:互斥(mutual exclusion)和可見性(visibility)?;コ饧匆淮沃辉试S一個線程持有某個特定的鎖,因此可使用該特性實現(xiàn)對共享數(shù)據(jù)的協(xié)調(diào)訪問協(xié)議,這樣,一次就只有一個線程能夠使用該共享數(shù)據(jù)??梢娦砸訌?fù)雜一些,它必須確保釋放鎖之前對共享數(shù)據(jù)做出的更改對于隨后獲得該鎖的另一個線程是可見的,如果沒有同步機制提供的這種可見性保證,線程看到的共享變量可能是修改前的值或不一致的值,這將引發(fā)許多嚴(yán)重問題。
volatile變量
volatile變量具有synchronized的可見性特性,但是不具備原子特性。這就是說線程能夠自動發(fā)現(xiàn)volatile變量的最新值。volatile 變量可用于提供線程安全,但是只能應(yīng)用于非常有限的一組用例:多個變量之間或者某個變量的當(dāng)前值與修改后值之間沒有約束。因此,單獨使用volatile還不足以實現(xiàn)計數(shù)器、互斥鎖或任何具有與多個變量相關(guān)的不變式(Invariants)的類(例如:start <=end)。
出于簡易性或可伸縮性的考慮,您可能傾向于使用volatile 變量而不是鎖。當(dāng)使用volatile變量而非鎖時,某些習(xí)慣用法(idiom)更加易于編碼和閱讀。此外,volatile 變量不會像鎖那樣造成線程阻塞,因此也很少造成可伸縮性問題。在某些情況下,如果讀操作遠遠大于寫操作,volatile 變量還可以提供優(yōu)于鎖的性能優(yōu)勢。(volatile類型變量并不會被重排序,也不會被緩存,每次都會從內(nèi)存中獲取最新值)
正確使用volatile變量的條件
您只能在有限的一些情形下使用volatile變量替代鎖。要使volatile變量提供理想的線程安全,必須同時滿足下面兩個條件:
- 對變量的寫操作不依賴于當(dāng)前值
- 該變量沒有包含在具有其他變量的不變式中
實際上,這些條件表明,可以被寫入volatile變量的這些有效值獨立于任何程序的狀態(tài),包括變量的當(dāng)前狀態(tài)。
第一個條件的限制使volatile 變量不能用作線程安全計數(shù)器。雖然增量操作(x++)看上去類似一個單獨操作,實際上它是一個由讀取-修改-寫入操作序列組成的組合操作,必須以原子方式執(zhí)行,而volatile不能提供必須的原子特性。實現(xiàn)正確的操作需要使x的值在操作期間保持不變,而volatile變量無法實現(xiàn)這點。(然而,如果將值調(diào)整為只從單個線程寫入,那么可以忽略第一個條件)
大多數(shù)編程情形都會與這兩個條件的其中之一沖突,使得volatile變量不能像synchronized那樣普遍適用于實現(xiàn)線程安全。清單 1 顯示了一個非線程安全的數(shù)值范圍類。它包含了一個不變式:下界總是小于或等于上界。
清單 1.非線程安全的數(shù)值范圍類
這種方式限制了范圍的狀態(tài)變量,因此將lower和upper字段定義為volatile類型不能夠充分實現(xiàn)類的線程安全;從而仍然需要使用同步。否則,如果湊巧兩個線程在同一時間使用不一致的值執(zhí)行setLower和setUpper的話,則會使范圍處于不一致的狀態(tài)。例如,如果初始狀態(tài)是0,5),同一時間內(nèi),線程A調(diào)用setLower(4)并且線程B調(diào)用setUpper(3),顯然這兩個操作交叉存入的值是不符合條件的,那么兩個線程都會通過用于保護不變式的檢查,使得最后的范圍值是(4,3)——一個無效值。至于針對范圍的其他操作,我們需要使setLower()和setUpper()操作原子化——而將字段定義為volatile類型是無法實現(xiàn)這一目的的。
性能考慮
使用volatile變量的主要原因是其簡易性:在某些情形下,使用volatile變量要比使用相應(yīng)的鎖簡單得多。使用volatile變量次要原因是其性能:某些情況下volatile變量同步機制的性能要優(yōu)于鎖。
很難做出準(zhǔn)確、全面的評價,例如:“X總是比Y快”,尤其是對JVM 內(nèi)在的操作而言。(例如,某些情況下VM 也許能夠完全刪除鎖機制,這使得我們難以抽象地比較volatile和synchronized的開銷。)就是說,在目前大多數(shù)的處理器架構(gòu)上,volatile讀操作開銷非常低——幾乎和非volatile讀操作一樣。而volatile寫操作的開銷要比非 volatile寫操作多很多,因為要保證可見性需要實現(xiàn)內(nèi)存界定(Memory Fence),即便如此,volatile的總開銷仍然要比鎖獲取低。
volatile操作不會像鎖一樣造成阻塞,因此,在能夠安全使用volatile的情況下,volatile可以提供一些優(yōu)于鎖的可伸縮特性。如果讀操作的次數(shù)要遠遠超過寫操作,與鎖相比,volatile 變量通常能夠減少同步的性能開銷。
正確使用volatile的模式
很多并發(fā)性專家事實上往往引導(dǎo)用戶遠離volatile變量,因為使用它們要比使用鎖更加容易出錯。然而,如果謹(jǐn)慎地遵循一些良好定義的模式,就能夠在很多場合內(nèi)安全地使用 volatile變量。要始終牢記使用volatile的限制——只有在狀態(tài)真正獨立于程序內(nèi)其他內(nèi)容時才能使用volatile——這條規(guī)則能夠避免將這些模式擴展到不安全的用例。
模式 #1:狀態(tài)標(biāo)志
也許實現(xiàn)volatile變量的規(guī)范使用僅僅是使用一個布爾狀態(tài)標(biāo)志,用于指示發(fā)生了一個重要的一次性事件,例如完成初始化或請求停機。
很多應(yīng)用程序包含了一種控制結(jié)構(gòu),形式為“在還沒有準(zhǔn)備好停止程序時再執(zhí)行一些工作”,如清單 2 所示:
清單 2.將volatile變量作為狀態(tài)標(biāo)志位使用
volatile boolean shutdownRequested;...public void shutdown() { shutdownRequested = true; }public void doWork() { while (!shutdownRequested) { // do stuff} }很可能會從循環(huán)外部調(diào)用shutdown()方法——即在另一個線程中——因此,需要執(zhí)行某種同步來確保正確實現(xiàn)shutdownRequested變量的可見性。(可能會從 JMX 偵聽程序、GUI 事件線程中的操作偵聽程序、通過 RMI 、通過一個 Web 服務(wù)等調(diào)用)。然而,使用synchronized塊編寫循環(huán)要比使用清單 2 所示的volatile狀態(tài)標(biāo)志編寫麻煩很多。由于volatile簡化了編碼,并且狀態(tài)標(biāo)志并不依賴于程序內(nèi)任何其他狀態(tài),因此此處非常適合使用volatile。
這種類型的狀態(tài)標(biāo)記的一個公共特性是:通常只有一種狀態(tài)轉(zhuǎn)換;shutdownRequested標(biāo)志從false轉(zhuǎn)換為true,然后程序停止。這種模式可以擴展到來回轉(zhuǎn)換的狀態(tài)標(biāo)志,但是只有在轉(zhuǎn)換周期不被察覺的情況下才能擴展(從false到true,再轉(zhuǎn)換到false)。此外,還需要某些原子狀態(tài)轉(zhuǎn)換機制,例如原子變量。
模式 #2:一次性安全發(fā)布
缺乏同步會導(dǎo)致無法實現(xiàn)可見性,這使得確定何時寫入對象引用而不是原語值變得更加困難。在缺乏同步的情況下,可能會遇到某個對象引用的更新值(由另一個線程寫入)和該對象狀態(tài)的舊值同時存在。(這就是造成著名的雙重檢查鎖定(double-checked-locking)問題的根源,其中對象引用在沒有同步的情況下進行讀操作,產(chǎn)生的問題是您可能會看到一個更新的引用,但是仍然會通過該引用看到不完全構(gòu)造的對象)。
實現(xiàn)安全發(fā)布對象的一種技術(shù)就是將對象引用定義為volatile類型。清單 3 展示了一個示例,其中后臺線程在啟動階段從數(shù)據(jù)庫加載一些數(shù)據(jù)。其他代碼在能夠利用這些數(shù)據(jù)時,在使用之前將檢查這些數(shù)據(jù)是否曾經(jīng)發(fā)布過。
清單 3.將volatile變量用作一次性安全發(fā)布
如果theFlooble引用不是volatile類型,doWork()中的代碼在解除對theFlooble的引用時,將會得到一個不完全構(gòu)造的Flooble。
該模式的一個必要條件是:被發(fā)布的對象必須是線程安全的,或者是有效的不可變對象(有效不可變意味著對象的狀態(tài)在發(fā)布之后永遠不會被修改)。volatile類型的引用可以確保對象的發(fā)布形式的可見性,但是如果對象的狀態(tài)在發(fā)布后將發(fā)生更改,那么就需要額外的同步。
模式 #3:獨立觀察
安全使用volatile的另一種簡單模式是:定期“發(fā)布”觀察結(jié)果供程序內(nèi)部使用。例如,假設(shè)有一種環(huán)境傳感器能夠感覺環(huán)境溫度。一個后臺線程可能會每隔幾秒讀取一次該傳感器,并更新包含當(dāng)前文檔的volatile變量。然后,其他線程可以讀取這個變量,從而隨時能夠看到最新的溫度值。
使用該模式的另一種應(yīng)用程序就是收集程序的統(tǒng)計信息。清單 4 展示了身份驗證機制如何記憶最近一次登錄的用戶的名字。將反復(fù)使用lastUser引用來發(fā)布值,以供程序的其他部分使用。
清單 4.將volatile變量用于多個獨立觀察結(jié)果的發(fā)布
該模式是前面模式的擴展;將某個值發(fā)布以在程序內(nèi)的其他地方使用,但是與一次性事件的發(fā)布不同,這是一系列獨立事件。這個模式要求被發(fā)布的值是有效不可變的 —— 即值的狀態(tài)在發(fā)布后不會更改。使用該值的代碼需要清楚該值可能隨時發(fā)生變化。
模式 #4:"volatile bean"模式
volatile bean模式適用于將JavaBeans作為“榮譽結(jié)構(gòu)”使用的框架。在volatile bean模式中,JavaBean被用作一組具有g(shù)etter和/或setter方法的獨立屬性的容器。volatile bean模式的基本原理是:很多框架為易變數(shù)據(jù)的持有者(例如HttpSession)提供了容器,但是放入這些容器中的對象必須是線程安全的。
在volatile bean模式中,JavaBean的所有數(shù)據(jù)成員都是volatile類型的,并且getter和setter方法必須非常普通——除了獲取或設(shè)置相應(yīng)的屬性外,不能包含任何邏輯。此外,對于對象引用的數(shù)據(jù)成員,引用的對象必須是有效不可變的。(這將禁止具有數(shù)組值的屬性,因為當(dāng)數(shù)組引用被聲明為volatile時,只有引用而不是數(shù)組本身具有volatile語義)。對于任何volatile變量,不變式或約束都不能包含JavaBean屬性。清單 5 中的示例展示了遵守volatile bean模式的JavaBean:
清單 5.遵守volatile bean模式的Person對象
volatile的高級模式
前面幾節(jié)介紹的模式涵蓋了大部分的基本用例,在這些模式中使用volatile非常有用并且簡單。這一節(jié)將介紹一種更加高級的模式,在該模式中,volatile將提供性能或可伸縮性優(yōu)勢。
volatile應(yīng)用的的高級模式非常脆弱。因此,必須對假設(shè)的條件仔細證明,并且這些模式被嚴(yán)格地封裝了起來,因為即使非常小的更改也會損壞您的代碼!同樣,使用更高級的 volatile用例的原因是它能夠提升性能,確保在開始應(yīng)用高級模式之前,真正確定需要實現(xiàn)這種性能獲益。需要對這些模式進行權(quán)衡,放棄可讀性或可維護性來換取可能的性能收益——如果您不需要提升性能(或者不能夠通過一個嚴(yán)格的測試程序證明您需要它),那么這很可能是一次糟糕的交易,因為您很可能會得不償失,換來的東西要比放棄的東西價值更低。
模式 #5:開銷較低的讀 - 寫鎖策略
目前為止,您應(yīng)該了解了volatile的功能還不足以實現(xiàn)計數(shù)器。因為++x實際上是三種操作(讀、添加、存儲)的簡單組合,如果多個線程湊巧試圖同時對volatile計數(shù)器執(zhí)行增量操作,那么它的更新值有可能會丟失。
然而,如果讀操作遠遠超過寫操作,您可以結(jié)合使用內(nèi)部鎖和volatile變量來減少公共代碼路徑的開銷。清單 6 中顯示的線程安全的計數(shù)器使用synchronized確保增量操作是原子的,并使用volatile保證當(dāng)前結(jié)果的可見性。如果更新不頻繁的話,該方法可實現(xiàn)更好的性能,因為讀路徑的開銷僅僅涉及 volatile 讀操作,這通常要優(yōu)于一個無競爭的鎖獲取的開銷。
清單 6.結(jié)合使用volatile和synchronized實現(xiàn)“開銷較低的讀 - 寫鎖”
之所以將這種技術(shù)稱之為“開銷較低的讀-寫鎖”是因為您使用了不同的同步機制進行讀寫操作。因為本例中的寫操作違反了使用volatile的第一個條件,因此不能使用volatile安全地實現(xiàn)計數(shù)器——您必須使用鎖。然而,您可以在讀操作中使用volatile確保當(dāng)前值的可見性,因此可以使用鎖進行所有變化的操作,使用volatile進行只讀操作。其中,鎖一次只允許一個線程訪問值,volatile允許多個線程執(zhí)行讀操作,因此當(dāng)使用volatile保證讀代碼路徑時,要比使用鎖執(zhí)行全部代碼路徑獲得更高的共享度——就像讀-寫操作一樣。然而,要隨時牢記這種模式的弱點:如果超越了該模式的最基本應(yīng)用,結(jié)合這兩個競爭的同步機制將變得非常困難。
結(jié)束語
與鎖相比,volatile變量是一種非常簡單但同時又非常脆弱的同步機制,它在某些情況下將提供優(yōu)于鎖的性能和伸縮性。如果嚴(yán)格遵循volatile的使用條件——即變量真正獨立于其他變量和自己以前的值——在某些情況下可以使用volatile代替synchronized來簡化代碼。然而,使用volatile的代碼往往比使用鎖的代碼更加容易出錯。本文介紹的模式涵蓋了可以使用volatile代替synchronized的最常見的一些用例。遵循這些模式(注意使用時不要超過各自的限制)可以幫助您安全地實現(xiàn)大多數(shù)用例,使用volatile變量獲得更佳性能。
?
轉(zhuǎn)自:http://www.ibm.com/developerworks/cn/java/j-jtp06197.html
?
轉(zhuǎn)載于:https://www.cnblogs.com/sean-zou/archive/2013/04/16/3710071.html
總結(jié)
以上是生活随笔為你收集整理的Java volatile关键字的全部內(nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: Terasoluna(中文)
- 下一篇: 【电信增值业务学习笔记】3 语音类增值业