在并發(fā)編程中藤巢,我們通常會遇到以下三個問題:原子性問題剂习,可見性問題,有序性問題。
synchronized: 具有原子性业栅,有序性和可見性冈欢;
volatile:具有有序性和可見性
一歉铝、原子性
即一個操作或者多個操作,要么全部執(zhí)行并且執(zhí)行的過程不會被任何因素打斷凑耻,要么就都不執(zhí)行太示。原子性就像數(shù)據(jù)庫里面的事務(wù)一樣,他們是一個團(tuán)隊香浩,同生共死类缤。
一個很經(jīng)典的例子就是銀行賬戶轉(zhuǎn)賬問題:比如從賬戶A向賬戶B轉(zhuǎn)1000元,那么必然包括2個操作:從賬戶A減去1000元邻吭,往賬戶B加上1000元餐弱。試想一下,如果這2個操作不具備原子性囱晴,會造成什么樣的后果膏蚓。假如從賬戶A減去1000元之后,操作突然中止速缆。然后又從B取出了500元降允,取出500元之后,再執(zhí)行 往賬戶B加上1000元 的操作艺糜。這樣就會導(dǎo)致賬戶A雖然減去了1000元剧董,但是賬戶B沒有收到這個轉(zhuǎn)過來的1000元幢尚。
所以這2個操作必須要具備原子性才能保證不出現(xiàn)一些意外的問題。同樣地反映到并發(fā)編程中會出現(xiàn)什么結(jié)果呢翅楼?舉一個簡單的例子:
i = 0; //1
j = i ; //2
i++; //3
i = j + 1; //4
上面四個操作尉剩,有哪個幾個是原子操作,那幾個不是毅臊?如果不是很理解理茎,可能會認(rèn)為都是原子性操作,其實只有1才是原子操作管嬉,其余均不是皂林。
1在Java中,對基本數(shù)據(jù)類型的變量和賦值操作都是原子性操作蚯撩;
2中包含了兩個操作:讀取i础倍,將i值賦值給j
3中包含了三個操作:讀取i值、i + 1 胎挎、將+1結(jié)果賦值給i沟启;
4中同三一樣
在單線程環(huán)境下我們可以認(rèn)為整個步驟都是原子性操作,但是在多線程環(huán)境下則不同犹菇,Java只保證了基本數(shù)據(jù)類型的變量和賦值操作才是原子性的(注:在32位的JDK環(huán)境下德迹,對64位數(shù)據(jù)的讀取不是原子性操作*,如long揭芍、double)胳搞。
要想在多線程環(huán)境下保證原子性,則可以通過鎖沼沈、synchronized來確保流酬。volatile是無法保證復(fù)合操作的原子性。
二列另、可見性
可見性是指當(dāng)多個線程訪問同一個變量時芽腾,一個線程修改了這個變量的值,其他線程能夠立即看得到修改的值页衙。
舉個簡單的例子摊滔,看下面這段代碼:
//線程1執(zhí)行的代碼
int i = 0;
i = 10;
//線程2執(zhí)行的代碼
j = i;
假若執(zhí)行線程1的是CPU1,執(zhí)行線程2的是CPU2店乐。由上面的分析可知艰躺,當(dāng)線程1執(zhí)行 i = 10這句時,會先把i的初始值加載到CPU1的高速緩存中眨八,然后賦值為10腺兴,那么在CPU1的高速緩存當(dāng)中i的值變?yōu)?0了,卻沒有立即寫入到主存當(dāng)中廉侧。此時線程2執(zhí)行 j = i页响,它會先去主存讀取i的值并加載到CPU2的緩存當(dāng)中篓足,注意此時內(nèi)存當(dāng)中i的值還是0,那么就會使得j的值為0闰蚕,而不是10栈拖。這就是可見性問題,線程1對變量i修改了之后没陡,線程2沒有立即看到線程1修改的值涩哟。
在上面已經(jīng)分析了,在多線程環(huán)境下盼玄,一個線程對共享變量的操作對其他線程是不可見的贴彼。
對于可見性,Java提供了volatile關(guān)鍵字來保證可見性强岸。當(dāng)一個共享變量被volatile修飾時锻弓,它會保證修改的值會立即被更新到主存砾赔,當(dāng)有其他線程需要讀取時蝌箍,它會去內(nèi)存中讀取新值。而普通的共享變量不能保證可見性暴心,因為普通共享變量被修改之后妓盲,什么時候被寫入主存是不確定的,當(dāng)其他線程去讀取時专普,此時內(nèi)存中可能還是原來的舊值悯衬,因此無法保證可見性。另外檀夹,通過synchronized和Lock也能夠保證可見性筋粗,synchronized和Lock能保證同一時刻只有一個線程獲取鎖然后執(zhí)行同步代碼,并且在釋放鎖之前會將對變量的修改刷新到主存當(dāng)中炸渡。因此可以保證可見性娜亿。
三、有序性
即程序執(zhí)行的順序按照代碼的先后順序執(zhí)行蚌堵。舉個簡單的例子买决,看下面這段代碼:
int i = 0;
boolean flag = false;
i = 1; //語句1
flag = true; //語句2
上面代碼定義了一個int型變量,定義了一個boolean類型變量吼畏,然后分別對兩個變量進(jìn)行賦值操作督赤。從代碼順序上看,語句1是在語句2前面的泻蚊,那么JVM在真正執(zhí)行這段代碼的時候會保證語句1一定會在語句2前面執(zhí)行嗎躲舌?不一定,為什么呢性雄?這里可能會發(fā)生指令重排序(Instruction Reorder)没卸。
下面解釋一下什么是指令重排序枯冈,一般來說,處理器為了提高程序運行效率办悟,可能會對輸入代碼進(jìn)行優(yōu)化尘奏,它不保證程序中各個語句的執(zhí)行先后順序同代碼中的順序一致,但是它會保證程序最終執(zhí)行結(jié)果和代碼順序執(zhí)行的結(jié)果是一致的病蛉。
比如上面的代碼中炫加,語句1和語句2誰先執(zhí)行對最終的程序結(jié)果并沒有影響,那么就有可能在執(zhí)行過程中铺然,語句2先執(zhí)行而語句1后執(zhí)行俗孝。但是要注意,雖然處理器會對指令進(jìn)行重排序魄健,但是它會保證程序最終結(jié)果會和代碼順序執(zhí)行結(jié)果相同赋铝,那么它靠什么保證的呢?再看下面一個例子:
int a = 10; //語句1
int r = 2; //語句2
a = a + 3; //語句3
r = a*a; //語句4
這段代碼有4個語句沽瘦,那么可能的一個執(zhí)行順序是:
語句2 -> 語句1 -> 語句3 -> 語句4
那么可不可能是這個執(zhí)行順序:
語句2 -> 語句1 -> 語句4 -> 語句3革骨。
不可能,因為處理器在進(jìn)行重排序時是會考慮指令之間的數(shù)據(jù)依賴性析恋,如果一個指令I(lǐng)nstruction 2必須用到Instruction 1的結(jié)果良哲,那么處理器會保證Instruction 1會在Instruction 2之前執(zhí)行。雖然重排序不會影響單個線程內(nèi)程序執(zhí)行的結(jié)果助隧,但是多線程呢筑凫?下面看一個例子:
//線程1:
context = loadContext(); //語句1
inited = true; //語句2
//線程2:
while(!inited ){
sleep()
}
doSomethingwithconfig(context);
上面代碼中,由于語句1和語句2沒有數(shù)據(jù)依賴性并村,因此可能會被重排序巍实。假如發(fā)生了重排序,在線程1執(zhí)行過程中先執(zhí)行語句2哩牍,而此時線程2會以為初始化工作已經(jīng)完成棚潦,那么就會跳出while循環(huán),去執(zhí)行doSomethingwithconfig(context)方法姐叁,而此時context并沒有被初始化瓦盛,就會導(dǎo)致程序出錯。
從上面可以看出外潜,指令重排序不會影響單個線程的執(zhí)行原环,但是會影響到線程并發(fā)執(zhí)行的正確性。也就是說处窥,要想并發(fā)程序正確地執(zhí)行嘱吗,必須要保證原子性、可見性以及有序性。只要有一個沒有被保證谒麦,就有可能會導(dǎo)致程序運行不正確俄讹。
在Java內(nèi)存模型中,允許編譯器和處理器對指令進(jìn)行重排序绕德,但是重排序過程不會影響到單線程程序的執(zhí)行患膛,卻會影響到多線程并發(fā)執(zhí)行的正確性。
在Java里面耻蛇,可以通過volatile關(guān)鍵字來保證一定的“有序性”踪蹬。另外可以通過synchronized和Lock來保證有序性,很顯然臣咖,synchronized和Lock保證每個時刻是有一個線程執(zhí)行同步代碼跃捣,相當(dāng)于是讓線程順序執(zhí)行同步代碼,自然就保證了有序性夺蛇。另外疚漆,Java內(nèi)存模型具備一些先天的“有序性”,即不需要通過任何手段就能夠得到保證的有序性刁赦,這個通常也稱為 happens-before 原則娶聘。如果兩個操作的執(zhí)行次序無法從happens-before原則推導(dǎo)出來,那么它們就不能保證它們的有序性截型,虛擬機可以隨意地對它們進(jìn)行重排序趴荸。
針對有序性用下面例子在說明一下:
在單例模式的實現(xiàn)上有一種雙重檢驗鎖定的方式(Double-checked Locking)。代碼如下:
public class Singleton {
private Singleton() { }
private volatile static Singleton instance;
public Singleton getInstance(){
if(instance==null){
synchronized (Singleton.class){
if(instance==null){
instance = new Singleton();
}
}
}
return instance;
}
}
這里為什么要加volatile宦焦?我們先來分析一下不加volatile的情況,有問題的語句是這條:
instance = new Singleton();
這條語句實際上包含了三個操作:1.分配對象的內(nèi)存空間顿涣;2.初始化對象波闹;3.設(shè)置instance指向剛分配的內(nèi)存地址。但由于存在重排序的問題涛碑,可能有以下的執(zhí)行順序:
如果2和3進(jìn)行了重排序的話精堕,線程B進(jìn)行判斷if(instance==null)時就會為true,而實際上這個instance并沒有初始化成功蒲障,顯而易見對線程B來說之后的操作就會是錯得歹篓。而用volatile修飾的話就可以禁止2和3操作重排序,從而避免這種情況揉阎。因為volatile包含禁止指令重排序的語義庄撮,所以才有了有序性。
四毙籽、happens-before原則(先行發(fā)生原則)
程序次序規(guī)則:一個線程內(nèi)洞斯,按照代碼順序,書寫在前面的操作先行發(fā)生于書寫在后面的操作坑赡。
鎖定規(guī)則:一個unLock操作先行發(fā)生于后面對同一個鎖額lock操作烙如。
volatile變量規(guī)則:對一個變量的寫操作先行發(fā)生于后面對這個變量的讀操作么抗。
傳遞規(guī)則:如果操作A先行發(fā)生于操作B,而操作B又先行發(fā)生于操作C亚铁,則可以得出操作A先行發(fā)生于操作C蝇刀。
線程啟動規(guī)則:Thread對象的start()方法先行發(fā)生于此線程的每個一個動作。
線程中斷規(guī)則:對線程interrupt()方法的調(diào)用先行發(fā)生于被中斷線程的代碼檢測到中斷事件的發(fā)生徘溢。
線程終結(jié)規(guī)則:線程中所有的操作都先行發(fā)生于線程的終止檢測熊泵,我們可以通過Thread.join()方法結(jié)束、Thread.isAlive()的返回值手段檢測到線程已經(jīng)終止執(zhí)行甸昏。
對象終結(jié)規(guī)則:一個對象的初始化完成先行發(fā)生于他的finalize()方法的開始顽分。
這8條原則摘自《深入理解Java虛擬機》。這8條規(guī)則中施蜜,前4條規(guī)則是比較重要的卒蘸,后4條規(guī)則都是顯而易見的。下面我們來解釋一下前4條規(guī)則:
對于程序次序規(guī)則來說翻默,我的理解就是一段程序代碼的執(zhí)行在單個線程中看起來是有序的缸沃。注意,雖然這條規(guī)則中提到“書寫在前面的操作先行發(fā)生于書寫在后面的操作”修械,這個應(yīng)該是程序看起來執(zhí)行的順序是按照代碼順序執(zhí)行的趾牧,因為虛擬機可能會對程序代碼進(jìn)行指令重排序。雖然進(jìn)行重排序肯污,但是最終執(zhí)行的結(jié)果是與程序順序執(zhí)行的結(jié)果一致的翘单,它只會對不存在數(shù)據(jù)依賴性的指令進(jìn)行重排序。因此蹦渣,在單個線程中哄芜,程序執(zhí)行看起來是有序執(zhí)行的,這一點要注意理解柬唯。事實上认臊,這個規(guī)則是用來保證程序在單線程中執(zhí)行結(jié)果的正確性,但無法保證程序在多線程中執(zhí)行的正確性锄奢。
鎖定規(guī)則也比較容易理解失晴,也就是說無論在單線程中還是多線程中,同一個鎖如果出于被鎖定的狀態(tài)拘央,那么必須先對鎖進(jìn)行了釋放操作涂屁,后面才能繼續(xù)進(jìn)行l(wèi)ock操作。
volatile變量規(guī)則直觀地解釋就是堪滨,如果一個線程先去寫一個變量胯陋,然后一個線程去進(jìn)行讀取,那么寫入操作肯定會先行發(fā)生于讀操作。
傳遞規(guī)則實際上就是體現(xiàn)happens-before原則具備傳遞性遏乔。