8000+字，就說一個字Volatile

来源:https://www.cnblogs.com/jiagooushi/archive/2023/02/24/17151400.html
-Advertisement-
Play Games

簡介 volatile是Java提供的一種輕量級的同步機制。Java 語言包含兩種內在的同步機制：同步塊（或方法）和 volatile 變數，相比於synchronized（synchronized通常稱為重量級鎖），volatile更輕量級，因為它不會引起線程上下文的切換和調度。但是volatil ...


簡介

volatile是Java提供的一種輕量級的同步機制。Java 語言包含兩種內在的同步機制：同步塊（或方法）和 volatile 變數，相比於synchronized（synchronized通常稱為重量級鎖），volatile更輕量級，因為它不會引起線程上下文的切換和調度。但是volatile 變數的同步性較差（有時它更簡單並且開銷更低），而且其使用也更容易出錯。

Java volatile關鍵字用於將Java變數標記為“存儲在主存儲器中”。更確切地說，這意味著，每次讀取一個volatile變數都將從電腦的主記憶體中讀取，而不是從CPU緩存中讀取，並且每次寫入volatile變數都將寫入主記憶體，而不僅僅是CPU緩存。

實際上，自Java 5以來，volatile關鍵字保證的不僅僅是向主存儲器寫入和讀取volatile變數。我將在以下部分解釋。

特性

可以把對volatile變數的單個讀/寫，看成是使用同一個鎖對這些單個讀/寫操作做了同步

當我們聲明共用變數為volatile後，對這個變數的讀/寫將會很特別。理解volatile特性的一個好方法是：把對volatile變數的單個讀/寫，看成是使用同一個鎖對這些單個讀/寫操作做了同步。

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

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

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

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

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

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

    //對單個的普通 變數的寫用同一個鎖同步
    public synchronized void set(long l) {             
       vl = l;
    }

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

如上面示常式序所示，對一個volatile變數的單個讀/寫操作，與對一個普通變數的讀/寫操作使用同一個鎖來同步，它們之間的執行效果相同。

鎖的happens-before規則保證釋放鎖和獲取鎖的兩個線程之間的記憶體可見性，這意味著對一個volatile變數的讀，總是能看到（任意線程）對這個volatile變數最後的寫入。

鎖的語義決定了臨界區代碼的執行具有原子性。這意味著即使是64位的long型和double型變數，只要它是volatile變數，對該變數的讀寫就將具有原子性。如果是多個volatile操作或類似於volatile++這種複合操作，這些操作整體上不具有原子性。

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

原子性

即一個操作或者多個操作 要麼全部執行並且執行的過程不會被任何因素打斷，要麼就都不執行。

原子性是拒絕多線程操作的，不論是多核還是單核，具有原子性的量，同一時刻只能有一個線程來對它進行操作。簡而言之，在整個操作過程中不會被線程調度器中斷的操作，都可認為是原子性。例如 a=1是原子性操作，但是a++和a +=1就不是原子性操作。Java中的原子性操作包括：

  • 基本類型的讀取和賦值操作，且賦值必須是數字賦值給變數，變數之間的相互賦值不是原子性操作。
  • 所有引用reference的賦值操作
  • java.concurrent.Atomic.* 包中所有類的一切操作

可見性

指當多個線程訪問同一個變數時，一個線程修改了這個變數的值，其他線程能夠立即看得到修改的值。

在多線程環境下，一個線程對共用變數的操作對其他線程是不可見的。Java提供了volatile來保證可見性，當一個變數被volatile修飾後，表示著線程本地記憶體無效，當一個線程修改共用變數後他會立即被更新到主記憶體中，其他線程讀取共用變數時，會直接從主記憶體中讀取。當然，synchronize和Lock都可以保證可見性。synchronized和Lock能保證同一時刻只有一個線程獲取鎖然後執行同步代碼，並且在釋放鎖之前會將對變數的修改刷新到主存當中。因此可以保證可見性。

線上程使用非volatile變數的多線程應用程式中，出於性能原因，每個線程可以在處理它們時將變數從主存儲器拷貝到CPU高速緩存中。如果您的電腦包含多個CPU，則每個線程可以在不同的CPU上運行。這意味著，每個線程都可以將變數複製到不同CPU的CPU緩存中。這在這裡說明：

