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

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

成都創(chuàng)新互聯(lián)公司堅持“要么做到，要么別承諾”的工作理念，服務(wù)領(lǐng)域包括：網(wǎng)站制作、網(wǎng)站建設(shè)、企業(yè)官網(wǎng)、英文網(wǎng)站、手機(jī)端網(wǎng)站、網(wǎng)站推廣等服務(wù)，滿足客戶于互聯(lián)網(wǎng)時代的金壇網(wǎng)站設(shè)計、移動媒體設(shè)計的需求，幫助企業(yè)找到有效的互聯(lián)網(wǎng)解決方案。努力成為您成熟可靠的網(wǎng)絡(luò)建設(shè)合作伙伴！

源頭一：緩存導(dǎo)致的可見性問題

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

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

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

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

    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();
            // 創(chuàng)建兩個線程，執(zhí)行 add() 操作
            Thread th2 = new Thread(() -> {
                test.add10K();
            });
            Thread th3 = new Thread(() -> {
                test.add10K();
            });
            // 啟動兩個線程
            th2.start();
            th3.start();
            // 等待兩個線程執(zhí)行結(jié)束

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

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

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

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

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

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

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

• 指令 3：最后，將結(jié)果寫入內(nèi)存（緩存機(jī)制導(dǎo)致可能寫入的是 CPU 緩存而不是內(nèi)存）。

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

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

源頭之三：編譯優(yōu)化帶來的有序性問題

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

    public class Singleton {
        static Singleton instance;

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

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

1. 分配一塊內(nèi)存 M；

2. 在內(nèi)存 M 上初始化 Singleton 對象；

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

但是實(shí)際上優(yōu)化后的執(zhí)行路徑卻是這樣的：

1. 分配一塊內(nèi)存 M；

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

3. 最后在內(nèi)存 M 上初始化 Singleton 對象。

那么優(yōu)化后會導(dǎo)致什么問題呢？看下圖，相信你一定會明白了！

感謝各位的閱讀，以上就是“java可見性、原子性、有序性在并發(fā)場景下的原理”的內(nèi)容了，經(jīng)過本文的學(xué)習(xí)后，相信大家對java可見性、原子性、有序性在并發(fā)場景下的原理這一問題有了更深刻的體會，具體使用情況還需要大家實(shí)踐驗(yàn)證。這里是創(chuàng)新互聯(lián)，小編將為大家推送更多相關(guān)知識點(diǎn)的文章，歡迎關(guān)注！

本文名稱：java可見性、原子性、有序性在并發(fā)場景下的原理
網(wǎng)頁鏈接：http://muchs.cn/article4/ghesie.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供品牌網(wǎng)站制作、微信小程序、、域名注冊、做網(wǎng)站、響應(yīng)式網(wǎng)站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)