1. 背景

前幾天，發了一條如下的微博 (關於C/C++ Volatile關鍵詞的使用建議)：

此微博，引發了朋友們的大量討論：贊同者有之；批評者有之；當然，更多的朋友，是希望我能更詳細的解讀C/C++ Volatile關鍵詞，來佐證我的微博觀點。而這，正是我寫這篇博文的初衷：本文，將詳細分析C/C++ Volatile關鍵詞的功能 (有多種功能)、Volatile關鍵詞在多執行緒程式設計中存在的問題、Volatile關鍵詞與編譯器/CPU的關係、C/C++ Volatile與Java Volatile的區別，以及Volatile關鍵詞的起源，希望對大家更好的理解、使用C/C++ Volatile，有所幫助。

Volatile，詞典上的解釋為：易失的；易變的；易揮發的。那麼用這個關鍵詞修飾的C/C++變數，應該也能夠體現出”易變”的特徵。大部分人認識Volatile，也是從這個特徵出發，而這也是本文揭祕的C/C++ Volatile的第一個特徵。

1. Volatile：易變的

在介紹C/C++ Volatile關鍵詞的”易變”性前，先讓我們看看以下的兩個程式碼片段，以及他們對應的彙編指令 (以下用例的彙編程式碼，均為VS 2008編譯出來的Release版本)：

• 測試用例一：非Volatile變數
  

  

  b = a + 1;這條語句，對應的彙編指令是：lea ecx, [eax + 1]。由於變數a，在前一條語句a = fn(c)執行時，被快取在了暫存器eax中，因此b = a + 1；語句，可以直接使用仍舊在暫存器eax中的a，來進行計算，對應的也就是彙編：[eax + 1]。
  

• 測試用例二：Volatile變數
  

與測試用例一唯一的不同之處，是變數a被設定為volatile屬性，一個小小的變化，帶來的是彙編程式碼上很大的變化。a = fn(c)執行後，暫存器ecx中的a，被寫回記憶體：mov dword ptr [esp+0Ch], ecx。然後，在執行b = a + 1；語句時，變數a有重新被從記憶體中讀取出來：mov eax, dword ptr [esp + 0Ch]，而不再直接使用暫存器ecx中的內容。

1. 小結

從以上的兩個用例，就可以看出C/C++ Volatile關鍵詞的第一個特性：易變性。所謂的易變性，在彙編層面反映出來，就是兩條語句，下一條語句不會直接使用上一條語句對應的volatile變數的暫存器內容，而是重新從記憶體中讀取

在瞭解了C/C++ Volatile關鍵詞的”易變”特性之後，再讓我們接著繼續來剖析Volatile的下一個特性：”不可優化”特性。

1. Volatile：不可優化的

與前面介紹的”易變”性類似，關於C/C++ Volatile關鍵詞的第二個特性：”不可優化”性，也通過兩個對比的程式碼片段來說明：

• 測試用例三：非Volatile變數
  

  

  在這個用例中，非volatile變數a，b，c全部被編譯器優化掉了 (optimize out)，因為編譯器通過分析，發覺a，b，c三個變數是無用的，可以進行常量替換。最後的彙編程式碼相當簡介，高效率。
  

• 測試用例四：Volatile變數
  

  

  測試用例四，與測試用例三類似，不同之處在於，a，b，c三個變數，都是volatile變數。這個區別，反映到組合語言中，就是三個變數仍舊存在，需要將三個變數從記憶體讀入到暫存器之中，然後再呼叫printf()函式。
  

1. 小結

從測試用例三、四，可以總結出C/C++ Volatile關鍵詞的第二個特性：“不可優化”特性。volatile告訴編譯器，不要對我這個變數進行各種激進的優化，甚至將變數直接消除，保證程式設計師寫在程式碼中的指令，一定會被執行。相對於前面提到的第一個特性：”易變”性，”不可優化”特性可能知曉的人會相對少一些。但是，相對於下面提到的C/C++ Volatile的第三個特性，無論是”易變”性，還是”不可優化”性，都是Volatile關鍵詞非常流行的概念。

