原文鏈接：https://bestzuo.cn/posts/4234991750.html

在 JSR-133 （也即 JDK1.5 ）之前，volatile 關鍵字一直飽受爭議，因為使用這個關鍵字會造成一些不可預料的后果，從 JSR-133 開始，專家組對這個關鍵字的語義進行了增強，從而使得現(xiàn)在使用 volatile 關鍵字的環(huán)境越來越多，目前它也被稱為是“輕量級的 synchronized”。

并發(fā)編程中的三個概念

volatile 雖然從字面意思上理解比較簡單，但是在實際環(huán)境中能正確的使用該變量并不容易，只有了解其背后的原理，我們才能發(fā)揮出這個關鍵字的重要作用。在理解原理之前，我們有必要先了解一下并發(fā)編程中三個常見的概念：原子性、可見性和順序一致性。

原子性

原子性理解比較簡單，與數(shù)據(jù)庫系統(tǒng)中原子性意思基本一致，即一個操作或者多個操作要么全部執(zhí)行并且執(zhí)行的過程不會被任何因素打斷，要么就都不執(zhí)行。

一個很經(jīng)典的例子就是銀行賬戶轉賬問題：

比如從賬戶 A 向賬戶 B 轉 1000 元，那么必然包括 2 個操作：從賬戶 A 減去 1000 元，往賬戶 B 加上 1000 元。

試想一下，如果這 2 個操作不具備原子性，會造成什么樣的后果。假如從賬戶 A 減去 1000 元之后，操作突然中止。然后又從 B 取出了 500 元，取出 500 元之后，再執(zhí)行往賬戶 B 加上 1000 元的操作。這樣就會導致賬戶 A 雖然減去了 1000 元，但是賬戶 B 沒有收到這個轉過來的 1000 元。

所以這 2 個操作必須要具備原子性才能保證不出現(xiàn)一些意外的問題。

同樣地反映到并發(fā)編程中會出現(xiàn)什么結果呢？

舉個最簡單的例子，大家想一下假如為一個 64 位的變量賦值過程不具備原子性的話，會發(fā)生什么后果？

long i = 9L;

假若一個線程執(zhí)行到這個語句時，我暫且假設為一個 64 位的變量賦值包括兩個過程：為低 32 位賦值，為高 32 位賦值。那么就可能發(fā)生一種情況：當將低 32 位數(shù)值寫入之后，突然被中斷，而此時又有一個線程去讀取 i 的值，那么讀取到的就是錯誤的數(shù)據(jù)。

可見性

可見性是指當多個線程訪問同一個變量時，一個線程修改了這個變量的值，其他線程能夠立即看得到修改的值。即一個線程修改的值能對其它線程可見。

可見性的原理涉及到 Java 內(nèi)存模型，關于其中的 Java 內(nèi)存模型可以參考我的另外一篇博客，以便于下文的理解。

有了 JMM 的概念后，可以舉個簡單的例子，看下面這段代碼：

//線程1執(zhí)行的代碼
int i = 0;
i = 10;
 
//線程2執(zhí)行的代碼
j = i;

假若執(zhí)行線程 1 的是 CPU1 ，執(zhí)行線程 2 的是 CPU2。由上面的分析可知，當線程 1 執(zhí)行 i = 10 這句時，會先把 i 的初始值加載到 CPU1 的高速緩存中，然后賦值為 10，那么在 CPU1 的高速緩存當中 i 的值變?yōu)?10 了，卻沒有立即寫入到主存當中。

此時線程 2 執(zhí)行 j = i，它會先去主存讀取i的值并加載到 CPU2 的緩存當中，注意此時內(nèi)存當中 i 的值還是 0，那么就會使得 j 的值為 0，而不是 10。

這就是可見性問題，線程 1 對變量 i 修改了之后，線程 2 沒有立即看到線程 1 修改的值。

順序一致性

即程序執(zhí)行的順序按照代碼的先后順序執(zhí)行。舉個簡單的例子，看下面這段代碼：

int i = 0;              
boolean flag = false;
i = 1;                //語句1  
flag = true;          //語句2

上面代碼定義了一個 int 型變量，定義了一個 boolean 類型變量，然后分別對兩個變量進行賦值操作。從代碼順序上看，語句 1 是在語句 2 前面的，那么 JVM 在真正執(zhí)行這段代碼的時候會保證語句 1 一定會在語句 2 前面執(zhí)行嗎？不一定，為什么呢？這里可能會發(fā)生指令重排序（Instruction Reorder）。