img

對於volatile變數，無法保證Java虛擬機（JVM）何時將數據從主記憶體讀取到CPU緩存中，或將數據從CPU緩存寫入主記憶體。這可能會導致一些問題，我將在以下部分中解釋。

想象一下兩個或多個線程可以訪問共用對象的情況，該共用對象包含一個聲明如下的計數器變數：

COPYpublic class SharedObject {
    public int counter = 0;
}

再想象一下，只有線程1對counter變數進行增加操作，但線程1和線程2都可能讀取變數counter。

如果counter變數未聲明volatile，則無法保證何時將counter變數的值從CPU緩存寫回主存儲器。這意味著，CPU高速緩存中的counter變數值可能與主存儲器中的變數值不同。這種情況如下所示：

img

線程沒有看到變數的最新值的問題，是因為它還沒有被另一個線程寫回主記憶體，這被稱為“可見性”問題，其他線程看不到一個線程的某些更新。

volatile可見性保證

Java volatile關鍵字旨在解決變數可見性問題。通過使用volatile聲明counter變數，對變數counter的所有寫操作都將立即寫回主存儲器。此外，counter變數的所有讀取都將直接從主存儲器中讀取。

下麵是counter變數聲明為volatile的樣子：

COPYpublic class SharedObject {
    public volatile int counter = 0;
}

聲明變數為volatile，對其他線程寫入該變數 保證了可見性。

在上面給出的場景中，一個線程（T1）修改計數器，另一個線程（T2）讀取計數器（但從不修改它），聲明該counter變數為volatile足以保證寫入counter變數對T2的可見性。

但是，如果T1和T2都在增加counter變數，那麼聲明counter變數為volatile就不夠了。稍後會詳細介紹。

完全volatile可見性保證

實際上，Java volatile的可見性保證超出了volatile變數本身。可見性保證如下：

  • 如果線程A寫入volatile變數並且線程B隨後讀取這個volatile變數，則在寫入volatile變數之前對線程A可見的所有變數線上程B讀取volatile變數後也將對線程B可見。
  • 如果線程A讀取volatile變數，則讀取volatile變數時對線程A可見的所有變數也將從主存儲器重新讀取。

讓我用代碼示例說明：

COPYpublic class MyClass {
    private int years;
    private int months
    private volatile int days;

    public void update(int years, int months, int days){
        this.years  = years;
        this.months = months;
        this.days   = days;
    }
}

udpate()方法寫入三個變數，其中只有days是volatile變數。

完全volatile可見性保證意味著，當將一個值寫入days時，對線程可見的其他所有變數也會寫入主存儲器。這意味著，當一個值被寫入days，years和months的值也被寫入主存儲器(註意days的寫入在最後)。

當讀取years，months和days的值你可以這樣做：

COPYpublic class MyClass {
    private int years;
    private int months
    private volatile int days;

    public int totalDays() {
        int total = this.days;
        total += months * 30;
        total += years * 365;
        return total;
    }

    public void update(int years, int months, int days){
        this.years  = years;
        this.months = months;
        this.days   = days;
    }
}

註意totalDays()方法通過讀取days的值到total變數中開始。當讀取days的值時，後續months 和years值的讀取也會從主存儲器中讀取。因此使用上述讀取序列可以保證看到最新的days，months和years值。

有序性

即程式執行的順序按照代碼的先後順序執行。

java記憶體模型中的有序性可以總結為：如果在本線程內觀察，所有操作都是有序的；如果在一個線程中觀察另一個線程，所有操作都是無序的。前半句是指“線程內表現為串列語義”，後半句是指“指令重排序”現象和“工作記憶體主主記憶體同步延遲”現象。
​ 在Java記憶體模型中，為了效率是允許編譯器和處理器對指令進行重排序，當然重排序不會影響單線程的運行結果，但是對多線程會有影響。Java提供volatile來保證一定的有序性。最著名的例子就是單例模式裡面的DCL（雙重檢查鎖）。另外，可以通過synchronized和Lock來保證有序性，synchronized和Lock保證每個時刻是有一個線程執行同步代碼，相當於是讓線程順序執行同步代碼，自然就保證了有序性。

