最近看LumaQQ的源碼發現一個volatile（中文意思是“可變的、不穩定的”），找了篇英文介紹。抽空我翻譯了一下，翻錯了大家不要見笑。。。

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

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