1.原子性（Atomicity）

原子性指的是一個操作是不可中斷的，即使是在多線程環(huán)境下，一個操作一旦開始就不會被其他線程影響。由Java內存模型來直接保證的原子性變量操作包括read、load、assign、use、store和write這六個，我們大致可以認為，基本數(shù)據(jù)類型的訪問、讀寫都是具備原子性的（例外就是long和double的非原子性協(xié)定）。如果應用場景需要一個更大范圍的原子性保證（經常會遇到），Java內存模型還提供了lock和unlock操作來滿足這種需求，盡管虛擬機未把lock和unlock操作直接開放給用戶使用，但是卻提供了更高層次的字節(jié)碼指令monitorenter和monitorexit來隱式地使用這兩個操作。這兩個字節(jié)碼指令反映到Java代碼中就是同步塊——synchronized關鍵字，因此在synchronized塊之間的操作也具備原子性。

long和double的非原子性協(xié)定”（Non-Atomic Treatment of double and long Variables）：

在java中，對基本數(shù)據(jù)類型的變量的讀取和賦值操作是原子性操作有點要注意的是，對于32位系統(tǒng)的來說，long類型數(shù)據(jù)和double類型數(shù)據(jù)(對于基本數(shù)據(jù)類型，byte, short, int, float, boolean, char讀寫是原子操作)，它們的讀寫并非原子性的，也就是說如果存在兩條線程同時對long類型或者double類型的數(shù)據(jù)進行讀寫是存在相互干擾的，因為對于32位虛擬機來說，每次原子讀寫是32位的，而long和double則是64位的存儲單元，這樣會導致一個線程在寫時，操作完前32位的原子操作后，輪到B線程讀取時，恰好只讀取到了后32位的數(shù)據(jù)，這樣可能會讀取到一個既非原值又不是線程修改值的變量，它可能是“半個變量”的數(shù)值，即64位數(shù)據(jù)被兩個線程分成了兩次讀取。但也不必太擔心，因為讀取到“半個變量”的情況比較少見，至少在目前的商用的虛擬機中，幾乎都把64位的數(shù)據(jù)的讀寫操作作為原子操作來執(zhí)行。

• X=10; //原子性（簡單的讀取、將數(shù)字賦值給變量）
• Y = x; //變量之間的相互賦值，不是原子操作
• X++; //對變量進行計算操作
• X = x+1;

2.可見性（Visibility）

可見性就是指當一個線程修改了共享變量的值時，其他線程能夠立即得知這個修改。上文在講解volatile變量的時候我們已詳細討論過這一點。Java內存模型是通過在變量修改后將新值同步回主內存，在變量讀取前從主內存刷新變量值這種依賴主內存作為傳遞媒介的方式來實現(xiàn)可見性的，無論是普通變量還是volatile變量都是如此。普通變量與volatile變量的區(qū)別是，volatile的特殊規(guī)則保證了新值能立即同步到主內存，以及每次使用前立即從主內存刷新。因此我們可以說volatile保證了多線程操作時變量的可見性，而普通變量則不能保證這一點。

除了volatile之外，Java還有兩個關鍵字能實現(xiàn)可見性，它們是synchronized和final。同步塊的可見性是由“對一個變量執(zhí)行unlock操作之前，必須先把此變量同步回主內存中（執(zhí)行store、write操作）”這條規(guī)則獲得的。而final關鍵字的可見性是指：被final修飾的字段在構造器中一旦被初始化完成，并且構造器沒有把“this”的引用傳遞出去（this引用逃逸是一件很危險的事情，其他線程有可能通過這個引用訪問到“初始化了一半”的對象），那么在其他線程中就能看見final字段的值。

如下面所示，變量i與j都具備可見性，它們無須同步就能被其他線程正確訪問。

public static final int i;
public final int j;
static {
	i = 0;
	// 省略后續(xù)動作
}
{
	// 也可以選擇在構造函數(shù)中初始化
	j = 0;
	// 省略后續(xù)動作
}

3.有序性（Ordering）

Java內存模型的有序性在前面講解volatile時也比較詳細地討論過了，Java程序中天然的有序性可以總結為一句話：如果在本線程內觀察，所有的操作都是有序的；如果在一個線程中觀察另一個線程，所有的操作都是無序的。前半句是指“線程內似表現(xiàn)為串行的語義”（Within-Thread As-If-Serial Semantics），后半句是指“指令重排序”現(xiàn)象和“工作內存與主內存同步延遲”現(xiàn)象。Java語言提供了volatile和synchronized兩個關鍵字來保證線程之間操作的有序性，volatile關鍵字本身就包含了禁止指令重排序的語義，而synchronized則是由“一個變量在同一個時刻只允許一條線程對其進行l(wèi)ock操作”這條規(guī)則獲得的，這個規(guī)則決定了持有同一個鎖的兩個同步塊只能串行地進入。