volatile變數的特性

保證可見性，不保證原子性

img

  • 當寫一個volatile變數時，JMM會把該線程本地記憶體中的變數強制刷新到主記憶體中去；
  • 這個寫會操作會導致其他線程中的緩存無效。

禁止指令重排

重排序是指編譯器和處理器為了優化程式性能而對指令序列進行排序的一種手段。重排序需要遵守一定規則：

  • 重排序操作不會對存在數據依賴關係的操作進行重排序。

    比如：a=1;b=a; 這個指令序列，由於第二個操作依賴於第一個操作，所以在編譯時和處理器運

    行時這兩個操作不會被重排序。

  • 重排序是為了優化性能，但是不管怎麼重排序，單線程下程式的執行結果不能被改變

    比如：a=1;b=2;c=a+b這三個操作，第一步（a=1)和第二步(b=2)由於不存在數據依賴關係， 所以可能會發

生重排序，但是c=a+b這個操作是不會被重排序的，因為需要保證最終的結果一定是c=a+b=3。

重排序在單線程下一定能保證結果的正確性，但是在多線程環境下，可能發生重排序，影響結果，下例中的1和2由於不存在數據依賴關係，則有可能會被重排序，先執行status=true再執行a=2。而此時線程B會順利到達4處，而線程A中a=2這個操作還未被執行，所以b=a+1的結果也有可能依然等於2。

指令重排序

出於性能原因允許JVM和CPU重新排序程式中的指令，只要指令的語義含義保持不變即可。例如，查看下麵的指令：

COPYint a = 1;
int b = 2;

a++;
b++;

這些指令可以按以下順序重新排序，而不會丟失程式的語義含義：

COPYint a = 1;
a++;

int b = 2;
b++;

然而，當其中一個變數是volatile變數時，指令重排序會出現一個挑戰。讓我們看看MyClass這個前面Java volatile教程中的例子中出現的類：

COPYpublic class MyClass {
    private int years;
    private int months
    private volatile int days;

    public void update(int years, int months, int days){
        this.years  = years;
        this.months = months;
        this.days   = days;
    }
}

一旦update()方法寫入一個值days，新寫入的值，以years和months也被寫入主存儲器。但是，如果JVM重新排序指令，如下所示：

COPYpublic void update(int years, int months, int days){
    this.days   = days;
    this.months = months;
    this.years  = years;
}

當days變數被修改時months和years的值仍然寫入主記憶體中，但是這一次它發生在新的值被寫入months和years之前，也就是這兩個變數的舊值會寫入主存中，後面兩句的寫入操作只是寫到緩存中。因此，新值不能正確地對其他線程可見。重新排序的指令的語義含義已經改變。

happens before

上面講的是volatile變數自身的特性，對程式員來說，volatile對線程的記憶體可見性的影響比volatile自身的特性更為重要，也更需要我們去關註。

從JSR-133開始，volatile變數的寫-讀可以實現線程之間的通信。

從記憶體語義的角度來說，volatile與鎖有相同的效果：volatile寫和鎖的釋放有相同的記憶體語義；volatile讀與鎖的獲取有相同的記憶體語義。

請看下麵使用volatile變數的示例代碼：

COPYclass 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執行writer()方法之後，線程B執行reader()方法。根據happens before規則，這個過程建立的happens before 關係可以分為兩類：

  1. 根據程式次序規則，1 happens before 2; 3 happens before 4。
  2. 根據volatile規則，2 happens before 3。
  3. 根據happens before 的傳遞性規則，1 happens before 4。

上述happens before 關係的圖形化表現形式如下：

img

上圖中，每一個箭頭鏈接的兩個節點，代表了一個happens before 關係。黑色箭頭表示程式順序規則；橙色箭頭表示volatile規則；藍色箭頭表示組合這些規則後提供的happens before保證。

這裡A線程寫一個volatile變數後，B線程讀同一個volatile變數。A線程在寫volatile變數之前所有可見的共用變數，在B線程讀同一個volatile變數後，將立即變得對B線程可見。

