Java併發編程、內存模型與Volatile

時間 2019-12-19

標籤 java 併發編程內存模型 volatile 欄目 Java 简体版

原文原文鏈接

http://www.importnew.com/24082.html volatile關鍵字html

http://www.importnew.com/16142.html ConcurrentHashMap原理分析java

http://www.importnew.com/19612.html Java內存模型c++

Java內存模型：編程

關鍵字：主存、工做內存；堆區、棧區（http://www.importnew.com/19612.html ）緩存

在Java Memory Model中，Memory分爲兩類，main memory和working memory，main memory爲全部線程共享，working memory中存放的是線程所須要的變量的拷貝（線程要對main memory中的內容進行操做的話，首先須要拷貝到本身的working memory，通常爲了速度，working memory通常是在cpu的cache中的）。volatile的變量在被操做的時候不會產生working memory的拷貝，而是直接操做main memory，固然volatile雖然解決了變量的可見性問題，但沒有解決變量操做的原子性的問題，這個還須要synchronized或者CAS相關操做配合進行。多線程

Java內存模型規定了全部的變量都存儲在主內存中。每條線程中還有本身的工做內存，線程的工做內存中保存了被該線程所使用到的變量（這些變量是從主內存中拷貝而來）。線程對變量的全部操做（讀取，賦值）都必須在工做內存中進行。不一樣線程之間也沒法直接訪問對方工做內存中的變量，線程間變量值的傳遞均須要經過主內存來完成。併發

併發編程的三大概念：原子性，有序性，可見性。app

可見性

也就說假設一個對象中有一個變量i，那麼i是保存在main memory中的，當某一個線程要操做i的時候，首先須要從main memory中將i 加載到這個線程的working memory中，這個時候working memory中就有了一個i的拷貝，這個時候此線程對i的修改都在其working memory中，直到其將i從working memory寫回到main memory中，新的i的值才能被其餘線程所讀取。從某個意義上說，可見性保證了各個線程的working memory的數據的一致性。可見性遵循下面一些規則：函數

當一個線程運行結束的時候，全部寫的變量都會被flush回main memory中。
當一個線程第一次讀取某個變量的時候，會從main memory中讀取最新的。
volatile的變量會被馬上寫到main memory中的，在jsr133中，對volatile的語義進行加強，後面會提到
當一個線程釋放鎖後，全部的變量的變化都會flush到main memory中，而後一個使用了這個相同的同步鎖的進程，將會從新加載全部的使用到的變量，這樣就保證了可見性。

原子性

還拿上面的例子來講，原子性就是當某一個線程修改i的值的時候，從取出i到將新的i的值寫給i之間不能有其餘線程對i進行任何操做。也就是說保證某個線程對i的操做是原子性的，這樣就能夠避免數據髒讀。經過鎖機制或者CAS（Compare And Set 須要硬件CPU的支持）操做能夠保證操做的原子性。性能

有序性

假設在main memory中存在兩個變量i和j，初始值都爲0，在某個線程A的代碼中依次對i和j進行自增操做（i，j的操做不相互依賴）

 
        i++; 
       
        j++;

因爲，因此i,j修改操做的順序可能會被從新排序。那麼修改後的ij寫到main memory中的時候，順序可能就不是按照i，j的順序了，這就是所謂的reordering，在單線程的狀況下，當線程A運行結束的後i，j的值都加1了，在線程本身看來就好像是線程按照代碼的順序進行了運行（這些操做都是基於as-if-serial語義的），即便在實際運行過程當中，i，j的自增可能被從新排序了，固然計算機也不能幫你亂排序，存在上下邏輯關聯的運行順序確定仍是不會變的。可是在多線程環境下，問題就不同了，好比另外一個線程B的代碼以下

 
        if 
        (j== 
        1 
        ) { 
       
        System.out.println(i); 
       
        }