下面解釋一下什么是指令重排序，一般來說，處理器為了提高程序運行效率，可能會對輸入代碼進行優(yōu)化，它不保證程序中各個語句的執(zhí)行先后順序同代碼中的順序一致，但是它會保證程序最終執(zhí)行結果和代碼順序執(zhí)行的結果是一致的。

比如上面的代碼中，語句 1 和語句 2 誰先執(zhí)行對最終的程序結果并沒有影響，那么就有可能在執(zhí)行過程中，語句 2 先執(zhí)行而語句 1 后執(zhí)行。

但是要注意，雖然處理器會對指令進行重排序，但是它會保證程序最終結果會和代碼順序執(zhí)行結果相同。關于指令重排序的具體細節(jié)可以參考我的另外一篇文章。

volatile的定義

有了并發(fā)編程的三個基本概念后，我們就可以看一下 volatile 相關的定義了。這里引用 JSR-133 中對 volatile 關鍵字的定義：

The Java programming language allows threads to access shared variables (§17.1). As a rule, to ensure that shared variables are consistently and reliably updated, a thread should ensure that it has exclusive use of such variables by obtaining a lock that, conventionally, enforces mutual exclusion for those shared variables.

The Java programming language provides a second mechanism, volatile fields, that is more convenient than locking for some purposes.

A field may be declared volatile, in which case the Java Memory Model ensures that all threads see a consistent value for the variable (§17.4).

簡單翻譯一下：

Java編程語言中允許線程訪問共享變量。為了確保共享變量能被一致地和可靠的更新，線程必須確保它是排他性的使用此共享變量，通常都是獲得對這些共享變量強制排他性的同步鎖。

Java編程語言提供了另一種機制，volatile 域變量，對于某些場景的使用這要更加的方便。

可以把變量聲明為 volatile，以讓 Java 內(nèi)存模型來保證所有線程都能看到這個變量的同一個值。

簡而言之，volatile 相當于提供了一種同步機制，從而保證被 volatile 關鍵字聲明的變量對所有線程的可見性，并且 volatile 不會引起線程上下文的切換和調度，比 synchronized 的執(zhí)行成本要更低。

volatile內(nèi)存語義

有了 volatile 的定義后，我們比較疑惑的地方就是， volatile 提供了一種什么樣的“同步機制”，是如何保證變量對所有線程的可見性的。只要理解了這兩個問題的原理，volatile 關鍵字就沒有那么可怕了。

實際上， 一旦一個共享變量（類的成員變量、類的靜態(tài)成員變量）被 volatile 修飾之后，那么就具備了兩層語義：

1. 保證了不同線程對這個變量進行操作時的可見性，即一個線程修改了某個變量的值，這新值對其他線程來說是立即可見的
2. 禁止進行指令重排序

對上面兩層語義，我們逐步進行解析。

volatile 的特性

當我們聲明共享變量為 volatile 后，對這個變量的讀 / 寫將會很特別。理解 volatile 特性的一個好方法是：把對 volatile 變量的單個讀 / 寫，看成是使用同一個監(jiān)視器鎖對這些單個讀 / 寫操作做了同步。下面我們通過具體的示例來說明，請看下面的示例代碼：

class VolatileFeaturesExample {
    volatile long vl = 0L;  // 使用 volatile 聲明 64 位的 long 型變量 

    public void set(long l) {
        vl = l;   // 單個 volatile 變量的寫 
    }

    public void getAndIncrement () {
        vl++;    // 復合（多個）volatile 變量的讀 / 寫 
    }

    public long get() {
        return vl;   // 單個 volatile 變量的讀 
    }
}

假設有多個線程分別調用上面程序的三個方法，這個程序在語意上和下面程序等價：

class VolatileFeaturesExample {
    long vl = 0L;               // 64 位的 long 型普通變量 

    public synchronized void set(long l) {     // 對單個的普通 變量的寫用同一個監(jiān)視器同步 
        vl = l;
    }

    public void getAndIncrement () { // 普通方法調用 
        long temp = get();           // 調用已同步的讀方法 
        temp += 1L;                  // 普通寫操作 
        set(temp);                   // 調用已同步的寫方法 
    }
    public synchronized long get() { 
    // 對單個的普通變量的讀用同一個監(jiān)視器同步 
        return vl;
    }
}