Happens-Before 保證

為瞭解決指令重排序挑戰，除了可見性保證之外，Java volatile關鍵字還提供“happens-before”保證。happens-before保證保證：

volatile 之前讀寫

如果讀取/寫入最初發生在寫入volatile變數之前，讀取/寫入其他變數不能重新排序在寫入volatile變數之後。
​ 寫入volatile變數之前的讀/寫操作被保證 “happen before” 寫入volatile變數。請註意，發生在寫入volatile變數之後的讀/寫操作依然可以重排序到寫入volatile變數前，只是不能相反。允許從後到前，但不允許從前到後。

volatile 之後讀寫

如果讀/寫操作最初發生在讀取volatile變數之後，則讀取/寫入其他變數不能重排序到發生在讀取volatile變數之前。請註意，發生在讀取volatile變數之前的讀/寫操作依然可以重排序到讀取volatile變數後，只是不能相反。允許從前到後，但不允許從後到前。

上述 “happens-before”規則保證確保volatile關鍵字的可見性保證在強制執行。

COPYpublic class VolatileTest {
    private volatile int vi = 1;
    private int i = 2;
    private int i2 = 3;

    @Test
    public void test() {
        System.out.println(i);      //1  讀取普通變數
        i=3;                        //2  寫入普通變數

        //1 2 不能重排序到3之後，操作4可以重排序到3前面
        vi = 2;                     //3  寫入volatile變數
        i2 = 5;                     //4  寫入普通變數
    }

    @Test
    public void test2() {
        System.out.println(i);      //1  讀取普通變數

        //3不能重排序到在2前，但1可以重排序到2後
        System.out.println(vi);     //2  讀取volatile變數
        System.out.println(i2);     //3  讀取普通變數
    }
}

volatile註意事項

volatile 線程不安全

即使volatile關鍵字保證volatile變數的所有讀取直接從主存儲器讀取，並且所有對volatile變數的寫入都直接寫入主存儲器，仍然存在聲明volatile變數線程不安全。

在前面解釋的情況中，只有線程1寫入共用counter變數，聲明counter變數為volatile足以確保線程2始終看到最新的寫入值。

實際上，如果寫入volatile變數的新值不依賴於其先前的值，則甚至可以多個線程寫入共用變數，並且仍然可以在主存儲器中存儲正確的值。換句話說，就是將值寫入共用volatile變數的線程開始並不需要讀取其舊值來計算其下一個值。

一旦線程需要首先讀取volatile變數的舊值，並且基於該值為共用volatile變數生成新值，volatile變數就不再足以保證正確的可見性。讀取volatile 變數和寫入新值之間的短時間間隔會產生競爭條件 ，其中多個線程可能讀取volatile變數的同一個舊值，然後為其生成新值，並將該值寫回主記憶體 - 覆蓋彼此的值。

多個線程遞增同一個計數器的情況正是 volatile變數並不安全的情況。以下部分更詳細地解釋了這種情況。

想象一下，如果線程1將值為0的共用變數counter讀入其CPU高速緩存，將其增加到1並且不將更改的值寫回主存儲器。然後，線程2也從主存儲器讀取相同的counter變數進入自己的CPU高速緩存，其中變數的值仍為0。然後，線程2也將計數器遞增到1，也不將其寫回主存儲器。這種情況如下圖所示：

img

線程1和線程2現在失去了同步。共用變數counter的實際值應為2，但每個線程的CPU緩存中的變數值為1，而在主記憶體中，該值仍為0。這是一個混亂！即使線程最終將共用變數counter的值寫回主存儲器，該值也將是錯誤的。

保證線程安全

正如我前面提到的，如果兩個線程都在讀取和寫入共用變數，那麼使用 volatile關鍵字是不安全的。 在這種情況下，您需要使用synchronized來保證變數的讀取和寫入是原子性的。讀取或寫入一個volatile變數不會阻塞其他線程讀取或寫入這個變數。為此，您必須在臨界區周圍使用synchronized關鍵字。

作為synchronized塊的替代方法，您還可以使用java.util.concurrent包中眾多的原子數據類型。例如，AtomicLong或者 AtomicReference或其他的。

