java可見性、原子性、有序性在并發場景下的原理

這篇文章主要講解了“java可見性、原子性、有序性在并發場景下的原理”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“java可見性、原子性、有序性在并發場景下的原理”吧！

源頭一：緩存導致的可見性問題

在單核時代，所有的線程都是在一顆 CPU 上執行，CPU 緩存與內存的數據一致性容易解 決。因為所有線程都是操作同一個 CPU 的緩存，一個線程對緩存的寫，對另外一個線程來 說一定是可見的。例如在下面的圖中，線程 A 和線程 B 都是操作同一個 CPU 里面的緩 存，所以線程 A 更新了變量 V 的值，那么線程 B 之后再訪問變量 V，得到的一定是 V 的 最新值（線程 A 寫過的值）。

一個線程對共享變量的修改，另外一個線程能夠立刻看到，我們稱為可見性。

多核時代，每顆 CPU 都有自己的緩存，這時 CPU 緩存與內存的數據一致性就沒那么容易 解決了，當多個線程在不同的 CPU 上執行時，這些線程操作的是不同的 CPU 緩存。比如 下圖中，線程 A 操作的是 CPU-1 上的緩存，而線程 B 操作的是 CPU-2 上的緩存，很明 顯，這個時候線程 A 對變量 V 的操作對于線程 B 而言就不具備可見性了。這個就屬于硬 件程序員給軟件程序員挖的“坑”。

下面我們再用一段代碼來驗證一下多核場景下的可見性問題。下面的代碼，每執行一次 add10K() 方法，都會循環 10000 次 count+=1 操作。在 calc() 方法中我們創建了兩個 線程，每個線程調用一次 add10K() 方法，我們來想一想執行 calc() 方法得到的結果應該 是多少呢？

    public class Test {
        private long count = 0;

        private void add10K() {
            int idx = 0;
            while (idx++ < 10000) {
                count += 1;
            }
        }

        public static long calc() {
            final Test test = new Test();
            // 創建兩個線程，執行 add() 操作
            Thread th2 = new Thread(() -> {
                test.add10K();
            });
            Thread th3 = new Thread(() -> {
                test.add10K();
            });
            // 啟動兩個線程
            th2.start();
            th3.start();
            // 等待兩個線程執行結束

            th2.join();
            th3.join();
            return count;
        }
    }

直覺告訴我們應該是 20000，因為在單線程里調用兩次 add10K() 方法，count 的值就是 20000，但實際上 calc() 的執行結果是個 10000 到 20000 之間的隨機數。為什么呢？ 我們假設線程 A 和線程 B 同時開始執行，那么第一次都會將 count=0 讀到各自的 CPU 緩存里，執行完 count+=1 之后，各自 CPU 緩存里的值都是 1，同時寫入內存后，我們 會發現內存中是 1，而不是我們期望的 2。之后由于各自的 CPU 緩存里都有了 count 的 值，兩個線程都是基于 CPU 緩存里的 count 值來計算，所以導致最終 count 的值都是小 于 20000 的。這就是緩存的可見性問題。
循環 10000 次 count+=1 操作如果改為循環 1 億次，你會發現效果更明顯，最終 count 的值接近 1 億，而不是 2 億。如果循環 10000 次，count 的值接近 20000，原因是兩個線程不是同時啟動的，有一個時差。

源頭二：線程切換帶來的原子性問題

由于 IO 太慢，早期的操作系統就發明了多進程，即便在單核的 CPU 上我們也可以一邊聽 著歌，一邊寫 Bug，這個就是多進程的功勞。
操作系統允許某個進程執行一小段時間，例如 50 毫秒，過了 50 毫秒操作系統就會重新選擇一個進程來執行（我們稱為“任務切換”），這個 50 毫秒稱為“時間片”。

Java 并發程序都是基于多線程的，自然也會涉及到任務切換，也許你想不到，任務切換竟 然也是并發編程里詭異 Bug 的源頭之一。任務切換的時機大多數是在時間片結束的時候， 我們現在基本都使用高級語言編程，高級語言里一條語句往往需要多條 CPU 指令完成，例 如上面代碼中的count += 1，至少需要三條 CPU 指令。

• 指令 1：首先，需要把變量 count 從內存加載到 CPU 的寄存器；

• 指令 2：之后，在寄存器中執行 +1 操作；

• 指令 3：最后，將結果寫入內存（緩存機制導致可能寫入的是 CPU 緩存而不是內存）。

操作系統做任務切換，可以發生在任何一條CPU 指令執行完，是的，是 CPU 指令，而不 是高級語言里的一條語句。對于上面的三條指令來說，我們假設 count=0，如果線程 A 在指令 1 執行完后做線程切換，線程 A 和線程 B 按照下圖的序列執行，那么我們會發現 兩個線程都執行了 count+=1 的操作，但是得到的結果不是我們期望的 2，而是 1。

我們潛意識里面覺得 count+=1 這個操作是一個不可分割的整體，就像一個原子一樣，線 程的切換可以發生在 count+=1 之前，也可以發生在 count+=1 之后，但就是不會發生 在中間。我們把一個或者多個操作在 CPU 執行的過程中不被中斷的特性稱為原子性。

源頭之三：編譯優化帶來的有序性問題

有序性指的是程序按照代碼的先后順序執行。編譯器為了優化性能，有時候會改 變程序中語句的先后順序，例如程序中：“a=6；b=7；”編譯器優化后可能變 成“b=7；a=6；”，在這個例子中，編譯器調整了語句的順序，但是不影響程序的最終 結果。不過有時候編譯器及解釋器的優化可能導致意想不到的 Bug。
在 Java 領域一個經典的案例就是利用雙重檢查創建單例對象（DCL單例模式），例如下面的代碼：在獲取實 例 getInstance() 的方法中，我們首先判斷 instance 是否為空，如果為空，則鎖定 Singleton.class 并再次檢查 instance 是否為空，如果還為空則創建 Singleton 的一個實例。

    public class Singleton {
        static Singleton instance;

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

這看上去一切都很完美，無懈可擊，但實際上這個 getInstance() 方法并不完美。問題出 在哪里呢？出在 new 操作上，我們以為的 new 操作應該是：

1. 分配一塊內存 M；

2. 在內存 M 上初始化 Singleton 對象；

3. 然后 M 的地址賦值給 instance 變量。

但是實際上優化后的執行路徑卻是這樣的：

1. 分配一塊內存 M；

2. 將 M 的地址賦值給 instance 變量；

3. 最后在內存 M 上初始化 Singleton 對象。

那么優化后會導致什么問題呢？看下圖，相信你一定會明白了！

感謝各位的閱讀，以上就是“java可見性、原子性、有序性在并發場景下的原理”的內容了，經過本文的學習后，相信大家對java可見性、原子性、有序性在并發場景下的原理這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！