如上面示例程序所示，對一個 volatile 變量的單個讀 / 寫操作，與對一個普通變量的讀 / 寫操作使用同一個監(jiān)視器鎖來同步，它們之間的執(zhí)行效果相同。

監(jiān)視器鎖的 happens-before 規(guī)則保證釋放監(jiān)視器和獲取監(jiān)視器的兩個線程之間的內(nèi)存可見性，這意味著對一個 volatile 變量的讀，總是能看到（任意線程）對這個 volatile 變量最后的寫入。

監(jiān)視器鎖的語義決定了臨界區(qū)代碼的執(zhí)行具有原子性。這意味著即使是 64 位的 long 型和 double 型變量，只要它是 volatile 變量，對該變量的讀寫就將具有原子性。如果是多個 volatile 操作或類似于 volatile++ 這種復合操作，這些操作整體上不具有原子性。

簡而言之，volatile 變量自身具有下列特性：

• 可見性：對一個 volatile 變量的讀，總是能看到（任意線程）對這個 volatile 變量最后的寫入。
• 原子性：對任意單個 volatile 變量的讀 / 寫具有原子性，但類似于 volatile++ 這種復合操作不具有原子性。

volatile 寫 - 讀建立的 happens before 關系

上面講的是 volatile 變量自身的特性，對程序員來說，volatile 對線程的內(nèi)存可見性的影響比 volatile 自身的特性更為重要，也更需要我們?nèi)リP注。

從 JSR-133 開始，volatile 變量的寫 - 讀可以實現(xiàn)線程之間的通信。

從內(nèi)存語義的角度來說，volatile 與監(jiān)視器鎖有相同的效果：volatile 寫和監(jiān)視器的釋放有相同的內(nèi)存語義；volatile 讀與監(jiān)視器的獲取有相同的內(nèi)存語義。

請看下面使用 volatile 變量的示例代碼：

class VolatileExample {
    int a = 0;
    volatile boolean flag = false;

    public void writer() {
        a = 1;                   //1
        flag = true;             //2
    }

    public void reader() {
        if (flag) {               //3
            int i =  a;           //4
            ……
        }
    }
}

假設線程 A 執(zhí)行 writer() 方法之后，線程 B 執(zhí)行 reader() 方法。根據(jù) happens before 規(guī)則，這個過程建立的 happens before 關系可以分為兩類：

1. 根據(jù)程序次序規(guī)則，1 happens before 2; 3 happens before 4。
2. 根據(jù) volatile 規(guī)則，2 happens before 3。
3. 根據(jù) happens before 的傳遞性規(guī)則，1 happens before 4。

上述 happens before 關系的圖形化表現(xiàn)形式如下：

image

在上圖中，每一個箭頭鏈接的兩個節(jié)點，代表了一個 happens before 關系。黑色箭頭表示程序順序規(guī)則；橙色箭頭表示 volatile 規(guī)則；藍色箭頭表示組合這些規(guī)則后提供的 happens before 保證。

這里 A 線程寫一個 volatile 變量后，B 線程讀同一個 volatile 變量。A 線程在寫 volatile 變量之前所有可見的共享變量，在 B 線程讀同一個 volatile 變量后，將立即變得對 B 線程可見。

volatile 寫 - 讀的內(nèi)存語義

volatile 寫的內(nèi)存語義如下：

當寫一個 volatile 變量時，JMM 會把該線程對應的本地內(nèi)存中的共享變量刷新到主內(nèi)存。

以上面示例程序 VolatileExample 為例，假設線程 A 首先執(zhí)行 writer() 方法，隨后線程 B 執(zhí)行 reader() 方法，初始時兩個線程的本地內(nèi)存中的 flag 和 a 都是初始狀態(tài)。下圖是線程 A 執(zhí)行 volatile 寫后，共享變量的狀態(tài)示意圖：

image

如上圖所示，線程 A 在寫 flag 變量后，本地內(nèi)存 A 中被線程 A 更新過的兩個共享變量的值被刷新到主內(nèi)存中。此時，本地內(nèi)存 A 和主內(nèi)存中的共享變量的值是一致的。

volatile 讀的內(nèi)存語義如下：

當讀一個 volatile 變量時，JMM 會把該線程對應的本地內(nèi)存置為無效。線程接下來將從主內(nèi)存中讀取共享變量。

下面是線程 B 讀同一個 volatile 變量后，共享變量的狀態(tài)示意圖：

image