如果只有一個線程讀取和寫入volatile變數的值，而其他線程只讀取這個變數，那麼此線程將保證其他線程能看到volatile變數的最新值。如果不將變數聲明為volatile，則無法保證。

volatile關鍵字也可以保證在64位變數上正常使用。

volatile的性能考慮

讀取和寫入volatile變數會導致變數從主存中讀取或寫入主存，讀取和寫入主記憶體比訪問CPU緩存開銷更大。訪問volatile變數也會阻止指令重排序，這是一種正常的性能提升技術。因此，當您確實需要強制實施變數可見性時，才使用volatile變數。

原理

volatile可以保證線程可見性且提供了一定的有序性，但是無法保證原子性。在JVM底層volatile是採用“記憶體屏障”來實現的。觀察加入volatile關鍵字和沒有加入volatile關鍵字時所生成的彙編代碼發現，加入volatile關鍵字時，會多出一個lock首碼指令，lock首碼指令實際上相當於一個記憶體屏障（也成記憶體柵欄），記憶體屏障會提供3個功能：

  • 它確保指令重排序時不會把其後面的指令排到記憶體屏障之前的位置，也不會把前面的指令排到記憶體屏障的後面；即在執行到記憶體屏障這句指令時，在它前面的操作已經全部完成；
  • 它會強制將對緩存的修改操作立即寫入主存；
  • 如果是寫操作，它會導致其他CPU中對應的緩存行無效。

記憶體語義

volatile寫的記憶體語義

當寫一個 volatile 變數時，JMM 會把該線程對應的本地記憶體中的共用變數值刷新到主記憶體。

以上面示常式序VolatileExample為例，假設線程A首先執行writer()方法，隨後線程B執行reader()方法，初始時兩個線程的本地記憶體中的flag和a都是初始狀態。下圖是線程A執行volatile寫後，共用變數的狀態示意圖：

img

如上圖所示，線程A在寫flag變數後，本地記憶體A中被線程A更新過的兩個共用變數的值被刷新到主記憶體中。此時，本地記憶體A和主記憶體中的共用變數的值是一致的。

volatile讀的記憶體語義

當讀一個 volatile 變數時，JMM 會把該線程對應的本地記憶體置為無效。線程接下來將從主記憶體中讀取共用變數。

下麵是線程 B 讀同一個 volatile 變數後，共用變數的狀態示意圖：

img

如上圖所示，在讀flag變數後，本地記憶體B已經被置為無效。此時，線程B必須從主記憶體中讀取共用變數。線程B的讀取操作將導致本地記憶體B與主記憶體中的共用變數的值也變成一致的了。

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

小結

下麵對volatile寫和volatile讀的記憶體語義做個總結

  • 線程A寫一個volatile變數，實質上是線程A向接下來將要讀這個volatile變數的某個線程發出了（其對共用變數所在修改的）消息。
  • 線程B讀一個volatile變數，實質上是線程B接收了之前某個線程發出的（在寫這個volatile變數之前對共用變數所做修改的）消息。
  • 線程A寫一個volatile變數，隨後線程B讀這個volatile變數，這個過程實質上是線程A通過主記憶體向線程B發送消息。

volatile記憶體語義的實現

前文我們提到過重排序分為編譯器重排序和處理器重排序。為了實現volatile記憶體語義，JMM會分別限制這兩種類型的重排序類型。下麵是JMM針對編譯器制定的volatile重排序規則表：

是否能重排序 第二個操作 第二個操作 第二個操作
第一個操作 普通讀/寫 volatile讀 volatile寫
普通讀/寫 NO
volatile讀 NO NO NO
volatile寫 NO NO

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

從上表我們可以看出

  • 當第二個操作為volatile寫操作時,不管第一個操作是什麼(普通讀寫或者volatile讀寫),都不能進行重排序。這個規則確保volatile寫之前的所有操作都不會被重排序到volatile寫之後;
  • 當第一個操作為volatile讀操作時,不管第二個操作是什麼,都不能進行重排序。這個規則確保volatile讀之後的所有操作都不會被重排序到volatile讀之前;
  • 當第一個操作是volatile寫操作時,第二個操作是volatile讀操作,不能進行重排序。