按照咱們的思惟方式，當j爲1的時候那麼i確定也是1，由於代碼中i在j以前就自增了，但實際的狀況有可能當j爲1的時候i仍是爲0。這就是reordering產生的很差的後果，因此咱們在某些時候爲了不這樣的問題須要一些必要的策略，以保證多個線程一塊兒工做的時候也存在必定的次序。JMM提供了happens-before 的排序策略。這樣咱們能夠獲得多線程環境下的as-if-serial語義。這裏不對happens-before進行詳細解釋了,詳細的請看這裏http://www.ibm.com/developerworks/cn/java/j-jtp03304/，這裏主要講一下volatile在新的java內存模型下的變化，在jsr133以前，下面的代碼可能會出現問題

 
        Map configOptions; 
       
        char 
        [] configText; 
       
        volatile 
        boolean 
        initialized =  
        false 
        ; 
       
        // In Thread A 
       
        configOptions =  
        new 
        HashMap(); 
       
        configText = readConfigFile(fileName); 
       
        processConfigOptions(configText, configOptions); 
       
        initialized =  
        true 
        ; 
       
        // In Thread B 
       
        while 
        (!initialized)  
       
        sleep(); 
       
        // use configOptions

jsr133以前，雖然對 volatile 變量的讀和寫不能與對其餘 volatile 變量的讀和寫一塊兒從新排序，可是它們仍然能夠與對 nonvolatile 變量的讀寫一塊兒從新排序，因此上面的Thread A的操做，就可能initialized變成true的時候，而configOptions尚未被初始化，因此initialized先於configOptions被線程B看到，就產生問題了。

JSR 133 Expert Group 決定讓 volatile 讀寫不能與其餘內存操做一塊兒從新排序，新的內存模型下，若是當線程 A 寫入 volatile 變量 V 而線程 B 讀取 V 時，那麼在寫入 V 時，A 可見的全部變量值如今均可以保證對 B 是可見的。

結果就是做用更大的 volatile 語義，代價是訪問 volatile 字段時會對性能產生更大的影響。這一點在ConcurrentHashMap中的統計某個segment元素個數的count變量中使用到了。

深刻理解volatile關鍵字

1.volatile保證可見性

一旦一個共享變量（類的成員變量、類的靜態成員變量）被volatile修飾以後，那麼就具有了兩層語義：

1）保證了不一樣線程對這個變量進行操做時的可見性，即一個線程修改了某個變量的值，這新值對其餘線程來講是當即可見的。

2）禁止進行指令重排序。

先看一段代碼，假如線程1先執行，線程2後執行：

 
        //線程1 
       
        boolean 
        stop =  
        false 
        ; 
       
        while 
        (!stop){ 
       
        doSomething(); 
       
        } 
       
        //線程2 
       
        stop =  
        true 
        ;

這段代碼是很典型的一段代碼，不少人在中斷線程時可能都會採用這種標記辦法。可是事實上，這段代碼會徹底運行正確麼？即必定會將線程中斷麼？不必定，也許在大多數時候，這個代碼可以把線程中斷，可是也有可能會致使沒法中斷線程（雖然這個可能性很小，可是隻要一旦發生這種狀況就會形成死循環了）。

下面解釋一下這段代碼爲什麼有可能致使沒法中斷線程。在前面已經解釋過，每一個線程在運行過程當中都有本身的工做內存，那麼線程1在運行的時候，會將stop變量的值拷貝一份放在本身的工做內存當中。

那麼當線程2更改了stop變量的值以後，可是還沒來得及寫入主存當中，線程2轉去作其餘事情了，那麼線程1因爲不知道線程2對stop變量的更改，所以還會一直循環下去。

可是用volatile修飾以後就變得不同了：

第一：使用volatile關鍵字會強制將修改的值當即寫入主存；

第二：使用volatile關鍵字的話，當線程2進行修改時，會致使線程1的工做內存中緩存變量stop的緩存行無效（反映到硬件層的話，就是CPU的L1或者L2緩存中對應的緩存行無效）；

第三：因爲線程1的工做內存中緩存變量stop的緩存行無效，因此線程1再次讀取變量stop的值時會去主存讀取。

那麼在線程2修改stop值時（固然這裏包括2個操做，修改線程2工做內存中的值，而後將修改後的值寫入內存），會使得線程1的工做內存中緩存變量stop的緩存行無效，而後線程1讀取時，發現本身的緩存行無效，它會等待緩存行對應的主存地址被更新以後，而後去對應的主存讀取最新的值。

那麼線程1讀取到的就是最新的正確的值。

2.volatile不能確保原子性

