在這個(gè)小結(jié)里面重點(diǎn)討論原子操作的原理和設(shè)計(jì)思想。
由于在下一個(gè)章節(jié)中會談到鎖機(jī)制，因此此小節(jié)中會適當(dāng)引入鎖的概念。
在Java Concurrency in Practice中是這樣定義線程安全的：
當(dāng)多個(gè)線程訪問一個(gè)類時(shí)，如果不用考慮這些線程在運(yùn)行時(shí)環(huán)境下的調(diào)度和交替運(yùn)行，并且不需要額外的同步及在調(diào)用方代碼不必做其他的協(xié)調(diào)，這個(gè)類的行為仍然是正確的，那么這個(gè)類就是線程安全的。
顯然只有資源競爭時(shí)才會導(dǎo)致線程不安全，因此無狀態(tài)對象永遠(yuǎn)是線程安全的。
原子操作的描述是： 多個(gè)線程執(zhí)行一個(gè)操作時(shí)，其中任何一個(gè)線程要么完全執(zhí)行完此操作，要么沒有執(zhí)行此操作的任何步驟，那么這個(gè)操作就是原子的。
枯燥的定義介紹完了，下面說更枯燥的理論知識。
指令重排序
Java語言規(guī)范規(guī)定了JVM線程內(nèi)部維持順序化語義，也就是說只要程序的最終結(jié)果等同于它在嚴(yán)格的順序化環(huán)境下的結(jié)果，那么指令的執(zhí)行順序就可能與代碼的順序不一致。這個(gè)過程通過叫做指令的重排序。指令重排序存在的意義在于：JVM能夠根據(jù)處理器的特性（CPU的多級緩存系統(tǒng)、多核處理器等）適當(dāng)?shù)闹匦屡判驒C(jī)器指令，使機(jī)器指令更符合CPU的執(zhí)行特點(diǎn)，最大限度的發(fā)揮機(jī)器的性能。
程序執(zhí)行最簡單的模型是按照指令出現(xiàn)的順序執(zhí)行，這樣就與執(zhí)行指令的CPU無關(guān)，最大限度的保證了指令的可移植性。這個(gè)模型的專業(yè)術(shù)語叫做順序化一致性模型。但是現(xiàn)代計(jì)算機(jī)體系和處理器架構(gòu)都不保證這一點(diǎn)（因?yàn)槿藶榈闹付ú⒉荒芸偸潜ＷC符合CPU處理的特性）。
我們來看最經(jīng)典的一個(gè)案例。
package xylz.study.concurrency.atomic;
public class ReorderingDemo 
{
static int x = 0, y = 0, a = 0, b = 0;
public static void main(String[] args) throws Exception {
for (int i = 0; i < 100; i++) {
x=y=a=b=0;
Thread one = new Thread() {
public void run() {
a = 1;
x = b;
}
};
Thread two = new Thread() {
public void run() {
b = 1;
y = a;
}
};
one.start();
two.start();
one.join();
two.join();
System.out.println(x + " " + y);
}
}
}
在這個(gè)例子中one/two兩個(gè)線程修改區(qū)x,y,a,b四個(gè)變量，在執(zhí)行100次的情況下，可能得到(0 1)或者（1 0）或者（1 1）。事實(shí)上按照J(rèn)VM的規(guī)范以及CPU的特性有很可能得到（0 0）。當(dāng)然上面的代碼大家不一定能得到（0 0），因?yàn)閞un()里面的操作過于簡單，可能比啟動一個(gè)線程花費(fèi)的時(shí)間還少，因此上面的例子難以出現(xiàn)（0,0）。但是在現(xiàn)代CPU和JVM上確實(shí)是存在的。由于run()里面的動作對于結(jié)果是無關(guān)的，因此里面的指令可能發(fā)生指令重排序，即使是按照程序的順序執(zhí)行，數(shù)據(jù)變化刷新到主存也是需要時(shí)間的。假定是按照a=1;x=b;b=1;y=a;執(zhí)行的，x=0是比較正常的，雖然a=1在y=a之前執(zhí)行的，但是由于線程one執(zhí)行a=1完成后還沒有來得及將數(shù)據(jù)1寫回主存（這時(shí)候數(shù)據(jù)是在線程one的堆棧里面的），線程two從主存中拿到的數(shù)據(jù)a可能仍然是0（顯然是一個(gè)過期數(shù)據(jù)，但是是有可能的），這樣就發(fā)生了數(shù)據(jù)錯(cuò)誤。
在兩個(gè)線程交替執(zhí)行的情況下數(shù)據(jù)的結(jié)果就不確定了，在機(jī)器壓力大，多核CPU并發(fā)執(zhí)行的情況下，數(shù)據(jù)的結(jié)果就更加不確定了。
Happens-before法則
Java存儲模型有一個(gè)happens-before原則，就是如果動作B要看到動作A的執(zhí)行結(jié)果（無論A/B是否在同一個(gè)線程里面執(zhí)行），那么A/B就需要滿足happens-before關(guān)系。
在介紹happens-before法則之前介紹一個(gè)概念：JMM動作（Java Memeory Model Action），Java存儲模型動作。一個(gè)動作（Action）包括：變量的讀寫、監(jiān)視器加鎖和釋放鎖、線程的start()和join()。后面還會提到鎖的的。
happens-before完整規(guī)則：
（1）同一個(gè)線程中的每個(gè)Action都happens-before于出現(xiàn)在其后的任何一個(gè)Action。
（2）對一個(gè)監(jiān)視器的解鎖happens-before于每一個(gè)后續(xù)對同一個(gè)監(jiān)視器的加鎖。
（3）對volatile字段的寫入操作happens-before于每一個(gè)后續(xù)的同一個(gè)字段的讀操作。
（4）Thread.start()的調(diào)用會happens-before于啟動線程里面的動作。
（5）Thread中的所有動作都happens-before于其他線程檢查到此線程結(jié)束或者Thread.join（）中返回或者Thread.isAlive()==false。
（6）一個(gè)線程A調(diào)用另一個(gè)另一個(gè)線程B的interrupt（）都happens-before于線程A發(fā)現(xiàn)B被A中斷（B拋出異常或者A檢測到B的isInterrupted（）或者interrupted()）。
（7）一個(gè)對象構(gòu)造函數(shù)的結(jié)束happens-before與該對象的finalizer的開始
（8）如果A動作happens-before于B動作，而B動作happens-before與C動作，那么A動作happens-before于C動作。
volatile語義
到目前為止，我們多次提到volatile，但是卻仍然沒有理解volatile的語義。
volatile相當(dāng)于synchronized的弱實(shí)現(xiàn)，也就是說volatile實(shí)現(xiàn)了類似synchronized的語義，卻又沒有鎖機(jī)制。它確保對volatile字段的更新以可預(yù)見的方式告知其他的線程。
volatile包含以下語義：
（1）Java 存儲模型不會對valatile指令的操作進(jìn)行重排序：這個(gè)保證對volatile變量的操作時(shí)按照指令的出現(xiàn)順序執(zhí)行的。
（2）volatile變量不會被緩存在寄存器中（只有擁有線程可見）或者其他對CPU不可見的地方，每次總是從主存中讀取volatile變量的結(jié)果。也就是說對于volatile變量的修改，其它線程總是可見的，并且不是使用自己線程棧內(nèi)部的變量。也就是在happens-before法則中，對一個(gè)valatile變量的寫操作后，其后的任何讀操作理解可見此寫操作的結(jié)果。
盡管volatile變量的特性不錯(cuò)，但是volatile并不能保證線程安全的，也就是說volatile字段的操作不是原子性的，volatile變量只能保證可見性（一個(gè)線程修改后其它線程能夠理解看到此變化后的結(jié)果），要想保證原子性，目前為止只能加鎖！
volatile通常在下面的場景：
volatile boolean done = false;
…
while( ! done ){
dosomething();
}
應(yīng)用volatile變量的三個(gè)原則：
（1）寫入變量不依賴此變量的值，或者只有一個(gè)線程修改此變量
（2）變量的狀態(tài)不需要與其它變量共同參與不變約束
（3）訪問變量不需要加鎖
這一節(jié)理論知識比較多，但是這是很面很多章節(jié)的基礎(chǔ)，在后面的章節(jié)中會多次提到這些特性。
本小節(jié)中還是沒有談到原子操作的原理和思想，在下一節(jié)中將根據(jù)上面的一些知識來介紹原子操作。
參考資料：
（1）Java Concurrency in Practice
（2）正確使用 Volatile 變量
©2009-2014 IMXYLZ
|求賢若渴