Java 併發編程：volatile的使用及其原理

時間 2019-11-16

原文原文鏈接

Java併發編程系列：html

1、volatile的做用app

　　在《Java併發編程：核心理論》一文中，咱們已經提到過可見性、有序性及原子性問題，一般狀況下咱們能夠經過Synchronized關鍵字來解決這些個問題，不過若是對Synchronized原理有了解的話，應該知道Synchronized是一個比較重量級的操做，對系統的性能有比較大的影響，因此，若是有其餘解決方案，咱們一般都避免使用Synchronized來解決問題。而volatile關鍵字就是Java中提供的另外一種解決可見性和有序性問題的方案。對於原子性，須要強調一點，也是你們容易誤解的一點：對volatile變量的單次讀/寫操做能夠保證原子性的，如long和double類型變量，可是並不能保證i++這種操做的原子性，由於本質上i++是讀、寫兩次操做。less

2、volatile的使用ide

　　關於volatile的使用，咱們能夠經過幾個例子來講明其使用方式和場景。函數

一、防止重排序

　　咱們從一個最經典的例子來分析重排序問題。你們應該都很熟悉單例模式的實現，而在併發環境下的單例實現方式，咱們一般能夠採用雙重檢查加鎖（DCL）的方式來實現。其源碼以下：

 1 package com.paddx.test.concurrent;
 2 
 3 public class Singleton {
 4     public static volatile Singleton singleton;
 5 
 6     /**
 7      * 構造函數私有，禁止外部實例化
 8      */
 9     private Singleton() {};
10 
11     public static Singleton getInstance() {
12         if (singleton == null) {
13             synchronized (singleton) {
14                 if (singleton == null) {
15                     singleton = new Singleton();
16                 }
17             }
18         }
19         return singleton;
20     }
21 }

　　如今咱們分析一下爲何要在變量singleton之間加上volatile關鍵字。要理解這個問題，先要了解對象的構造過程，實例化一個對象其實能夠分爲三個步驟：

　　（1）分配內存空間。

　　（2）初始化對象。

　　（3）將內存空間的地址賦值給對應的引用。

可是因爲操做系統能夠對指令進行重排序，因此上面的過程也可能會變成以下過程：

　　（1）分配內存空間。

　　（2）將內存空間的地址賦值給對應的引用。

　　（3）初始化對象

　　若是是這個流程，多線程環境下就可能將一個未初始化的對象引用暴露出來，從而致使不可預料的結果。所以，爲了防止這個過程的重排序，咱們須要將變量設置爲volatile類型的變量。

二、實現可見性

　　可見性問題主要指一個線程修改了共享變量值，而另外一個線程卻看不到。引發可見性問題的主要緣由是每一個線程擁有本身的一個高速緩存區——線程工做內存。volatile關鍵字能有效的解決這個問題，咱們看下下面的例子，就能夠知道其做用：

 1 package com.paddx.test.concurrent;
 2 
 3 public class VolatileTest {
 4     int a = 1;
 5     int b = 2;
 6 
 7     public void change(){
 8         a = 3;
 9         b = a;
10     }
11 
12     public void print(){
13         System.out.println("b="+b+";a="+a);
14     }
15 
16     public static void main(String[] args) {
17         while (true){
18             final VolatileTest test = new VolatileTest();
19             new Thread(new Runnable() {
20                 @Override
21                 public void run() {
22                     try {
23                         Thread.sleep(10);
24                     } catch (InterruptedException e) {
25                         e.printStackTrace();
26                     }
27                     test.change();
28                 }
29             }).start();
30 
31             new Thread(new Runnable() {
32                 @Override
33                 public void run() {
34                     try {
35                         Thread.sleep(10);
36                     } catch (InterruptedException e) {
37                         e.printStackTrace();
38                     }
39                     test.print();
40                 }
41             }).start();
42 
43         }
44     }
45 }

　　直觀上說，這段代碼的結果只可能有兩種：b=3;a=3 或 b=2;a=1。不過運行上面的代碼（可能時間上要長一點），你會發現除了上兩種結果以外，還出現了第三種結果：

......
b=2;a=1
b=2;a=1
b=3;a=3
b=3;a=3
b=3;a=1
b=3;a=3
b=2;a=1
b=3;a=3
b=3;a=3
......

