2023年Q2用戶偏好榜：12+256G版本成新主流
3月份的性能榜、性價比榜和好評榜之后，就要輪到2023年的第二季度偏好榜了，上半年的新機潮已經過去，最明顯的肯定就是大內存和存儲的機型了，另外部分中端機也取消了屏幕塑料支架
這些年，我們的 CPU、內存、I/O 設備都在不斷迭代，不斷朝著更快的方向努力。但是，在這個快速發展的過程中，有一個核心矛盾一直存在，就是這三者的速度差異。CPU 和內存的速度差異可以形象地描述為：CPU 是天上一天，內存是地上一年（假設 CPU 執行一條普通指令需要一天，那么 CPU 讀寫內存得等待一年的時間）。內存和 I/O 設備的速度差異就更大了，內存是天上一天，I/O 設備是地上十年。
程序里大部分語句都要訪問內存，有些還要訪問 I/O，根據木桶理論（一只水桶能裝多少水取決于它最短的那塊木板），程序整體的性能取決于最慢的操作——讀寫 I/O 設備，也就是說單方面提高 CPU 性能是無效的。
為了合理利用 CPU 的高性能，平衡這三者的速度差異，計算機體系機構、操作系統、編譯程序都做出了貢獻，主要體現為：
現在我們幾乎所有的程序都默默地享受著這些成果，但是天下沒有免費的午餐，并發程序很多詭異問題的根源也在這里。
在單核時代，所有的線程都是在一顆 CPU 上執行，CPU 緩存與內存的數據一致性容易解決。因為所有線程都是操作同一個 CPU 的緩存，一個線程對緩存的寫，對另外一個線程來說一定是可見的。例如在下面的圖中，線程 A 和線程 B 都是操作同一個 CPU 里面的緩存，所以線程 A 更新了變量 V 的值，那么線程 B 之后再訪問變量 V，得到的一定是 V 的最新值（線程 A 寫過的值）。
CPU 緩存與內存的關系圖
一個線程對共享變量的修改，另外一個線程能夠立刻看到，我們稱為可見性。
多核時代，每顆 CPU 都有自己的緩存，這時 CPU 緩存與內存的數據一致性就沒那么容易解決了，當多個線程在不同的 CPU 上執行時，這些線程操作的是不同的 CPU 緩存。比如下圖中，線程 A 操作的是 CPU-1 上的緩存，而線程 B 操作的是 CPU-2 上的緩存，很明顯，這個時候線程 A 對變量 V 的操作對于線程 B 而言就不具備可見性了。
多核 CPU 的緩存與內存關系圖
我們再用一段代碼來驗證一下多核場景下的可見性問題。下面的代碼，每執行一次 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 th1 = new Thread(()->{ test.add10K(); }); Thread th2 = new Thread(()->{ test.add10K(); }); // 啟動兩個線程 th1.start(); th2.start(); // 等待兩個線程執行結束 th1.join(); th2.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 的。這就是緩存的可見性問題。
變量 count 在 CPU 緩存和內存的分布圖
由于 IO 太慢，早期的操作系統就發明了多進程，即便在單核的 CPU 上我們也可以一邊聽著歌，一邊寫 Bug，這個就是多進程的功勞。操作系統允許某個進程執行一小段時間，例如 50 毫秒，過了 50 毫秒操作系統就會重新選擇一個進程來執行（我們稱為“任務切換”），這個 50 毫秒稱為“時間片”。
線程切換示意圖
在一個時間片內，如果一個進程進行一個 IO 操作，例如讀個文件，這個時候該進程可以把自己標記為“休眠狀態”并出讓 CPU 的使用權，待文件讀進內存，操作系統會把這個休眠的進程喚醒，喚醒后的進程就有機會重新獲得 CPU 的使用權了。
這里的進程在等待 IO 時之所以會釋放 CPU 使用權，是為了讓 CPU 在這段等待時間里可以做別的事情，這樣一來 CPU 的使用率就上來了；此外，如果這時有另外一個進程也讀文件，讀文件的操作就會排隊，磁盤驅動在完成一個進程的讀操作后，發現有排隊的任務，就會立即啟動下一個讀操作，這樣 IO 的使用率也上來了。
早期的操作系統基于進程來調度 CPU，不同進程間是不共享內存空間的，所以進程要做任務切換就要切換內存映射地址，而一個進程創建的所有線程，都是共享一個內存空間的，所以線程做任務切換成本就很低了。現代的操作系統都基于更輕量的線程來調度，現在我們提到的“任務切換”都是指“線程切換”。
Java 并發程序都是基于多線程的，自然也會涉及到任務切換，也許你想不到，任務切換竟然也是并發編程里詭異 Bug 的源頭之一。任務切換的時機大多數是在時間片結束的時候，我們現在基本都使用高級語言編程，高級語言里一條語句往往需要多條 CPU 指令完成，例如上面代碼中的count += 1，至少需要三條 CPU 指令。
操作系統做任務切換，可以發生在任何一條CPU 指令執行完，是的，是 CPU 指令，而不是高級語言里的一條語句。對于上面的三條指令來說，我們假設 count=0，如果線程 A 在指令 1 執行完后做線程切換，線程 A 和線程 B 按照下圖的序列執行，那么我們會發現兩個線程都執行了 count+=1 的操作，但是得到的結果不是我們期望的 2，而是 1。
非原子操作的執行路徑示意圖
我們潛意識里面覺得 count+=1 這個操作是一個不可分割的整體，就像一個原子一樣，線程的切換可以發生在 count+=1 之前，也可以發生在 count+=1 之后，但就是不會發生在中間。我們把一個或者多個操作在 CPU 執行的過程中不被中斷的特性稱為原子性。CPU 能保證的原子操作是 CPU 指令級別的，而不是高級語言的操作符，這是違背我們直覺的地方。因此，很多時候我們需要在高級語言層面保證操作的原子性。
有序性。顧名思義，有序性指的是程序按照代碼的先后順序執行。編譯器為了優化性能，有時候會改變程序中語句的先后順序，例如程序中：“a=6；b=7；”編譯器優化后可能變成“b=7；a=6；”，在這個例子中，編譯器調整了語句的順序，但是不影響程序的最終結果。不過有時候編譯器及解釋器的優化可能導致意想不到的 Bug。
在 Java 領域一個經典的案例就是利用雙重檢查創建單例對象，例如下面的代碼：在獲取實例 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; }}假設有兩個線程 A、B 同時調用 getInstance() 方法，他們會同時發現 instance == null
，于是同時對 Singleton.class 加鎖，此時 JVM 保證只有一個線程能夠加鎖成功（假設是線程 A），另外一個線程則會處于等待狀態（假設是線程 B）；線程 A 會創建一個 Singleton 實例，之后釋放鎖，鎖釋放后，線程 B 被喚醒，線程 B 再次嘗試加鎖，此時是可以加鎖成功的，加鎖成功后，線程 B 檢查 instance == null 時會發現，已經創建過 Singleton 實例了，所以線程 B 不會再創建一個 Singleton 實例。
這看上去一切都很完美，無懈可擊，但實際上這個 getInstance() 方法并不完美。問題出在哪里呢？出在 new 操作上，我們以為的 new 操作應該是：
但是實際上優化后的執行路徑卻是這樣的：
優化后會導致什么問題呢？我們假設線程 A 先執行 getInstance() 方法，當執行完指令 2 時恰好發生了線程切換，切換到了線程 B 上；如果此時線程 B 也執行 getInstance() 方法，那么線程 B 在執行第一個判斷時會發現 instance != null，所以直接返回 instance，而此時的 instance 是沒有初始化過的，如果我們這個時候訪問 instance 的成員變量就可能觸發空指針異常。
雙重檢查創建單例的異常執行路徑
要寫好并發程序，首先要知道并發程序的問題在哪里，只有確定了“靶子”，才有可能把問題解決，畢竟所有的解決方案都是針對問題的。并發程序經常出現的詭異問題看上去非常無厘頭，但是深究的話，無外乎就是直覺欺騙了我們，只要我們能夠深刻理解可見性、原子性、有序性在并發場景下的原理，很多并發 Bug 都是可以理解、可以診斷的。
本文鏈接：http://m.www897cc.com/showinfo-26-75339-0.html可見性、原子性和有序性問題：并發編程Bug的源頭
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號