1. Volatile：順序性

C/C++ Volatile關鍵詞前面提到的兩個特性，讓Volatile經常被解讀為一個為多執行緒而生的關鍵詞：一個全域性變數，會被多執行緒同時訪問/修改，那麼執行緒內部，就不能假設此變數的不變性，並且基於此假設，來做一些程式設計。當然，這樣的假設，本身並沒有什麼問題，多執行緒程式設計，併發訪問/修改的全域性變數，通常都會建議加上Volatile關鍵詞修飾，來防止C/C++編譯器進行不必要的優化。但是，很多時候，C/C++ Volatile關鍵詞，在多執行緒環境下，會被賦予更多的功能，從而導致問題的出現。

回到本文背景部分我的那篇微博，我的這位朋友，正好犯了一個這樣的問題。其對C/C++ Volatile關鍵詞的使用，可以抽象為下面的虛擬碼：

這段虛擬碼，宣告另一個Volatile的flag變數。一個執行緒(Thread1)在完成一些操作後，會修改這個變數。而另外一個執行緒(Thread2)，則不斷讀取這個flag變數，由於flag變數被聲明瞭volatile屬性，因此編譯器在編譯時，並不會每次都從暫存器中讀取此變數，同時也不會通過各種激進的優化，直接將if (flag == true)改寫為if (false == true)。只要flag變數在Thread1中被修改，Thread2中就會讀取到這個變化，進入if條件判斷，然後進入if內部進行處理。在if條件的內部，由於flag == true，那麼假設Thread1中的something操作一定已經完成了，在基於這個假設的基礎上，繼續進行下面的other things操作。

通過將flag變數宣告為volatile屬性，很好的利用了本文前面提到的C/C++ Volatile的兩個特性：”易變”性；”不可優化”性。按理說，這是一個對於volatile關鍵詞的很好應用，而且看到這裡的朋友，也可以去檢查檢查自己的程式碼，我相信肯定會有這樣的使用存在。

但是，這個多執行緒下看似對於C/C++ Volatile關鍵詞完美的應用，實際上卻是有大問題的。問題的關鍵，就在於前面標紅的文字：由於flag = true，那麼假設Thread1中的something操作一定已經完成了。flag == true，為什麼能夠推斷出Thread1中的something一定完成了？其實既然我把這作為一個錯誤的用例，答案是一目瞭然的：這個推斷不能成立，你不能假設看到flag == true後，flag = true;這條語句前面的something一定已經執行完成了。這就引出了C/C++ Volatile關鍵詞的第三個特性：順序性。

同樣，為了說明C/C++ Volatile關鍵詞的”順序性”特徵，下面給出三個簡單的用例 (注：與上面的測試用例不同，下面的三個用例，基於的是Linux系統，使用的是”GCC: (Debian 4.3.2-1.1) 4.3.2″)：

• 測試用例五：非Volatile變數
  

  

  一個簡單的示例，全域性變數A，B均為非volatile變數。通過gcc O2優化進行編譯，你可以驚奇的發現，A，B兩個變數的賦值順序被調換了！！！在對應的彙編程式碼中，B = 0語句先被執行，然後才是A = B + 1語句被執行。
  

  在這裡，我先簡單的介紹一下C/C++編譯器最基本優化原理：保證一段程式的輸出，在優化前後無變化。將此原理應用到上面，可以發現，雖然gcc優化了A，B變數的賦值順序，但是foo()函式的執行結果，優化前後沒有發生任何變化，仍舊是A = 1；B = 0。因此這麼做是可行的。
  

• 測試用例六：一個Volatile變數
  

  

  此測試，相對於測試用例五，最大的區別在於，變數B被宣告為volatile變數。通過檢視對應的彙編程式碼，B仍舊被提前到A之前賦值，Volatile變數B，並未阻止編譯器優化的發生，編譯後仍舊發生了亂序現象。
  

  如此看來，C/C++ Volatile變數，與非Volatile變數之間的操作，是可能被編譯器交換順序的。
  

  通過此用例，已經能夠很好的說明，本章節前面，通過flag == true，來假設something一定完成是不成立的。在多執行緒下，如此使用volatile，會產生很嚴重的問題。但是，這不是終點，請繼續看下面的測試用例七。
  