　　為了實現 volatile 的記憶體語義，編譯器在生成位元組碼時，會在指令序列中插入記憶體屏障來禁止特定類型的處理器重排序。下麵是基於保守策略的 JMM 記憶體屏障插入策略：

  • 在每個 volatile 寫操作的前面插入一個 StoreStore 屏障（禁止前面的寫與volatile寫重排序）。
  • 在每個 volatile 寫操作的後面插入一個 StoreLoad 屏障（禁止volatile寫與後面可能有的讀和寫重排序）。
  • 在每個 volatile 讀操作的後面插入一個 LoadLoad 屏障（禁止volatile讀與後面的讀操作重排序）。
  • 在每個 volatile 讀操作的後面插入一個 LoadStore 屏障（禁止volatile讀與後面的寫操作重排序）。

　　其中重點說下StoreLaod屏障，它是確保可見性的關鍵，因為它會將屏障之前的寫緩衝區中的數據全部刷新到主記憶體中。上述記憶體屏障插入策略非常保守，但它可以保證在任意處理平臺，任意的程式中都能得到正確的volatile語義。下麵是保守策略（為什麼說保守呢，因為有些在實際的場景是可省略的）下，volatile 寫操作 插入記憶體屏障後生成的指令序列示意圖：

img

其中StoreStore屏障可以保證在volatile寫之前，其前面的所有普通寫操作對任意處理器可見（把它刷新到主記憶體）。

另外volatile寫後面有StoreLoad屏障，此屏障的作用是避免volatile寫與後面可能有的讀或寫操作進行重排序。因為編譯器常常無法準確判斷在一個volatile寫的後面是否需要插入一個StoreLoad屏障（比如，一個volatile寫之後方法立即return）為了保證能正確實現volatile的記憶體語義，JMM採取了保守策略：在每個volatile寫的後面插入一個StoreLoad屏障。因為volatile寫-讀記憶體語義的常見模式是：一個寫線程寫volatile變數，多個度線程讀同一個volatile變數。當讀線程的數量大大超過寫線程時，選擇在volatile寫之後插入StoreLoad屏障將帶來可觀的執行效率的提升。從這裡也可看出JMM在實現上的一個特點：首先確保正確性，然後再去追求效率（其實我們工作中編碼也是一樣）。

下麵是在保守策略下，volatile讀插入記憶體屏障後生產的指令序列示意圖：

img

　上述volatile寫和volatile讀的記憶體屏障插入策略非常保守。在實際執行時，只要不改變volatile寫-讀的記憶體語義，編譯器可以根據具體情況忽略不必要的屏障。在JMM基礎中就有提到過各個處理器對各個屏障的支持度，其中x86處理器僅會對寫-讀操作做重排序。

下麵我們通過具體的示例代碼來說明

COPYclass 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() 方法，編譯器在生成位元組碼時可以做如下的優化：

img

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

上面的優化是針對任意處理器平臺，由於不同的處理器有不同“鬆緊度”的處理器記憶體模型，記憶體屏障的插入還可以根據具體的處理器記憶體模型繼續優化。以x86處理器為例，上圖中除最後的StoreLoad屏障外，其它的屏障都會被省略。

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

img

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

為什麼要增強volatile的記憶體語義

在 JSR-133 之前的舊 Java 記憶體模型中，雖然不允許 volatile 變數之間重排序，但舊的 Java 記憶體模型允許 volatile 變數與普通變數之間重排序。在舊的記憶體模型中，VolatileExample 示常式序可能被重排序成下列時序來執行：

img

在舊的記憶體模型中，當 1 和 2 之間沒有數據依賴關係時，1 和 2 之間就可能被重排序（3 和 4 類似）。其結果就是：讀線程 B 執行 4 時，不一定能看到寫線程 A 在執行 1 時對共用變數的修改。

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

由於volatile僅僅保證對單個volatile變數的讀/寫具有原子性，而鎖的互斥執行的特性可以確保對整個臨界區代碼的執行具有原子性。在功能上，鎖比volatile更強大；在可伸縮性和執行性能上，volatile更有優勢。如果讀者想在程式中用volatile代替監視器鎖，請一定謹慎，具體細節請參閱參考Java理論與實踐：正確使用Volatile變數。