volatile用來保證可見性和有序性，synchronized則對三種特性都可以保證。

4.happens-before（先行發(fā)生）原則

只靠sychronized和volatile關鍵字來保證原子性、可見性以及有序性，那么編寫并發(fā)程序可能會顯得十分麻煩，幸運的是，從JDK 5開始，Java使用新的JSR-133內存模型，提供了
happens-before 原則來輔助保證程序執(zhí)行的原子性、可見性以及有序性的問題，它是判斷數(shù)據(jù)是否存在競爭、線程是否安全的依據(jù)。

先行發(fā)生是Java內存模型中定義的兩項操作之間的偏序關系，比如說操作A先行發(fā)生于操作B，其實就是說在發(fā)生操作B之前，操作A產生的影響能被操作B觀察到，“影響”包括修改了內存中共享變量的值、發(fā)送了消息、調用了方法等。下面三個偽代碼：

// 以下操作在線程A中執(zhí)行
i = 1;
// 以下操作在線程B中執(zhí)行
j = i;
// 以下操作在線程C中執(zhí)行
i = 2;

假設線程A中的操作“i=1”先行發(fā)生于線程B的操作“j=i”，那我們就可以確定在線程B的操作執(zhí)行后，變量j的值一定是等于1，得出這個結論的依據(jù)有兩個：一是根據(jù)先行發(fā)生原則，“i=1”的結果可以被觀察到；二是線程C還沒登場，線程A操作結束之后沒有其他線程會修改變量i的值。現(xiàn)在再來考慮線程C，我們依然保持線程A和B之間的先行發(fā)生關系，而C出現(xiàn)在線程A和B的操作之間，但是C與B沒有先行發(fā)生關系，那j的值會是多少呢？答案是不確定！1和2都有可能，因為線程C對變量i的影響可能會被線程B觀察到，也可能不會，這時候線程B就存在讀取到過期數(shù)據(jù)的風險，不具備多線程安全性。

下面是Java內存模型下一些“天然的”先行發(fā)生關系，這些先行發(fā)生關系無須任何同步器協(xié)助就已經存在，可以在編碼中直接使用。如果兩個操作之間的關系不在此列，并且無法從下列規(guī)則推導出來，則它們就沒有順序性保障，虛擬機可以對它們隨意地進行重排序。

• 程序次序規(guī)則（Program Order Rule）：在一個線程內，按照控制流順序，書寫在前面的操作先行發(fā)生于書寫在后面的操作。注意，這里說的是控制流順序而不是程序代碼順序，因為要考慮分支、循環(huán)等結構。
• 管程鎖定規(guī)則（Monitor Lock Rule）：一個unlock操作先行發(fā)生于后面對同一個鎖的lock操作。這里必須強調的是“同一個鎖”，而“后面”是指時間上的先后。
• volatile變量規(guī)則（Volatile Variable Rule）：對一個volatile變量的寫操作先行發(fā)生于后面對這個變量的讀操作，這里的“后面”同樣是指時間上的先后。
• 線程啟動規(guī)則（Thread Start Rule）：Thread對象的start()方法先行發(fā)生于此線程的每一個動作。
• 線程終止規(guī)則（Thread Termination Rule）：線程中的所有操作都先行發(fā)生于對此線程的終止檢測，我們可以通過Thread::join()方法是否結束、Thread::isAlive()的返回值等手段檢測線程是否已經終止執(zhí)行。
• 線程中斷規(guī)則（Thread Interruption Rule）：對線程interrupt()方法的調用先行發(fā)生于被中斷線程的代碼檢測到中斷事件的發(fā)生，可以通過Thread::interrupted()方法檢測到是否有中斷發(fā)生。
• 對象終結規(guī)則（Finalizer Rule）：一個對象的初始化完成（構造函數(shù)執(zhí)行結束）先行發(fā)生于它的finalize()方法的開始。
• 傳遞性（Transitivity）：如果操作A先行發(fā)生于操作B，操作B先行發(fā)生于操作C，那就可以得出操作A先行發(fā)生于操作C的結論。

一個操作“時間上的先發(fā)生”不代表這個操作會是“先行發(fā)生”。如果一個操作“先行發(fā)生”，這個操作也不代表是“時間上的先發(fā)生”的，因為存在指令重排的可能性。時間先后順序與先行發(fā)生原則之間基本沒有因果關系，所以我們衡量并發(fā)安全問題的時候不要受時間順序的干擾，一切必須以先行發(fā)生原則為準

參考《深入理解Java虛擬機第三版周志明》

到此這篇關于Java并發(fā)之原子性 有序性 可見性及Happen Before原則的文章就介紹到這了,更多相關Java 并發(fā)原則內容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！