溫馨提示×

溫馨提示×

您好,登錄后才能下訂單哦!

密碼登錄×
登錄注冊×
其他方式登錄
點擊 登錄注冊 即表示同意《億速云用戶服務(wù)條款》

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

發(fā)布時間:2021-09-10 11:56:21 來源:億速云 閱讀:122 作者:chen 欄目:大數(shù)據(jù)

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

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

在單核時代,所有的線程都是在一顆 CPU 上執(zhí)行,CPU 緩存與內(nèi)存的數(shù)據(jù)一致性容易解 決。因為所有線程都是操作同一個 CPU 的緩存,一個線程對緩存的寫,對另外一個線程來 說一定是可見的。例如在下面的圖中,線程 A 和線程 B 都是操作同一個 CPU 里面的緩 存,所以線程 A 更新了變量 V 的值,那么線程 B 之后再訪問變量 V,得到的一定是 V 的 最新值(線程 A 寫過的值)。
java可見性、原子性、有序性在并發(fā)場景下的原理
一個線程對共享變量的修改,另外一個線程能夠立刻看到,我們稱為可見性

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

下面我們再用一段代碼來驗證一下多核場景下的可見性問題。下面的代碼,每執(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,因為在單線程里調(diào)用兩次 add10K() 方法,count 的值就是 20000,但實際上 calc() 的執(zhí)行結(jié)果是個 10000 到 20000 之間的隨機數(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,原因是兩個線程不是同時啟動的,有一個時差。
java可見性、原子性、有序性在并發(fā)場景下的原理

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

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

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

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

  • 指令 2:之后,在寄存器中執(zhí)行 +1 操作;

  • 指令 3:最后,將結(jié)果寫入內(nèi)存(緩存機制導(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。
java可見性、原子性、有序性在并發(fā)場景下的原理
我們潛意識里面覺得 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單例模式),例如下面的代碼:在獲取實 例 getInstance() 的方法中,我們首先判斷 instance 是否為空,如果為空,則鎖定 Singleton.class 并再次檢查 instance 是否為空,如果還為空則創(chuàng)建 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 操作應(yīng)該是:

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

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

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

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

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

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

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

那么優(yōu)化后會導(dǎo)致什么問題呢?看下圖,相信你一定會明白了! java可見性、原子性、有序性在并發(fā)場景下的原理

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

向AI問一下細節(jié)

免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點不代表本網(wǎng)站立場,如果涉及侵權(quán)請聯(lián)系站長郵箱:is@yisu.com進行舉報,并提供相關(guān)證據(jù),一經(jīng)查實,將立刻刪除涉嫌侵權(quán)內(nèi)容。

AI