本文由傳智教育博學谷狂野架構師教研團隊發佈。

如果本文對您有幫助，歡迎關註和點贊；如果您有任何建議也可留言評論或私信，您的支持是我堅持創作的動力。

轉載請註明出處！


您的分享是我們最大的動力!

-Advertisement-
Play Games
更多相關文章
  • 面向對象進階第二天
    面向對象進階第二天 許可權修飾符 作用：約束成員變數，構造器，方法等的訪問範圍 自己定義成員（方法，成員變數，構造器等）一般需要滿足如下要求： 成員變數一般私有。 方法一般公開。 如果該成員只希望本類訪問，使用private修飾。 如果該成員只希望本類，同一個包下的其他類和不同包下的子類訪問，使用pr ...
  • Python爬蟲基礎丨採集知乎問答區內容
    不知道現在還有多少人玩知某乎，我們那時候沒事就刷刷知某乎，貼某吧，不知留下了多少足跡。 知乎上問答的質量挺高，今天咱們就對其問答內容進行爬蟲實驗。 效果展示 可以看到，數據咱們就獲取下來了，保存就可以了。 代碼展示 import requests import re import json impo ...
  • python正則表達式替換所有內容並同時保留找到的內容
    Ansible-playbook 快速入門到放棄 隔岸紅塵忙似火，當軒青嶂冷如冰。 1-簡介 playbook 相當於可以把模塊命令都寫入到配置文件裡面，這樣就可以直接執行配置文件了，類似腳本。 2-playbook 初體驗 編寫test.yml 文件，在serviceA 主機機器上的/opt/tj ...
  • Spring 保存帶Array欄位的記錄到PostgreSQL
    字元串 字元集用來做什麼 字元集是為每個字元分配一個唯一的ID 在同一個字元集內，字元的ID是唯一的，不同字元集ID可能是不同的 UTF-8是編碼規則或者說是Unicode的一種實現 UTF-8將Unicode中的字元ID以某種方式進行編碼 變長的編碼規則： 1-4位元組，具體規則： 0xxxx表示0 ...
  • Python+Appium實現APP自動化測試
    OpenAI註冊（使用代理vpn才行） 準備： 外國郵箱，如gmail、outlook、iCloud郵箱等 外國手機號，或者能接受外國手機驗證碼既可以 （沒有的話文章里有推薦） 1.註冊我們的OpenAI賬號， 訪問地址：https://platform.openai.com/signup 點擊si ...
  • 《分散式技術原理與演算法解析》學習筆記Day21
    分散式存儲系統將用戶存儲的數據根據某種規則存儲到不同機器上，當用戶想要獲取指定數據時，再按照規則到存儲數據的機器中獲取。數據生產者/消費者、數據索引和數據存儲是分散式存儲系統的三大要素。 ...
  • MicroStrategy 教程_編程入門自學教程_菜鳥教程-免費教程分享
    教程簡介 MicroStrategy初學者教程 - 從簡單和簡單的步驟學習MicroStrategy，從基本到高級概念，包括概述，環境設置，桌面，架構，組件概述，導入數據，OLAP服務，配置對象，公共對象，模式對象，報告對象，報表類型，切片，切塊，透視，鑽取和向下鑽取，彙總，創建度量標準，嵌套度量標 ...
  • QT MySQL 連接出錯報 QSqlDatabase: QMYSQL driver not loaded
    QT連接MySQL失敗（本人QT版本：5.12.5） 一、報錯結果 QSqlDatabase: QMYSQL driver not loaded QSqlDatabase: available drivers: QSQLITE QODBC QODBC3 QPSQL QPSQL7 二、報錯原因 缺少M ...