如上圖所示，在讀 flag 變量后，本地內(nèi)存 B 已經(jīng)被置為無效。此時，線程 B 必須從主內(nèi)存中讀取共享變量。線程 B 的讀取操作將導致本地內(nèi)存 B 與主內(nèi)存中的共享變量的值也變成一致的了。

如果我們把 volatile 寫和 volatile 讀這兩個步驟綜合起來看的話，在讀線程 B 讀一個 volatile 變量后，寫線程 A 在寫這個 volatile 變量之前所有可見的共享變量的值都將立即變得對讀線程 B 可見。

下面對 volatile 寫和 volatile 讀的內(nèi)存語義做個總結：

• 線程 A 寫一個 volatile 變量，實質上是線程 A 向接下來將要讀這個 volatile 變量的某個線程發(fā)出了（其對共享變量所在修改的）消息。
• 線程 B 讀一個 volatile 變量，實質上是線程 B 接收了之前某個線程發(fā)出的（在寫這個 volatile 變量之前對共享變量所做修改的）消息。
• 線程 A 寫一個 volatile 變量，隨后線程 B 讀這個 volatile 變量，這個過程實質上是線程 A 通過主內(nèi)存向線程 B 發(fā)送消息。

volatile 內(nèi)存語義的實現(xiàn)

下面，讓我們來看看 JMM 如何實現(xiàn) volatile 寫 / 讀的內(nèi)存語義。

前文我們提到過重排序分為編譯器重排序和處理器重排序。為了實現(xiàn) volatile 內(nèi)存語義，JMM 會分別限制這兩種類型的重排序類型。下面是 JMM 針對編譯器制定的 volatile 重排序規(guī)則表：

舉例來說，第三行最后一個單元格的意思是：在程序順序中，當?shù)谝粋€操作為普通變量的讀或寫時，如果第二個操作為 volatile 寫，則編譯器不能重排序這兩個操作。

從上表我們可以看出：

• 當?shù)诙€操作是 volatile 寫時，不管第一個操作是什么，都不能重排序。這個規(guī)則確保 volatile 寫之前的操作不會被編譯器重排序到 volatile 寫之后。
• 當?shù)谝粋€操作是 volatile 讀時，不管第二個操作是什么，都不能重排序。這個規(guī)則確保 volatile 讀之后的操作不會被編譯器重排序到 volatile 讀之前。
• 當?shù)谝粋€操作是 volatile 寫，第二個操作是 volatile 讀時，不能重排序。

為了實現(xiàn) volatile 的內(nèi)存語義，編譯器在生成字節(jié)碼時，會在指令序列中插入內(nèi)存屏障來禁止特定類型的處理器重排序。對于編譯器來說，發(fā)現(xiàn)一個最優(yōu)布置來最小化插入屏障的總數(shù)幾乎不可能，為此，JMM 采取保守策略。下面是基于保守策略的 JMM 內(nèi)存屏障插入策略：

• 在每個 volatile 寫操作的前面插入一個 StoreStore 屏障。
• 在每個 volatile 寫操作的后面插入一個 StoreLoad 屏障。
• 在每個 volatile 讀操作的后面插入一個 LoadLoad 屏障。
• 在每個 volatile 讀操作的后面插入一個 LoadStore 屏障。

上述內(nèi)存屏障插入策略非常保守，但它可以保證在任意處理器平臺，任意的程序中都能得到正確的 volatile 內(nèi)存語義。

下面是保守策略下，volatile 寫插入內(nèi)存屏障后生成的指令序列示意圖：

image

上圖中的 StoreStore 屏障可以保證在 volatile 寫之前，其前面的所有普通寫操作已經(jīng)對任意處理器可見了。這是因為 StoreStore 屏障將保障上面所有的普通寫在 volatile 寫之前刷新到主內(nèi)存。

這里比較有意思的是 volatile 寫后面的 StoreLoad 屏障。這個屏障的作用是避免 volatile 寫與后面可能有的 volatile 讀 / 寫操作重排序。因為編譯器常常無法準確判斷在一個 volatile 寫的后面，是否需要插入一個 StoreLoad 屏障（比如，一個 volatile 寫之后方法立即 return）。為了保證能正確實現(xiàn) volatile 的內(nèi)存語義，JMM 在這里采取了保守策略：在每個 volatile 寫的后面或在每個 volatile 讀的前面插入一個 StoreLoad 屏障。從整體執(zhí)行效率的角度考慮，JMM 選擇了在每個 volatile 寫的后面插入一個 StoreLoad 屏障。因為 volatile 寫 - 讀內(nèi)存語義的常見使用模式是：一個寫線程寫 volatile 變量，多個讀線程讀同一個 volatile 變量。當讀線程的數(shù)量大大超過寫線程時，選擇在 volatile 寫之后插入 StoreLoad 屏障將帶來可觀的執(zhí)行效率的提升。從這里我們可以看到 JMM 在實現(xiàn)上的一個特點：首先確保正確性，然后再去追求執(zhí)行效率。