　　爲何會出現b=3;a=1這種結果呢？正常狀況下，若是先執行change方法，再執行print方法，輸出結果應該爲b=3;a=3。相反，若是先執行的print方法，再執行change方法，結果應該是 b=2;a=1。那b=3;a=1的結果是怎麼出來的？緣由就是第一個線程將值a=3修改後，可是對第二個線程是不可見的，因此纔出現這一結果。若是將a和b都改爲volatile類型的變量再執行，則不再會出現b=3;a=1的結果了。

三、保證原子性

　　關於原子性的問題，上面已經解釋過。volatile只能保證對單次讀/寫的原子性。這個問題能夠看下JLS中的描述：

  17.7 Non-Atomic Treatment of double and long 
 For the purposes of the Java programming language memory model, a single write to a non-volatile long or double value is treated as two separate writes: one to each 32-bit half. This can result in a situation where a thread sees the first 32 bits of a 64-bit value from one write, and the second 32 bits from another write.
Writes and reads of volatile long and double values are always atomic. 
Writes to and reads of references are always atomic, regardless of whether they are implemented as 32-bit or 64-bit values. 
Some implementations may find it convenient to divide a single write action on a 64-bit long or double value into two write actions on adjacent 32-bit values. For efficiency's sake, this behavior is implementation-specific; an implementation of the Java Virtual Machine is free to perform writes to long and double values atomically or in two parts. 
Implementations of the Java Virtual Machine are encouraged to avoid splitting 64-bit values where possible. Programmers are encouraged to declare shared 64-bit values as volatile or synchronize their programs correctly to avoid possible complications.

　　這段話的內容跟我前面的描述內容大體相似。由於long和double兩種數據類型的操做可分爲高32位和低32位兩部分，所以普通的long或double類型讀/寫可能不是原子的。所以，鼓勵你們將共享的long和double變量設置爲volatile類型，這樣能保證任何狀況下對long和double的單次讀/寫操做都具備原子性。

　　關於volatile變量對原子性保證，有一個問題容易被誤解。如今咱們就經過下列程序來演示一下這個問題：

 1 package com.paddx.test.concurrent;
 2 
 3 public class VolatileTest01 {
 4     volatile int i;
 5 
 6     public void addI(){
 7         i++;
 8     }
 9 
10     public static void main(String[] args) throws InterruptedException {
11         final  VolatileTest01 test01 = new VolatileTest01();
12         for (int n = 0; n < 1000; n++) {
13             new Thread(new Runnable() {
14                 @Override
15                 public void run() {
16                     try {
17                         Thread.sleep(10);
18                     } catch (InterruptedException e) {
19                         e.printStackTrace();
20                     }
21                     test01.addI();
22                 }
23             }).start();
24         }
25 
26         Thread.sleep(10000);//等待10秒，保證上面程序執行完成
27 
28         System.out.println(test01.i);
29     }
30 }

你們可能會誤認爲對變量i加上關鍵字volatile後，這段程序就是線程安全的。你們能夠嘗試運行上面的程序。下面是我本地運行的結果：

　　可能每一個人運行的結果不相同。不過應該能看出，volatile是沒法保證原子性的（不然結果應該是1000）。緣由也很簡單，i++實際上是一個複合操做，包括三步驟：

　　（1）讀取i的值。

　　（2）對i加1。

　　（3）將i的值寫回內存。

volatile是沒法保證這三個操做是具備原子性的，咱們能夠經過AtomicInteger或者Synchronized來保證+1操做的原子性。

注：上面幾段代碼中多處執行了Thread.sleep()方法，目的是爲了增長併發問題的產生概率，無其餘做用。

3、volatile的原理

　　經過上面的例子，咱們基本應該知道了volatile是什麼以及怎麼使用。如今咱們再來看看volatile的底層是怎麼實現的。

　　一、可見性實現：

　　在前文中已經說起過，線程自己並不直接與主內存進行數據的交互，而是經過線程的工做內存來完成相應的操做。這也是致使線程間數據不可見的本質緣由。所以要實現volatile變量的可見性，直接從這方面入手便可。對volatile變量的寫操做與普通變量的主要區別有兩點：

　　（1）修改volatile變量時會強制將修改後的值刷新的主內存中。

　　（2）修改volatile變量後會致使其餘線程工做內存中對應的變量值失效。所以，再讀取該變量值的時候就須要從新從讀取主內存中的值。

　　經過這兩個操做，就能夠解決volatile變量的可見性問題。

　　二、有序性實現：

　　在解釋這個問題前，咱們先來了解一下Java中的happen-before規則，JSR 133中對Happen-before的定義以下：

Two actions can be ordered by a happens-before relationship.If one action happens before another, then the first is visible to and ordered before the second.

