線程安全是個非常棘手的問題。即使你合理的使用了鎖（lock），依然可能不會產生預期的效果。
讓我們來看看貌似合理的代碼
X=0;
Thread 1 Thread2
lock(); lock();
x++; x++;
unlock(); unlock();
你會認為執行完這兩個線程之后，X的一定值等于2？沒錯，因為lock()和unlock()的保護，x++的執行并不會被打斷。（為什么++操作會被多線程給擾亂呢？原因就在于++操作在被編譯成匯編之后對應到了多條匯編代碼。）但是，編譯器卻可能因為自作聰明的優化，把x放到register里面（因為寄存器速度快嘛），也就是說當Thread1執行完x++之后，被Thread2打斷，但是1這個值只保存到了寄存器x里，沒有寫入內存中的x變量里。隨后Thread2執行完成后，內存中x的值等于1，此時，Thread1再執行完，內存中的x又被寫入為1.
原來都是編譯器倒得鬼！
再看一個例子
x=y=0;
Thread1 Thread2
y=1; x=1;
r1=x; r2=y;
當你拍胸脯向崇拜你的MM保證說：r1或者r2至少有一個為1的時候，可惜編譯器又再一次的站到了你的對立面。
原因是早在十幾年前還是幾十年前，編譯器就有了這么一種優化機制，為了提高效率而交換指令的序列。所以上面的代碼到了可能變成了這樣：
x=y=0;
Thread1 Thread2
r1=x; r2=y;
y=1; x=1;
知道你錯了吧～還好我們還有volatile：
1. 阻止編譯器為了提高速度將變量緩存寄存到寄存器內而不寫回內存。
2. 阻止編譯器調整操作指令序列
哈哈，可惜道高一尺，魔高一丈。CPU動態調度的功能，CPU可以交換指令序列。volatile幫不了你，但宙斯大帝為我們發明了：barrier指令（這是一個CPU的指令）能夠幫組我們阻止CPU調整操作指令序列。
好想目前我們解決了現場安全的問題了。
有一個著名的與換序有關的問題來至于Singleton模式的double-check。代碼大概是這樣子的：
volatile Singleton* Singleton::_instance = 0;
static Singleton& Instance() {
if (0 == _instance) {
Lock lock(_mutex);
if (0 == _instance) {
_instance = new Singleton();
atexit(Destroy);
}
}
return *_instance;
}
簡單的說，編譯器為了效率可能會重排指令的執行順序(compiler-based reorderings)。
看這一行代碼：
_instance = new Singleton();
在編譯器未優化的情況下順序如下：
1.new operator分配適當的內存；
2.在分配的內存上構造Singleton對象；
3.內存地址賦值給_instance。
但是當編譯器優化后執行順序可能如下：
1.new operator分配適當的內存；
2.內存地址賦值給_instance；
3.在分配的內存上構造Singleton對象。
當編譯器優化后，如果線程一執行到2后被掛起。線程二開始執行并發現0 == _instance為false，于是直接return，而這時Singleton對象可能還未構造完成，后果...