下面看一個例子：

 
        public 
        class 
        Test { 
       
        public 
        volatile 
        int 
        inc =  
        0 
        ; 
       
        public 
        void 
        increase() { 
       
        inc++; 
       
        } 
       
        public 
        static 
        void 
        main(String[] args) { 
       
        final 
        Test test =  
        new 
        Test(); 
       
        for 
        ( 
        int 
        i= 
        0 
        ;i< 
        10 
        ;i++){ 
       
        new 
        Thread(){ 
       
        public 
        void 
        run() { 
       
        for 
        ( 
        int 
        j= 
        0 
        ;j< 
        1000 
        ;j++) 
       
        test.increase(); 
       
        }; 
       
        }.start(); 
       
        } 
       
        while 
        (Thread.activeCount()> 
        1 
        )   
        //保證前面的線程都執行完 
       
        Thread.yield(); 
       
        System.out.println(test.inc); 
       
        } 
       
        }

你們想一下這段程序的輸出結果是多少？也許有些朋友認爲是10000。可是事實上運行它會發現每次運行結果都不一致，都是一個小於10000的數字。

可能有的朋友就會有疑問，不對啊，上面是對變量inc進行自增操做，因爲volatile保證了可見性，那麼在每一個線程中對inc自增完以後，在其餘線程中都能看到修改後的值啊，因此有10個線程分別進行了1000次操做，那麼最終inc的值應該是1000*10=10000。

這裏面就有一個誤區了，volatile關鍵字能保證可見性沒有錯，可是上面的程序錯在沒能保證原子性。可見性只能保證每次讀取的是最新的值，可是volatile沒辦法保證對變量的操做的原子性。

在前面已經提到過，自增操做是不具有原子性的，它包括讀取變量的原始值、進行加1操做、寫入工做內存。那麼就是說自增操做的三個子操做可能會分割開執行，就有可能致使下面這種狀況出現：

假如某個時刻變量inc的值爲10，

線程1對變量進行自增操做，線程1先讀取了變量inc的原始值，而後線程1被阻塞了；

而後線程2對變量進行自增操做，線程2也去讀取變量inc的原始值，因爲線程1只是對變量inc進行讀取操做，而沒有對變量進行修改操做，因此不會致使線程2的工做內存中緩存變量inc的緩存行無效，也不會致使主存中的值刷新，因此線程2會直接去主存讀取inc的值，發現inc的值時10，而後進行加1操做，並把11寫入工做內存，最後寫入主存。

而後線程1接着進行加1操做，因爲已經讀取了inc的值，注意此時在線程1的工做內存中inc的值仍然爲10，因此線程1對inc進行加1操做後inc的值爲11，而後將11寫入工做內存，最後寫入主存。

那麼兩個線程分別進行了一次自增操做後，inc只增長了1。

根源就在這裏，自增操做不是原子性操做，並且volatile也沒法保證對變量的任何操做都是原子性的。

解決方案：能夠經過synchronized或lock，進行加鎖，來保證操做的原子性。也能夠經過AtomicInteger。

在java 1.5的java.util.concurrent.atomic包下提供了一些原子操做類，即對基本數據類型的自增（加1操做），自減（減1操做）、以及加法操做（加一個數），減法操做（減一個數）進行了封裝，保證這些操做是原子性操做。atomic是利用CAS來實現原子性操做的（Compare And Swap），CAS其實是利用處理器提供的CMPXCHG指令實現的，而處理器執行CMPXCHG指令是一個原子性操做。

3.volatile保證有序性

在前面提到volatile關鍵字能禁止指令重排序，因此volatile能在必定程度上保證有序性。

volatile關鍵字禁止指令重排序有兩層意思：

1）當程序執行到volatile變量的讀操做或者寫操做時，在其前面的操做的更改確定所有已經進行，且結果已經對後面的操做可見；在其後面的操做確定尚未進行；

2）在進行指令優化時，不能將在對volatile變量的讀操做或者寫操做的語句放在其後面執行，也不能把volatile變量後面的語句放到其前面執行。

可能上面說的比較繞，舉個簡單的例子：

 
        //x、y爲非volatile變量 
       
        //flag爲volatile變量 
       
        x =  
        2 
        ;         
        //語句1 
       
        y =  
        0 
        ;         
        //語句2 
       
        flag =  
        true 
        ;   
        //語句3 
       
        x =  
        4 
        ;          
        //語句4 
       
        y = - 
        1 
        ;        
        //語句5

因爲flag變量爲volatile變量，那麼在進行指令重排序的過程的時候，不會將語句3放到語句一、語句2前面，也不會講語句3放到語句四、語句5後面。可是要注意語句1和語句2的順序、語句4和語句5的順序是不做任何保證的。

