并發(fā)編程:原子性,可見性和有序性

并發(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í)行順序:


image.png

如果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原則具備傳遞性遏乔。

最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 序言:七十年代末义矛,一起剝皮案震驚了整個濱河市,隨后出現(xiàn)的幾起案子盟萨,更是在濱河造成了極大的恐慌凉翻,老刑警劉巖,帶你破解...
    沈念sama閱讀 222,946評論 6 518
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件捻激,死亡現(xiàn)場離奇詭異制轰,居然都是意外死亡,警方通過查閱死者的電腦和手機胞谭,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 95,336評論 3 399
  • 文/潘曉璐 我一進(jìn)店門垃杖,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人丈屹,你說我怎么就攤上這事调俘。” “怎么了旺垒?”我有些...
    開封第一講書人閱讀 169,716評論 0 364
  • 文/不壞的土叔 我叫張陵彩库,是天一觀的道長。 經(jīng)常有香客問我先蒋,道長骇钦,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 60,222評論 1 300
  • 正文 為了忘掉前任竞漾,我火速辦了婚禮眯搭,結(jié)果婚禮上,老公的妹妹穿的比我還像新娘畴蹭。我一直安慰自己坦仍,他們只是感情好,可當(dāng)我...
    茶點故事閱讀 69,223評論 6 398
  • 文/花漫 我一把揭開白布叨襟。 她就那樣靜靜地躺著,像睡著了一般幔荒。 火紅的嫁衣襯著肌膚如雪糊闽。 梳的紋絲不亂的頭發(fā)上,一...
    開封第一講書人閱讀 52,807評論 1 314
  • 那天爹梁,我揣著相機與錄音右犹,去河邊找鬼。 笑死姚垃,一個胖子當(dāng)著我的面吹牛念链,可吹牛的內(nèi)容都是我干的。 我是一名探鬼主播,決...
    沈念sama閱讀 41,235評論 3 424
  • 文/蒼蘭香墨 我猛地睜開眼掂墓,長吁一口氣:“原來是場噩夢啊……” “哼谦纱!你這毒婦竟也來了?” 一聲冷哼從身側(cè)響起君编,我...
    開封第一講書人閱讀 40,189評論 0 277
  • 序言:老撾萬榮一對情侶失蹤跨嘉,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后吃嘿,有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體祠乃,經(jīng)...
    沈念sama閱讀 46,712評論 1 320
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點故事閱讀 38,775評論 3 343
  • 正文 我和宋清朗相戀三年兑燥,在試婚紗的時候發(fā)現(xiàn)自己被綠了亮瓷。 大學(xué)時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 40,926評論 1 353
  • 序言:一個原本活蹦亂跳的男人離奇死亡降瞳,死狀恐怖嘱支,靈堂內(nèi)的尸體忽然破棺而出,到底是詐尸還是另有隱情力崇,我是刑警寧澤斗塘,帶...
    沈念sama閱讀 36,580評論 5 351
  • 正文 年R本政府宣布,位于F島的核電站亮靴,受9級特大地震影響馍盟,放射性物質(zhì)發(fā)生泄漏。R本人自食惡果不足惜茧吊,卻給世界環(huán)境...
    茶點故事閱讀 42,259評論 3 336
  • 文/蒙蒙 一贞岭、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧搓侄,春花似錦瞄桨、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 32,750評論 0 25
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至乳讥,卻和暖如春柱查,著一層夾襖步出監(jiān)牢的瞬間,已是汗流浹背云石。 一陣腳步聲響...
    開封第一講書人閱讀 33,867評論 1 274
  • 我被黑心中介騙來泰國打工唉工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人汹忠。 一個月前我還...
    沈念sama閱讀 49,368評論 3 379
  • 正文 我出身青樓淋硝,卻偏偏與公主長得像雹熬,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子谣膳,可洞房花燭夜當(dāng)晚...
    茶點故事閱讀 45,930評論 2 361

推薦閱讀更多精彩內(nèi)容