• 本章難度：★★☆☆☆
• 本章重點：掌握多個線程同時讀寫同一共享變量存在共享問題的根本原因，重點掌握CPU內存模式和Java內存模型的核心原理，緩存一致性問題及其產(chǎn)生的原因，并能夠根據(jù)CPU內存模型和Java內存模型編寫線程安全的代碼。

大家好，我是冰河~~

“原來如此啊，真沒想到統(tǒng)計個調用商品詳情接口次數(shù)的功能背后還會牽扯到這么多知識點，這些知識之前確實沒聽說過，看來確實有很多我之前不知道的東西呀，以后跟著老大好好學，爭取跟他一樣厲害”，小菜默默的在心里嘀咕著。

一、情景再現(xiàn)

小菜憑借著之前在學校的傳奇經(jīng)歷順利進入一家頭部互聯(lián)網(wǎng)公司實習，幾天后，被分配到一個統(tǒng)計線上調用商品詳情接口的任務，本以為很簡單的功能，小菜也三下五除二的完成了開發(fā)任務，但是在測試時，卻被告知小菜統(tǒng)計出來的結果和實際結果差距太大。經(jīng)過一天的排查和定位，小菜最終也沒有找出問題出在哪里。

二、尋求幫助

第二天，小菜早早來到公司，還在思考著昨天為什么自己寫的代碼明明看起來沒問題，卻跟實際統(tǒng)計結果差距這么大。

正當小菜還在糾結時，他突然聽到：“小菜，怎么樣了，知道昨天為什么會出現(xiàn)問題了嗎？”。

小菜轉過頭一看，原來是自己的直屬領導老王到公司了，“沒有呀，我昨天下班后也在想這個問題，但是還是沒找到原因”。

此時，小菜起身來到老王的工位旁邊，“老大，昨天我搞到很晚也沒發(fā)現(xiàn)啥問題，你可以給我講講哪里出了問題嗎？”。

“可以”，老王一邊說著，一邊從電腦包里拿出自己的電腦。“其實，要搞清楚為啥昨天你寫的代碼會出問題，這就涉及到內存模型了，說到內存模型，就要從CPU內存模型和Java內存模型兩個方面進行講述了”。

“這樣吧，小菜拿上筆和本，現(xiàn)在會議室沒人使用，我單獨給你講講”。

“好的”，小菜邊說，邊回到工位拿筆和本子，老王則拿起了自己的電腦，二人一起到會議室走去。

三、CPU內存模型

“以前了解過CPU內存模型嗎？”。

“在學校聽老師講過，不過講的不夠深入和具體，我也了解的不多，我確實也想不出來這跟昨天實現(xiàn)的功能有啥關系”。

“沒關系，我今天給你講一下”，老王邊說，邊打開了電腦和投影儀。

“你昨天寫的代碼出問題，本質上與內存模型有關，說到內存模型呢，又會涉及到CPU內存模型和Java內存模型，我們先來講講CPU內存模型吧”，老王將自己的電腦投到投影儀上。

“好的”，小菜邊聽邊在本子上記。

老王接著說：“Java程序一般都是運行在JVM上，JVM本身有自己的內存模型，Java的內存模型其實與CPU的內存模型有很多相似之處。如果是CPU內存模型呢，計算機執(zhí)行程序時，每條執(zhí)行指令都是在CPU中執(zhí)行的，并且在CPU執(zhí)行指令的過程中就會涉及到數(shù)據(jù)的讀寫操作，CPU并不會直接從計算機的磁盤上讀數(shù)據(jù)，而是從計算機的主存，也就是我們常說的內存中讀取數(shù)據(jù)，并且CPU也會將處理的結果數(shù)據(jù)寫回主存”。

老王一邊說，一邊在腦電上畫出了這樣一張圖，如圖2-1所示。

圖片

“你在大學里應該學到過，其實CPU的執(zhí)行速度是非?？斓?，會比內存的讀寫速度快的多”，老王畫完圖說道。

“是的，這個我了解過”，小菜回應道。

“CPU的執(zhí)行速度和內存的讀寫速度存在巨大的速度差，這樣就會存在一個問題，由于CPU在處理任務時，需要從內存中讀取數(shù)據(jù)，內存的讀寫速度遠遠不及CPU的執(zhí)行速度，這樣就會導致CPU的執(zhí)行速度大大下降”。

