一、64位寫入的原子性（Half Write）

如，對于一個long型變量的賦值和取值操作而言，在多線程場景下，線程A調用set(100)，線程B調 用get()，在某些場景下，返回值可能不是100。

因為JVM的規范并沒有要求64位的long或者double的寫入是原子的。在32位的機器上，一個64位變 量的寫入可能被拆分成兩個32位的寫操作來執行。這樣一來，讀取的線程就可能讀到“一半的值”。解決 辦法也很簡單，在long前面加上volatile關鍵字。

二、重排序：DCL問題

單例模式的線程安全的寫法不止一種，常用寫法為DCL（Double Checking Locking），如下所示：

上述的 instance = new Singleton(); 代碼有問題：其底層會分為三個操作：

1. 分配一塊內存。

2. 在內存上初始化成員變量。

3. 把instance引用指向內存。

在這三個操作中，操作2和操作3可能重排序，即先把instance指向內存，再初始化成員變量，因為 二者并沒有先后的依賴關系。此時，另外一個線程可能拿到一個未完全初始化的對象。這時，直接訪問 里面的成員變量，就可能出錯。這就是典型的“構造方法溢出”問題。 解決辦法也很簡單，就是為instance變量加上volatile修飾。

volatile的三重功效：64位寫入的原子性、內存可見性和禁止重排序。

三、volatile實現原理

由于不同的CPU架構的緩存體系不一樣，重排序的策略不一樣，所提供的內存屏障指令也就有差 異。 這里只探討為了實現volatile關鍵字的語義的一種參考做法：

1. 在volatile寫操作的前面插入一個StoreStore屏障。保證volatile寫操作不會和之前的寫操作重 排序。

2. 在volatile寫操作的后面插入一個StoreLoad屏障。保證volatile寫操作不會和之后的讀操作重 排序。

3. 在volatile讀操作的后面插入一個LoadLoad屏障+LoadStore屏障。保證volatile讀操作不會和 之后的讀操作、寫操作重排序。

具體到x86平臺上，其實不會有LoadLoad、LoadStore和StoreStore重排序，只有StoreLoad一種 重排序（內存屏障），也就是只需要在volatile寫操作后面加上StoreLoad屏障。

四、JSR-133對volatile語義的增強

在JSR -133之前的舊內存模型中，一個64位long/ double型變量的讀/ 寫操作可以被拆分為兩個32位 的讀/寫操作來執行。從JSR -133內存模型開始 （即從JDK5開始），僅僅只允許把一個64位long/ double 型變量的寫操作拆分為兩個32位的寫操作來執行，任意的讀操作在JSR -133中都必須具有原子性（即 任 意讀操作必須要在單個讀事務中執行）。