最近看LumaQQ的源碼發(fā)現(xiàn)一個(gè)volatile（中文意思是“可變的、不穩(wěn)定的”），找了篇英文介紹。抽空我翻譯了一下，翻錯(cuò)了大家不要見笑。。。

volatile關(guān)鍵字有什么用？
　　恐怕比較一下volatile和synchronized的不同是最容易解釋清楚的。volatile是變量修飾符，而synchronized則作用于一段代碼或方法；看如下三句get代碼：

　　geti1()得到存儲(chǔ)在當(dāng)前線程中i1的數(shù)值。多個(gè)線程有多個(gè)i1變量拷貝，而且這些i1之間可以互不相同。換句話說(shuō)，另一個(gè)線程可能已經(jīng)改變了它線程內(nèi)的i1值，而這個(gè)值可以和當(dāng)前線程中的i1值不相同。事實(shí)上，Java有個(gè)思想叫“主”內(nèi)存區(qū)域，這里存放了變量目前的“準(zhǔn)確值”。每個(gè)線程可以有它自己的變量拷貝，而這個(gè)變量拷貝值可以和“主”內(nèi)存區(qū)域里存放的不同。因此實(shí)際上存在一種可能：“主”內(nèi)存區(qū)域里的i1值是1，線程1里的i1值是2，線程2里的i1值是3——這在線程1和線程2都改變了它們各自的i1值，而且這個(gè)改變還沒(méi)來(lái)得及傳遞給“主”內(nèi)存區(qū)域或其他線程時(shí)就會(huì)發(fā)生。
　　而geti2()得到的是“主”內(nèi)存區(qū)域的i2數(shù)值。用volatile修飾后的變量不允許有不同于“主”內(nèi)存區(qū)域的變量拷貝。換句話說(shuō)，一個(gè)變量經(jīng)volatile修飾后在所有線程中必須是同步的；任何線程中改變了它的值，所有其他線程立即獲取到了相同的值。理所當(dāng)然的，volatile修飾的變量存取時(shí)比一般變量消耗的資源要多一點(diǎn)，因?yàn)榫€程有它自己的變量拷貝更為高效。
　　既然volatile關(guān)鍵字已經(jīng)實(shí)現(xiàn)了線程間數(shù)據(jù)同步，又要synchronized干什么呢？呵呵，它們之間有兩點(diǎn)不同。首先，synchronized獲得并釋放監(jiān)視器——如果兩個(gè)線程使用了同一個(gè)對(duì)象鎖，監(jiān)視器能強(qiáng)制保證代碼塊同時(shí)只被一個(gè)線程所執(zhí)行——這是眾所周知的事實(shí)。但是，synchronized也同步內(nèi)存：事實(shí)上，synchronized在“主”內(nèi)存區(qū)域同步整個(gè)線程的內(nèi)存。因此，執(zhí)行g(shù)eti3()方法做了如下幾步：
1. 線程請(qǐng)求獲得監(jiān)視this對(duì)象的對(duì)象鎖（假設(shè)未被鎖，否則線程等待直到鎖釋放）
2. 線程內(nèi)存的數(shù)據(jù)被消除，從“主”內(nèi)存區(qū)域中讀入（Java虛擬機(jī)能優(yōu)化此步。。。[后面的不知道怎么表達(dá),汗]）
3. 代碼塊被執(zhí)行
4. 對(duì)于變量的任何改變現(xiàn)在可以安全地寫到“主”內(nèi)存區(qū)域中（不過(guò)geti3()方法不會(huì)改變變量值）
5. 線程釋放監(jiān)視this對(duì)象的對(duì)象鎖
　　因此volatile只是在線程內(nèi)存和“主”內(nèi)存間同步某個(gè)變量的值，而synchronized通過(guò)鎖定和解鎖某個(gè)監(jiān)視器同步所有變量的值。顯然synchronized要比volatile消耗更多資源。

附英文原文：
What does volatile do?

geti1() accesses the value currently stored in i1 in the current thread. Threads can have local copies of variables, and the data does not have to be the same as the data held in other threads. In particular, another thread may have updated i1 in it’s thread, but the value in the current thread could be different from that updated value. In fact Java has the idea of a “main” memory, and this is the memory that holds the current “correct” value for variables. Threads can have their own copy of data for variables, and the thread copy can be different from the “main” memory. So in fact, it is possible for the “main” memory to have a value of 1 for i1, for thread1 to have a value of 2 for i1 and for thread2 to have a value of 3 for i1 if thread1 and thread2 have both updated i1 but those updated value has not yet been propagated to “main” memory or other threads.

On the other hand, geti2() effectively accesses the value of i2 from “main” memory. A volatile variable is not allowed to have a local copy of a variable that is different from the value currently held in “main” memory. Effectively, a variable declared volatile must have it’s data synchronized across all threads, so that whenever you access or update the variable in any thread, all other threads immediately see the same value. Of course, it is likely that volatile variables have a higher access and update overhead than “plain” variables, since the reason threads can have their own copy of data is for better efficiency.

Well if volatile already synchronizes data across threads, what is synchronized for? Well there are two differences. Firstly synchronized obtains and releases locks on monitors which can force only one thread at a time to execute a code block, if both threads use the same monitor (effectively the same object lock). That’s the fairly well known aspect to synchronized. But synchronized also synchronizes memory. In fact synchronized synchronizes the whole of thread memory with “main” memory. So executing geti3() does the following:

1. The thread acquires the lock on the monitor for object this (assuming the monitor is unlocked, otherwise the thread waits until the monitor is unlocked).
2. The thread memory flushes all its variables, i.e. it has all of its variables effectively read from “main” memory (JVMs can use dirty sets to optimize this so that only “dirty” variables are flushed, but conceptually this is the same. See section 17.9 of the Java language specification).
3. The code block is executed (in this case setting the return value to the current value of i3, which may have just been reset from “main” memory).
4. (Any changes to variables would normally now be written out to “main” memory, but for geti3() we have no changes.)
5. The thread releases the lock on the monitor for object this.

So where volatile only synchronizes the value of one variable between thread memory and “main” memory, synchronized synchronizes the value of all variables between thread memory and “main” memory, and locks and releases a monitor to boot. Clearly synchronized is likely to have more overhead than volatile.