下面是在保守策略下，volatile 讀插入內(nèi)存屏障后生成的指令序列示意圖：

image

上圖中的 LoadLoad 屏障用來禁止處理器把上面的 volatile 讀與下面的普通讀重排序。LoadStore 屏障用來禁止處理器把上面的 volatile 讀與下面的普通寫重排序。

上述 volatile 寫和 volatile 讀的內(nèi)存屏障插入策略非常保守。在實際執(zhí)行時，只要不改變 volatile 寫 - 讀的內(nèi)存語義，編譯器可以根據(jù)具體情況省略不必要的屏障。下面我們通過具體的示例代碼來說明：

class VolatileBarrierExample {
    int a;
    volatile int v1 = 1;
    volatile int v2 = 2;

    void readAndWrite() {
        int i = v1;           // 第一個 volatile 讀 
        int j = v2;           // 第二個 volatile 讀 
        a = i + j;            // 普通寫 
        v1 = i + 1;          // 第一個 volatile 寫 
        v2 = j * 2;          // 第二個 volatile 寫 
    }

    …                    // 其他方法 
}

針對 readAndWrite() 方法，編譯器在生成字節(jié)碼時可以做如下的優(yōu)化：

image

注意，最后的 StoreLoad 屏障不能省略。因為第二個 volatile 寫之后，方法立即 return。此時編譯器可能無法準確斷定后面是否會有 volatile 讀或寫，為了安全起見，編譯器常常會在這里插入一個 StoreLoad 屏障。

上面的優(yōu)化是針對任意處理器平臺，由于不同的處理器有不同“松緊度”的處理器內(nèi)存模型，內(nèi)存屏障的插入還可以根據(jù)具體的處理器內(nèi)存模型繼續(xù)優(yōu)化。以 x86 處理器為例，上圖中除最后的 StoreLoad 屏障外，其它的屏障都會被省略。

前面保守策略下的 volatile 讀和寫，在 x86 處理器平臺可以優(yōu)化成：

image

前文提到過，x86 處理器僅會對寫 - 讀操作做重排序。X86 不會對讀 - 讀，讀 - 寫和寫 - 寫操作做重排序，因此在 x86 處理器中會省略掉這三種操作類型對應的內(nèi)存屏障。在 x86 中，JMM 僅需在 volatile 寫后面插入一個 StoreLoad 屏障即可正確實現(xiàn) volatile 寫 - 讀的內(nèi)存語義。這意味著在 x86 處理器中，volatile 寫的開銷比 volatile 讀的開銷會大很多（因為執(zhí)行 StoreLoad 屏障開銷會比較大）。

JSR-133 為什么要增強 volatile 的內(nèi)存語義

在 JSR-133 之前的舊 Java 內(nèi)存模型中，雖然不允許 volatile 變量之間重排序，但舊的 Java 內(nèi)存模型允許 volatile 變量與普通變量之間重排序。在舊的內(nèi)存模型中，VolatileExample 示例程序可能被重排序成下列時序來執(zhí)行：

image

在舊的內(nèi)存模型中，當 1 和 2 之間沒有數(shù)據(jù)依賴關系時，1 和 2 之間就可能被重排序（3 和 4 類似）。其結果就是：讀線程 B 執(zhí)行 4 時，不一定能看到寫線程 A 在執(zhí)行 1 時對共享變量的修改。

因此在舊的內(nèi)存模型中 ，volatile 的寫 - 讀沒有監(jiān)視器的釋放 - 獲所具有的內(nèi)存語義。為了提供一種比監(jiān)視器鎖更輕量級的線程之間通信的機制，JSR-133 專家組決定增強 volatile 的內(nèi)存語義：嚴格限制編譯器和處理器對 volatile 變量與普通變量的重排序，確保 volatile 的寫 - 讀和監(jiān)視器的釋放 - 獲取一樣，具有相同的內(nèi)存語義。從編譯器重排序規(guī)則和處理器內(nèi)存屏障插入策略來看，只要 volatile 變量與普通變量之間的重排序可能會破壞 volatile 的內(nèi)存語意，這種重排序就會被編譯器重排序規(guī)則和處理器內(nèi)存屏障插入策略禁止。