“為了解決這個問題，CPU的架構師們在CPU內部設計了一個高速緩沖區(qū)，用來平緩CPU執(zhí)行速度與內存讀寫速度之間的差距。在執(zhí)行時，會將CPU執(zhí)行任務要讀取的數(shù)據(jù)從內存讀取到CPU的告訴緩沖區(qū)，然后CPU再從高速緩沖區(qū)讀取數(shù)據(jù)后執(zhí)行任務。當CPU執(zhí)行完任務，也是先將結果數(shù)據(jù)寫回到高速緩沖區(qū)，隨后再將高速緩沖區(qū)的數(shù)據(jù)刷新到內存，這樣CPU的執(zhí)行效率就大大提升了，我們再來畫一張圖”。

說完，老王又畫了一張圖，如圖2-2所示。

圖片

“你可以記一下這張圖，這里咱們也暫時不展開講，如果展開講的話，會涉及到很多的知識點，比如CPU多級緩存架構，緩存一致性，偽共享，內存屏障等等很多知識點，一時半會兒也講不完，如果今天都講了的話，我估計你可能也消化不完，所以，關于CPU內存模型，今天就講到這里”。

“好的”，小菜邊聽，邊拿本子記下了這張圖。

“如果你對CPU多級緩存架構，緩存一致性，偽共享，內存屏障等等這些知識點感興趣，想進一步學習的話，我給你推薦一本書，就是冰河寫的《深入理解高并發(fā)編程：核心原理與案例實戰(zhàn)》這本書，這本書剖析了并發(fā)編程出現(xiàn)各種詭異Bug問題的根源，從本質上深度解析了并發(fā)編程的核心原理，并且給出了很實用的實戰(zhàn)案例，吃透這本書，對你學習并發(fā)編程幫助很大，這本書在京東和當當都在售”。老王繼續(xù)說道。

“好的”，小菜也記下了這本書的書名，準備入手一本。

“那我們再來講講Java內存模型”。

四、Java內存模型

“說起Java內存模型，其實與CPU內存模型有很多相似的地方，只是說Java內存模型中屏蔽了不同操作系統(tǒng)和底層硬件之間的訪問差異，能夠在不同的操作系統(tǒng)和底層硬件之間達到一致的訪問效果”，老王一邊說，一邊畫圖，畫了一張線程、主內存、工作內存的關系圖，如圖2-3所示。

圖片

“Java內存模型規(guī)定了所有的變量都存儲在主內存中，也就是存儲在計算機的物理內存中，每個線程都有自己的工作內存，用于存儲線程私有的數(shù)據(jù)，線程對變量的所有操作都需要在工作內存中完成。一個線程不能直接訪問其他線程工作內存中的數(shù)據(jù)，只能通過主內存進行數(shù)據(jù)交互。也就是說，線程在執(zhí)行任務時，會先將數(shù)據(jù)從主內存復制到自己的工作內存，然后執(zhí)行對應的任務，任務執(zhí)行完畢后，會將計算的結果數(shù)據(jù)，從自己的工作內存刷新到主內存，這就與CPU內存模型很相似了”。

老王邊說邊喝了口水，繼續(xù)道：“你先消化下，CPU內存模型和Java內存模型，接下來，我們再講講你昨天寫的代碼為啥會出問題”。

“好的”，小菜回應道，隨后小菜就在本子上迅速的記著。。。

五、緩存一致性問題

“好了，接下來，我們就來分析下你昨天代碼出現(xiàn)的問題原因吧”。

“好的”。

“我們還是先來看看你昨天寫的代碼”，老王一邊說，一邊打開開發(fā)環(huán)境，打開了小菜昨天寫的代碼。

public class WrongCounter {

    private int visitCount;

    public void accessVisit(){
        visitCount++;
    }

    public int getVisitCount() {
        return visitCount;
    }
}

“現(xiàn)在我們就結合這個有問題的類來講，假設同一時刻有兩個線程調用了獲取商品詳情數(shù)據(jù)的接口，兩個線程都觸發(fā)了WrongCounter類中的accessVisit()方法。也就是說，兩個線程都執(zhí)行了visitCount++操作，你知道visitCount++操作在內存中是如何執(zhí)行的嗎？”，老王問小菜。