而且volatile關鍵字能保證，執行到語句3時，語句1和語句2一定是執行完畢了的，且語句1和語句2的執行結果對語句三、語句四、語句5是可見的。

那麼咱們回到前面舉的一個例子：

 
        //線程1: 
       
        context = loadContext();    
        //語句1 
       
        inited =  
        true 
        ;              
        //語句2 
       
        //線程2: 
       
        while 
        (!inited ){ 
       
        sleep() 
       
        } 
       
        doSomethingwithconfig(context);

前面舉這個例子的時候，提到有可能語句2會在語句1以前執行，那麼久可能致使context還沒被初始化，而線程2中就使用未初始化的context去進行操做，致使程序出錯。

這裏若是用volatile關鍵字對inited變量進行修飾，就不會出現這種問題了，由於當執行到語句2時，一定能保證context已經初始化完畢。

volatile的實現原理

1.可見性

處理器爲了提升處理速度，不直接和內存進行通信，而是將系統內存的數據獨到內部緩存後再進行操做，但操做完後不知何時會寫到內存。

若是對聲明瞭volatile變量進行寫操做時，JVM會向處理器發送一條Lock前綴的指令，將這個變量所在緩存行的數據寫會到系統內存。這一步確保了若是有其餘線程對聲明瞭volatile變量進行修改，則當即更新主內存中數據。

但這時候其餘處理器的緩存仍是舊的，因此在多處理器環境下，爲了保證各個處理器緩存一致，每一個處理會經過嗅探在總線上傳播的數據來檢查本身的緩存是否過時，當處理器發現本身緩存行對應的內存地址被修改了，就會將當前處理器的緩存行設置成無效狀態，當處理器要對這個數據進行修改操做時，會強制從新從系統內存把數據讀處處理器緩存裏。這一步確保了其餘線程得到的聲明瞭volatile變量都是從主內存中獲取最新的。

2.有序性

Lock前綴指令實際上至關於一個內存屏障（也成內存柵欄），它確保指令重排序時不會把其後面的指令排到內存屏障以前的位置，也不會把前面的指令排到內存屏障的後面；即在執行到內存屏障這句指令時，在它前面的操做已經所有完成。

volatile的應用場景

synchronized關鍵字是防止多個線程同時執行一段代碼，那麼就會很影響程序執行效率，而volatile關鍵字在某些狀況下性能要優於synchronized，可是要注意volatile關鍵字是沒法替代synchronized關鍵字的，由於volatile關鍵字沒法保證操做的原子性。一般來講，使用volatile必須具有如下2個條件：

1）對變量的寫操做不依賴於當前值

2）該變量沒有包含在具備其餘變量的不變式中

下面列舉幾個Java中使用volatile的幾個場景。

①.狀態標記量

 
        volatile 
        boolean 
        flag =  
        false 
        ; 
       
        //線程1 
       
        while 
        (!flag){ 
       
        doSomething(); 
       
        } 
       
        //線程2 
       
        public 
        void 
        setFlag() { 
       
        flag =  
        true 
        ; 
       
        }

根據狀態標記，終止線程。

②.單例模式中的double check

 
        class 
        Singleton{ 
       
        private 
        volatile 
        static 
        Singleton instance =  
        null 
        ; 
       
        private 
        Singleton() { 
       
        } 
       
        public 
        static 
        Singleton getInstance() { 
       
        if 
        (instance== 
        null 
        ) { 
       
        synchronized 
        (Singleton. 
        class 
        ) { 
       
        if 
        (instance== 
        null 
        ) 
       
        instance =  
        new 
        Singleton(); 
       
        } 
       
        } 
       
        return 
        instance; 
       
        } 
       
        }

爲何要使用volatile 修飾instance？

主要在於instance = new Singleton()這句，這並不是是一個原子操做，事實上在 JVM 中這句話大概作了下面 3 件事情:

1.給 instance 分配內存

2.調用 Singleton 的構造函數來初始化成員變量

3.將instance對象指向分配的內存空間（執行完這步 instance 就爲非 null 了）。

可是在 JVM 的即時編譯器中存在指令重排序的優化。也就是說上面的第二步和第三步的順序是不能保證的，最終的執行順序多是 1-2-3 也多是 1-3-2。若是是後者，則在 3 執行完畢、2 未執行以前，被線程二搶佔了，這時 instance 已是非 null 了（但卻沒有初始化），因此線程二會直接返回 instance，而後使用，而後瓜熟蒂落地報錯。