由于 volatile 僅僅保證對單個 volatile 變量的讀 / 寫具有原子性，而監(jiān)視器鎖的互斥執(zhí)行的特性可以確保對整個臨界區(qū)代碼的執(zhí)行具有原子性。在功能上，監(jiān)視器鎖比 volatile 更強大；在可伸縮性和執(zhí)行性能上，volatile 更有優(yōu)勢。如果想在程序中用 volatile 代替監(jiān)視器鎖，請一定謹慎。

volatile的使用場景

在了解了 volatile 關鍵字的原理之后，我們可以做一個小結，volatile 關鍵字可以為一個變量提供一種同步訪問機制，如果一個變量被聲明為 volatile ，那么編譯器和 JVM 就知道該變量是可能被另一個線程并發(fā)更新的。

<div class="note info">那么 volatile 關鍵字能提供這種機制的原理就是，如果寫入 volatile 聲明的變量，JMM 會通過強制將本地內(nèi)存刷新到主內(nèi)存中，如果讀取 volatile 聲明的變量， JMM 會將本地內(nèi)存置為無效，同時強制從主內(nèi)存中讀取該變量數(shù)據(jù)到本地內(nèi)存中，從而通過這個機制保證 volatile 變量的可見性。另一方面，volatile 變量在讀/寫時會在每個操作前后插入一個內(nèi)存屏障，從而禁止編譯器和處理器指令重排序以保證其語義。</div>

那么可以引申出 volatile 變量的使用場景，要使 volatile 變量提供理想的線程安全，必須同時滿足下面兩個條件：

• 對變量的寫操作不依賴于當前值。
• 該變量沒有包含在具有其他變量的不變式中。

作為狀態(tài)標志

使用 volatile 聲明的布爾類型變量，可以在一些情景中達到很好的效果，比如如下從一個線程終止另外一個線程。

反例：

private static boolean stopThread;
public static void main(String[] args) throws InterruptedException {
   Thread th = new Thread(new Runnable() {
      @Override
      public void run() {
         int i = 0;
         while (!stopThread) {
            i++;
         }
      }
   });
   th.start();
   TimeUnit.SECONDS.sleep(2);
   stopThread = true;
}

運行后發(fā)現(xiàn)該程序根本無法終止循環(huán)，原因是，Java 語言規(guī)范并不保證一個線程寫入的值對另外一個線程是可見的，所以即使主線程 main 函數(shù)修改了共享變量 stopThread 狀態(tài)，但是對 th 線程并不一定可見，最終導致循環(huán)無法終止。

正例：

private static volatile boolean stopThread;
public static void main(String[] args) throws InterruptedException {
   Thread th = new Thread(new Runnable() {
      @Override
      public void run() {
         int i = 0;
         while (!stopThread) {
            i++;
         }
      }
   });
   th.start();
   TimeUnit.SECONDS.sleep(2);
   stopThread = true;
}

通過使用關鍵字 volatile 修飾共享變量 stopThread，根據(jù) volatile 的可見性原則可以保證主線程 main 函數(shù)修改了共享變量 stopThread 狀態(tài)后對線程 th 來說是立即可見的，所以在兩秒內(nèi)線程 th 將停止循環(huán)。

雙重檢查鎖

可以作為單例模式的一種實現(xiàn)方法，具體為什么要這么實現(xiàn)可以參考我的另外一篇博客。

public class Singleton {
    private volatile static Singleton uniqueSingleton;

    private Singleton() {
    }

    public Singleton getInstance() {
        if (null == uniqueSingleton) {
            synchronized (Singleton.class) {
                if (null == uniqueSingleton) {
                    uniqueSingleton = new Singleton();
                }
            }
        }
        return uniqueSingleton;
    }
}

參考文章

1. 方騰飛等 著 《Java 并發(fā)編程的藝術》
2. Java理論與實踐：正確使用 Volatile 變量
3. 聊聊并發(fā)（一）深入分析Volatile的實現(xiàn)原理
4. Java并發(fā)編程：volatile關鍵字解析
5. Java關鍵字volatile的理解與正確使用
6. JSR-133: JavaTM Memory Model and Thread Specification
7. The JSR-133 Cookbook for Compiler Writers