在并發(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原則具備傳遞性遏乔。