一周排行
    -Advertisement-
    Play Games
  • GoF之工廠模式
    GoF之工廠模式 @目錄GoF之工廠模式每博一文案1. 簡單說明“23種設計模式”1.2 介紹工廠模式的三種形態1.3 簡單工廠模式（靜態工廠模式）1.3.1 簡單工廠模式的優缺點:1.4 工廠方法模式1.4.1 工廠方法模式的優缺點:1.5 抽象工廠模式1.6 抽象工廠模式的優缺點：2. 總結:3 ...
  • dotnet C# 簡單的追加文件夾到 ZipArchive 壓縮文件的方法
    新改進提供的Taurus Rpc 功能，可以簡化微服務間的調用，同時可以不用再手動輸出模塊名稱，或調用路徑，包括負載均衡，這一切，由框架實現並提供了。新的Taurus Rpc 功能，將使得服務間的調用，更加輕鬆、簡約、高效。 ...
  • Elasticsearch 系列（六）- ES數據同步和ES集群
    本章將和大家分享ES的數據同步方案和ES集群相關知識。廢話不多說，下麵我們直接進入主題。 一、ES數據同步 1、數據同步問題 Elasticsearch中的酒店數據來自於mysql資料庫，因此mysql數據發生改變時，Elasticsearch也必須跟著改變，這個就是Elasticsearch與my ...
  • 自動化測試數據生成：Asp.Net Core單元測試利器AutoFixture詳解
    引言 在我們之前的文章中介紹過使用Bogus生成模擬測試數據，今天來講解一下功能更加強大自動生成測試數據的工具的庫"AutoFixture"。 什麼是AutoFixture? AutoFixture 是一個針對 .NET 的開源庫，旨在最大程度地減少單元測試中的“安排（Arrange）”階段，以提高 ...
  • .NET Emit 入門教程：第七部分：實戰項目1：將 DbDataReader 轉實體
    經過前面幾個部分學習，相信學過的同學已經能夠掌握 .NET Emit 這種中間語言，並能使得它來編寫一些應用，以提高程式的性能。隨著 IL 指令篇的結束，本系列也已經接近尾聲，在這接近結束的最後，會提供幾個可供直接使用的示例，以供大伙分析或使用在項目中。 ...
  • Windows下綁定線程到指定的CPU核心
    當從不同來源導入Excel數據時，可能存在重覆的記錄。為了確保數據的準確性，通常需要刪除這些重覆的行。手動查找並刪除可能會非常耗費時間，而通過編程腳本則可以實現在短時間內處理大量數據。本文將提供一個使用C# 快速查找並刪除Excel重覆項的免費解決方案。 以下是實現步驟： 1. 首先安裝免費.NET ...
  • mORMot 1.18 第07章 簡單的讀寫操作
    C++ 異常處理 C++ 異常處理機制允許程式在運行時處理錯誤或意外情況。它提供了捕獲和處理錯誤的一種結構化方式，使程式更加健壯和可靠。 異常處理的基本概念： 異常: 程式在運行時發生的錯誤或意外情況。 拋出異常: 使用 throw 關鍵字將異常傳遞給調用堆棧。 捕獲異常: 使用 try-catch ...
  • mORMot 1.18 第06章 概念
    優秀且經驗豐富的Java開發人員的特征之一是對API的廣泛瞭解，包括JDK和第三方庫。 我花了很多時間來學習API，尤其是在閱讀了Effective Java 3rd Edition之後 ，Joshua Bloch建議在Java 3rd Edition中使用現有的API進行開發，而不是為常見的東西編 ...
  • php 開發規範
    框架 · 使用laravel框架，原因：tp的框架路由和orm沒有laravel好用 · 使用強制路由，方便介面多時，分多版本，分文件夾等操作 介面 · 介面開發註意欄位類型，欄位是int，查詢成功失敗都要返回int（對接java等強類型語言方便） · 查詢介面用GET、其他用POST 代碼 · 所 ...
  • 2024 年 4 月 28 日 周日 晴 熱（1253 字）
    正文 下午找企業的人去鎮上做貸後。 車上聽同事跟那個司機對罵，火星子都快出來了。司機跟那同事更熟一些，連我在內一共就三個人，同事那一手指桑罵槐給我都聽愣了。司機也是老社會人了，馬上聽出來了，為那個無辜的企業經辦人辯護，實際上是為自己辯護。 “這個事情你不能怪企業。”“但他們總不能讓銀行的人全權負責， ...
所有分類