• 測試用例七：兩個Volatile變數
  

  

  同時將A，B兩個變數都宣告為volatile變數，再來看看對應的彙編。奇蹟發生了，A，B賦值亂序的現象消失。此時的彙編程式碼，與使用者程式碼順序高度一直，先賦值變數A，然後賦值變數B。
  

  如此看來，C/C++ Volatile變數間的操作，是不會被編譯器交換順序的。
  

1. happens-before

通過測試用例六，可以總結出：C/C++ Volatile變數與非Volatile變數間的操作順序，有可能被編譯器交換。因此，上面多執行緒操作的虛擬碼，在實際執行的過程中，就有可能變成下面的順序：

由於Thread1中的程式碼執行順序發生變化，flag = true被提前到something之前進行，那麼整個Thread2的假設全部失效。由於something未執行，但是Thread2進入了if程式碼段，整個多執行緒程式碼邏輯出現問題，導致多執行緒完全錯誤。

細心的讀者看到這裡，可能要提問，根據測試用例七，C/C++ Volatile變數間，編譯器是能夠保證不交換順序的，那麼能不能將something中所有的變數全部設定為volatile呢？這樣就阻止了編譯器的亂序優化，從而也就保證了這個多執行緒程式的正確性。

針對此問題，很不幸，仍舊不行。將所有的變數都設定為volatile，首先能夠阻止編譯器的亂序優化，這一點是可以肯定的。但是，別忘了，編譯器編譯出來的程式碼，最終是要通過CPU來執行的。目前，市場上有各種不同體系架構的CPU產品，CPU本身為了提高程式碼執行的效率，也會對程式碼的執行順序進行調整，這就是所謂的CPU Memory Model (CPU記憶體模型)。關於CPU的記憶體模型，可以參考這些資料：Memory Ordering From Wiki；Memory Barriers Are Like Source Control Operations From Jeff Preshing；CPU Cache and Memory Ordering From 何登成。下面，是擷取自Wiki上的一幅圖，列舉了不同CPU架構，可能存在的指令亂序。

從圖中可以看到，X86體系(X86，AMD64)，也就是我們目前使用最廣的CPU，也會存在指令亂序執行的行為：StoreLoad亂序，讀操作可以提前到寫操作之前進行。

因此，回到上面的例子，哪怕將所有的變數全部都宣告為volatile，哪怕杜絕了編譯器的亂序優化，但是針對生成的彙編程式碼，CPU有可能仍舊會亂序執行指令，導致程式依賴的邏輯出錯，volatile對此無能為力。

其實，針對這個多執行緒的應用，真正正確的做法，是構建一個happens-before語義。關於happens-before語義的定義，可參考文章：The Happens-Before Relation。下面，用圖的形式，來展示happens-before語義：

如圖所示，所謂的happens-before語義，就是保證Thread1程式碼塊中的所有程式碼，一定在Thread2程式碼塊的第一條程式碼之前完成。當然，構建這樣的語義有很多方法，我們常用的Mutex、Spinlock、RWLock，都能保證這個語義 (關於happens-before語義的構建，以及為什麼鎖能保證happens-before語義，以後專門寫一篇文章進行討論)。但是，C/C++ Volatile關鍵詞不能保證這個語義，也就意味著C/C++ Volatile關鍵詞，在多執行緒環境下，如果使用的不夠細心，就會產生如同我這裡提到的錯誤。

1. 小結

C/C++ Volatile關鍵詞的第三個特性：”順序性”，能夠保證Volatile變數間的順序性，編譯器不會進行亂序優化。Volatile變數與非Volatile變數的順序，編譯器不保證順序，可能會進行亂序優化。同時，C/C++ Volatile關鍵詞，並不能用於構建happens-before語義，因此在進行多執行緒程式設計時，要小心使用volatile，不要掉入volatile變數的使用陷阱之中。