“這個不太清楚”。

“好的，那我們就來講一下，其實visitCount++操作總體上會在內存中分為三個步驟”。

1.從主內存讀取visitCount的值。

2.將visitCount的值進行加1操作。

3.將visitCount的值寫回主內存。

“我們一步步講，這樣你也好理解些”，老王繼續(xù)說，“我們先來看第1步：從主內存讀取visitCount的值。假設同一時刻有兩個線程同時調用了獲取商品詳情的接口，并且觸發(fā)了 visitCount++操作，此時結合Java內存模型看的話，就像這張圖一樣”。

老王是真厲害，隨手又畫了一張圖，如圖2-4所示。

圖片

“在步驟1從主內存讀取visitCount的值時，線程1和線程2都會把主內存中的visitCount值讀取到自己的工作內存中，此時線程1和線程2自身工作內存中的visitCount值都是0，這點能理解嗎？”。

“能理解”，小菜回應道。

“好，我們再來接著講第2步：將visitCount的值進行加1操作，還是畫一張圖看的清晰些”，老王又畫了一張圖，如圖2-5所示。

圖片

“此時，線程1和線程2都將讀取到自己工作內存中的visitCount的值進行加1，此時線程1和線程2各自工作內存中的visitCount值都是1，這點能理解嗎？”。

“能理解”。

“好，我們再來看第3步：將visitCount的值寫回主內存，還是來一張圖”，老王確實厲害，隨手又畫了一張圖，如圖2-6所示。

圖片

“線程1和線程2都會將自己計算出的結果數(shù)據(jù)寫到自身的工作內存，再刷新回主內存，在實際場景中，線程1和線程2的執(zhí)行結果刷新回主內存的先后順序是隨機的，可能是線程1的結果先刷新回主內存，也可能是線程2的結果先刷新回主內存。但無論是先刷新線程1的結果，還是先刷新線程2的結果，最終主內存中的visitCount的值都是1，這與我們期望的結果不同，我們期望的結果是2，實際結果卻是1，這下明白昨天你寫的代碼為什么出問題了吧？”。

“明白了，明白了”，小菜連忙回應道，”真沒想到寫個功能還牽扯到這么多知識點，真是又學到不少知識呀“。

六、如何解決問題

“現(xiàn)在明白了昨天寫的代碼為何會出現(xiàn)問題，那知道怎么解決嗎？”，老王問。

“大概知道點，但是不是很明白”。

“好，那我們再講講怎么解決問題吧”。

“好的”。

“我們再次看看visitCount++操作在內存中的執(zhí)行流程”。

1.從主內存讀取visitCount的值。

2.將visitCount的值進行加1操作。

3.將visitCount的值寫回主內存。

“既然visitCount++操作在內存中的執(zhí)行流程會被分成3個步驟，那如果能夠保證這3個步驟的原子性，也就是說，線程1完全執(zhí)行完畢這三個步驟，線程2再從主內存中讀取數(shù)據(jù)進行處理。或者線程2完全執(zhí)行完畢這三個步驟，線程1再從主內存中讀取數(shù)據(jù)進行處理，這樣就能保證最終的結果數(shù)據(jù)與預期相符。這么說明白了嗎？”。

“明白了”。

“好的，那我們今天就講到這，根據(jù)今天我們講的內容，你把昨天寫的代碼嘗試修改下，不明白的地方再來問我”。

“好的，謝謝你，老大，今天確實學到不少知識，回去我也好好總結下”。

七、本章總結

本章，以故事場景的方式結合代碼問題，以圖文的形式重點介紹了CPU內存模型和Java內存模型，CPU內存模型和Java內存模型雖然平滑了CPU執(zhí)行計算與讀寫主內存之間的速度差異，但是也引入了新的問題，那就是緩存一致性問題。本章，也結合代碼示例與圖文詳細介紹了緩存一致性問題。最后，簡單敘述了如何解決相關的問題。

最后，可以在評論區(qū)寫下你學完本章節(jié)的收獲，祝大家都能學有所成，我們一起搞定高并發(fā)設計模式。