　　通俗一點說就是若是a happen-before b，則a所作的任何操做對b是可見的。（這一點你們務必記住，由於happen-before這個詞容易被誤解爲是時間的先後）。咱們再來看看JSR 133中定義了哪些happen-before規則：

• Each action in a thread happens before every subsequent action in that thread.
• An unlock on a monitor happens before every subsequent lock on that monitor.
• A write to a volatile field happens before every subsequent read of that volatile.
• A call to start() on a thread happens before any actions in the started thread.
• All actions in a thread happen before any other thread successfully returns from a join() on that thread.
• If an action a happens before an action b, and b happens before an action c, then a happens before c.

　　翻譯過來爲：

同一個線程中的，前面的操做 happen-before 後續的操做。（即單線程內按代碼順序執行。可是，在不影響在單線程環境執行結果的前提下，編譯器和處理器能夠進行重排序，這是合法的。換句話說，這一是規則沒法保證編譯重排和指令重排）。
監視器上的解鎖操做 happen-before 其後續的加鎖操做。（Synchronized 規則）
對volatile變量的寫操做 happen-before 後續的讀操做。（volatile 規則）
線程的start() 方法 happen-before 該線程全部的後續操做。（線程啓動規則）
線程全部的操做 happen-before 其餘線程在該線程上調用 join 返回成功後的操做。
若是 a happen-before b，b happen-before c，則a happen-before c（傳遞性）。

　　這裏咱們主要看下第三條：volatile變量的保證有序性的規則。《Java併發編程：核心理論》一文中提到太重排序分爲編譯器重排序和處理器重排序。爲了實現volatile內存語義，JMM會對volatile變量限制這兩種類型的重排序。下面是JMM針對volatile變量所規定的重排序規則表：

Can Reorder	2nd operation
1st operation	Normal Load Normal Store	Volatile Load	Volatile Store
Normal Load Normal Store			No
Volatile Load	No	No	No
Volatile store		No	No

　　三、內存屏障

　　爲了實現volatile可見性和happen-befor的語義。JVM底層是經過一個叫作「內存屏障」的東西來完成。內存屏障，也叫作內存柵欄，是一組處理器指令，用於實現對內存操做的順序限制。下面是完成上述規則所要求的內存屏障：

Required barriers	2nd operation
1st operation	Normal Load	Normal Store	Volatile Load	Volatile Store
Normal Load				LoadStore
Normal Store				StoreStore
Volatile Load	LoadLoad	LoadStore	LoadLoad	LoadStore
Volatile Store			StoreLoad	StoreStore

（1）LoadLoad 屏障
執行順序：Load1—>Loadload—>Load2
確保Load2及後續Load指令加載數據以前能訪問到Load1加載的數據。

（2）StoreStore 屏障
執行順序：Store1—>StoreStore—>Store2
確保Store2以及後續Store指令執行前，Store1操做的數據對其它處理器可見。

（3）LoadStore 屏障
執行順序： Load1—>LoadStore—>Store2
確保Store2和後續Store指令執行前，能夠訪問到Load1加載的數據。

（4）StoreLoad 屏障
執行順序: Store1—> StoreLoad—>Load2
確保Load2和後續的Load指令讀取以前，Store1的數據對其餘處理器是可見的。

最後我能夠經過一個實例來講明一下JVM中是如何插入內存屏障的：

 1 package com.paddx.test.concurrent;
 2 
 3 public class MemoryBarrier {
 4     int a, b;
 5     volatile int v, u;
 6 
 7     void f() {
 8         int i, j;
 9 
10         i = a;
11         j = b;
12         i = v;
13         //LoadLoad
14         j = u;
15         //LoadStore
16         a = i;
17         b = j;
18         //StoreStore
19         v = i;
20         //StoreStore
21         u = j;
22         //StoreLoad
23         i = u;
24         //LoadLoad
25         //LoadStore
26         j = b;
27         a = i;
28     }
29 }

4、總結

　　整體上來講volatile的理解仍是比較困難的，若是不是特別理解，也不用急，徹底理解須要一個過程，在後續的文章中也還會屢次看到volatile的使用場景。這裏暫且對volatile的基礎知識和原來有一個基本的瞭解。整體來講，volatile是併發編程中的一種優化，在某些場景下能夠代替Synchronized。可是，volatile的不能徹底取代Synchronized的位置，只有在一些特殊的場景下，才能適用volatile。總的來講，必須同時知足下面兩個條件才能保證在併發環境的線程安全：

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

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