1. Volatile：Java增強

在介紹了C/C++ Volatile關鍵詞之後，再簡單介紹一下Java的Volatile。與C/C++的Volatile關鍵詞類似，Java的Volatile也有這三個特性，但最大的不同在於：第三個特性，”順序性”，Java的Volatile有很極大的增強，Java Volatile變數的操作，附帶了Acquire與Release語義。所謂的Acquire與Release語義，可參考文章：Acquire and Release Semantics。(這一點，後續有必要的話，可以寫一篇文章專門討論)。Java Volatile所支援的Acquire、Release語義，如下：

• 對於Java Volatile變數的寫操作，帶有Release語義，所有Volatile變數寫操作之前的針對其他任何變數的讀寫操作，都不會被編譯器、CPU優化後，亂序到Volatile變數的寫操作之後執行。
  
• 對於Java Volatile變數的讀操作，帶有Acquire語義，所有Volatile變數讀操作之後的針對其他任何變數的讀寫操作，都不會被編譯器、CPU優化後，亂序到Volatile變數的讀操作之前進行。
  

通過Java Volatile的Acquire、Release語義，對比C/C++ Volatile，可以看出，Java Volatile對於編譯器、CPU的亂序優化，限制的更加嚴格了。Java Volatile變數與非Volatile變數的一些亂序操作，也同樣被禁止。

由於Java Volatile支援Acquire、Release語義，因此Java Volatile，能夠用來構建happens-before語義。也就是說，前面提到的C/C++ Volatile在多執行緒下錯誤的使用場景，在Java語言下，恰好就是正確的。如下圖所示：

1. Volatile的起源

C/C++的Volatile關鍵詞，有三個特性：易變性；不可優化性；順序性。那麼，為什麼Volatile被設計成這樣呢？要回答這個問題，就需要從Volatile關鍵詞的產生說起。(注：這一小節的內容，參考自C++ and the Perils of Double-Checked Locking論文的第10章節：volatile：A Brief History。這是一篇頂頂好的論文，值得多次閱讀，強烈推薦！)

Volatile關鍵詞，最早出現於19世紀70年代，被用於處理memory-mapeed I/O (MMIO)帶來的問題。在引入MMIO之後，一塊記憶體地址，既有可能是真正的記憶體，也有可能被對映到一個I/O埠。相對的，讀寫一個記憶體地址，既有可能操作記憶體，也有可能讀寫的是一個I/O裝置。MMIO為什麼需要引入Volatile關鍵詞？考慮如下的一個程式碼片段：

在此程式碼片段中，指標p既有可能指向一個記憶體地址，也有可能指向一個I/O裝置。如果指標p指向的是I/O裝置，那麼(1)，(2)中的a，b，就會接收到I/O裝置的連續兩個位元組。但是，p也有可能指向記憶體，此時，編譯器的優化策略，就可能會判斷出a，b同時從同一記憶體地址讀取資料，在做完(1)之後，直接將a賦值給b。對於I/O裝置，需要防止編譯器做這個優化，不能假設指標b指向的內容不變——易變性。

同樣，程式碼(3)，(4)也有類似的問題，編譯器發現將a，b同時賦值給指標p是無意義的，因此可能會優化程式碼(3)中的賦值操作，僅僅保留程式碼(4)。對於I/O裝置，需要防止編譯器將寫操作給徹底優化消失了——”不可優化”性。

對於I/O裝置，編譯器不能隨意互動指令的順序，因為順序一變，寫入I/O裝置的內容也就發生變化了——”順序性”。

基於MMIO的這三個需求，設計出來的C/C++ Volatile關鍵詞，所含有的特性，也就是本文前面分析的三個特性：易變性；不可優化性；順序性。

1. 參考資料

[10] Java Glossary. volatile.

轉自： http://hedengcheng.com/?p=725