您好,登錄后才能下訂單哦!
這篇文章主要講解了“java可見性、原子性、有序性在并發(fā)場景下的原理”,文中的講解內(nèi)容簡單清晰,易于學(xué)習(xí)與理解,下面請大家跟著小編的思路慢慢深入,一起來研究和學(xué)習(xí)“java可見性、原子性、有序性在并發(fā)場景下的原理”吧!
在單核時代,所有的線程都是在一顆 CPU 上執(zhí)行,CPU 緩存與內(nèi)存的數(shù)據(jù)一致性容易解 決。因為所有線程都是操作同一個 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 而言就不具備可見性了。這個就屬于硬 件程序員給軟件程序員挖的“坑”。
下面我們再用一段代碼來驗證一下多核場景下的可見性問題。下面的代碼,每執(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,原因是兩個線程不是同時啟動的,有一個時差。
由于 IO 太慢,早期的操作系統(tǒng)就發(fā)明了多進程,即便在單核的 CPU 上我們也可以一邊聽 著歌,一邊寫 Bug,這個就是多進程的功勞。
操作系統(tǒng)允許某個進程執(zhí)行一小段時間,例如 50 毫秒,過了 50 毫秒操作系統(tǒng)就會重新選擇一個進程來執(zhí)行(我們稱為“任務(wù)切換”),這個 50 毫秒稱為“時間片”。
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。
我們潛意識里面覺得 count+=1 這個操作是一個不可分割的整體,就像一個原子一樣,線 程的切換可以發(fā)生在 count+=1 之前,也可以發(fā)生在 count+=1 之后,但就是不會發(fā)生 在中間。我們把一個或者多個操作在 CPU 執(zhí)行的過程中不被中斷的特性稱為原子性。
有序性指的是程序按照代碼的先后順序執(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)該是:
分配一塊內(nèi)存 M;
在內(nèi)存 M 上初始化 Singleton 對象;
然后 M 的地址賦值給 instance 變量。
但是實際上優(yōu)化后的執(zhí)行路徑卻是這樣的:
分配一塊內(nèi)存 M;
將 M 的地址賦值給 instance 變量;
最后在內(nèi)存 M 上初始化 Singleton 對象。
那么優(yōu)化后會導(dǎo)致什么問題呢?看下圖,相信你一定會明白了!
感謝各位的閱讀,以上就是“java可見性、原子性、有序性在并發(fā)場景下的原理”的內(nèi)容了,經(jīng)過本文的學(xué)習(xí)后,相信大家對java可見性、原子性、有序性在并發(fā)場景下的原理這一問題有了更深刻的體會,具體使用情況還需要大家實踐驗證。這里是億速云,小編將為大家推送更多相關(guān)知識點的文章,歡迎關(guān)注!
免責(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)容。