Java并發中的內存模型

這篇文章主要講解了“Java并發中的內存模型”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“Java并發中的內存模型”吧！

CPU和內存

在講JMM之前，我想先和大家聊聊硬件層面的東西。大家應該都知道執行運算操作的CPU本身是不具備存儲能力的，它只負責根據指令對傳遞進來的數據做相應的運算，而數據存儲這一任務則交給內存去完成。雖然內存的運行速度雖然比起硬盤快非常多，但是和3GHZ，4GHZ,甚至5GHZ的CPU比起來還是太慢了，在CPU的眼中，內存運行的速度簡直就是弟弟中的弟弟，等內存進行一次讀寫操作，CPU能思考成百上千次人生了:grin:。但是CPU的運算能力是緊缺資源啊，可不能這么白白浪費了，所以得想辦法解決這一個問題。

沒有什么問題是一個緩存不能解決的，如果有，那就再加一個緩存 ——魯迅：反正我沒說這句話

所以人們就想到了給CPU增加一個高速緩存（為什么是加高速緩存而不是給內存提高速度就牽扯到硬件成本問題了）來解決這個問題，比如像博主用的Intel的I9 9900k CPU就帶了高達16M的三級緩存，所以硬件上的內存模型大概如下圖所示。

如圖可以很清楚的看到，在CPU內部構建了一到多層的緩存，并且其中的L1 Cache是CPU內核心獨有的，不同的Core之間是不能共享的，而L2 Cache則是所有的核心共享。簡單來說就是CPU在讀取一個數據時會先去最近的Cache層級上讀取，如果找不到則會去下一個層級尋找，都找不到的話就會從內存中去加載，而如果Cache中能拿到所需要的數據就不會去內存讀取。在將數據寫回的時候也會先寫入Cache中，等待合適的時機再寫入到內存中（其中有一個細節就是緩存行的問題，關于這部分內容放在文章結尾）。而由于存在多個cache層級，并且部分cache還不能夠被共享，所以會存在內存可見性的問題。

舉個簡單的例子： 假設現在存在兩個Core，分別是CoreA和CoreB并且他們都擁有屬于自己的L1Chace和共用的L2Cache。同時有一個變量X的值為1，該變量已經被加載在L2Cahce上。此時CoreA執行運算需要用到變量X，先去L1Cache尋找，未命中，繼續在L2Cache尋找，命中成功，將X=1載入L1Cahce，再經過一系列運算后將X修改為2并寫入L1Cache。于此同時CoreB剛好也需要X來進行運算，此時他去自己的L1Cahce尋找，未命中，繼續L2Cache尋找，命中成功，將X=1載入自己的L1Cache。此時就出現了問題，CoreA明明已經將X的值修改為2了，CoreB讀取到的依然是X=1，這就是內存可見性問題。

看到這里的小伙伴們可能要問了，博主你啥情況啊，你這寫的漸漸忘記標題了啊，說好了Java內存模型，你扯這么多硬件上的問題干啥啊？(╯‵□′)╯︵┻━┻

Java中的主內存和工作內存

小伙伴們別著急，其實JMM和上面的硬件層次上的模型很像，不信看下面的圖片

怎么樣，是不是看起來很像，可以簡單的理解為線程的工作內存就是CPU里Core獨占的L1Cahce，而主內存就是共享的L2Cache。所以上述的內存一致性問題也會在JMM中存在，而JMM就需要制定一些列的規則來保證內存一致性，這也是Java多線程并發的一個疑難點，那么JMM制定了哪些規則呢？

內存間交互操作 首先是主內存的工作內存之間的交互協議，具體來說定義了以下幾個操作（并且保證這幾個操作都是原子性的）：

• lock （鎖定）作用于主內存的變量，將一個變量標識為一個線程獨占狀態

• unlock（解鎖）作用于主內存的變量，將一個處于鎖定狀態的變量釋放出來，釋放之后才能被其他線程鎖定

• read（讀取）作用于主內存的變量，將一個變量的值從主內存傳輸到線程工作內存中，便于之后的load操作使用

• load（載入）作用于工作內存的變量，它把read操作從主內存中得到的變量值放入工作內存的變量副本中。

• use（使用）作用于工作內存的變量，把工作內存中的一個變量值傳遞給執行引擎，每當虛擬機遇到一個需要使用變量的值的字節碼指令時將會執行這個操作。

• assign（賦值）作用于工作內存的變量，它把一個從執行引擎接收到的值賦值給工作內存的變量，每當虛擬機遇到一個給變量賦值的字節碼指令時執行這個操作。

• store（存儲）作用于工作內存的變量，把工作內存中的一個變量的值傳送到主內存中，以便隨后的write的操作。

• write（寫入）作用于主內存的變量，它把store操作從工作內存中一個變量的值傳送到主內存的變量中。

同時還規定了執行上述八個操作時必須遵循以下規則：

• 如果要把一個變量從主內存中復制到工作內存，就需要按順尋地執行read和load操作， 如果把變量從工作內存中同步回主內存中，就要按順序地執行store和write操作。但Java內存模型只要求上述操作必須按順序執行，而沒有保證必須是連續執行。

• 不允許read和load、store和write操作之一單獨出現

• 不允許一個線程丟棄它的最近assign的操作，即變量在工作內存中改變了之后必須同步到主內存中。

• 不允許一個線程無原因地（沒有發生過任何assign操作）把數據從工作內存同步回主內存中。

• 一個新的變量只能在主內存中誕生，不允許在工作內存中直接使用一個未被初始化（load或assign）的變量。即就是對一個變量實施use和store操作之前，必須先執行過了assign和load操作。

• 一個變量在同一時刻只允許一條線程對其進行lock操作，但lock操作可以被同一條線程重復執行多次，多次執行lock后，只有執行相同次數的unlock操作，變量才會被解鎖。lock和unlock必須成對出現

• 如果對一個變量執行lock操作，將會清空工作內存中此變量的值，在執行引擎使用這個變量前需要重新執行load或assign操作初始化變量的值

• 如果一個變量事先沒有被lock操作鎖定，則不允許對它執行unlock操作；也不允許去unlock一個被其他線程鎖定的變量。

• 對一個變量執行unlock操作之前，必須先把此變量同步到主內存中（執行store和write操作）。

（上述部分參考并引用《深入理解Java虛擬機》中的內容）

volatile（能夠保證內存可見性和禁止指令重排序）

對于volatile修飾的變量，JMM對其有一些特殊的規定。

內存可見性

往簡單來說volatile關鍵字可以理解為，有一個volatile修飾的變量x，當一個線程需要使用該變量的時候，直接從主內存中讀取，而當一個線程修改該變量的值時，直接寫入到主內存中。根據之前的分析我們能得出具備這些特性的volatile能夠保證一個變量的內存可見性和內存一致性。

指令重排序

指令重排序是一個大部分CPU都有的操作，同時JVM在運行時也會存在指令重排序的操作。 簡單舉個:chestnut:

      private void test(){        int a,b,c;//1
        a=1;//2
        b=3;//3
        c=a+b;//4
    }

假設有上面這么一個方法，內部有這4行代碼。那么JVM可能會對其進行指令重排序，而指令重排序的規定則是as-if-serial 不管怎么重排序（編譯器和處理器為了提高并行度），（單線程）程序的執行結果不能被改變。根據這一規定，編譯器和處理器不會對有依賴關系的指令重排序，但是對沒有依賴的指令則可能會進行重排序。放在上面的例子里面就是，第1行代碼和2，3，4行代碼是有依賴關系的，所以第一行代碼的指令必須排在2，3，4之前，因為不可能對一個未定義的變量進行賦值操作。而第2，3行代碼之間并沒有相互依賴關系，所以此處可能會發生指令重排序，先執行3，再執行2。而最后的第4行代碼和之前的3行代碼都有依賴關系，所以他一定會放在最后執行。

既然JVM特別指出指令重排序只在單線程下和未排序的效果一致，那是否表示在多線程下會存在一些問題呢？ 答案是肯定的，多線程下指令重排序會帶來一些意想不到的結果。

 int a=0;    //flag作為一個標識符，標識是否寫入完成
    boolean flag = false;    public void writer(){
        a=10;//1
        flag=true;//2
    }    public void reader(){        if (flag)
            System.out.println("a:"+a);
    }

假設存在一個類，他有上述部分的field和method，該類在設計上以flag作為寫入是否完成的標志，在單線程下這并不會存在問題。而此時有兩個線程分別執行writer和reader方法，暫時不考慮內存可見性的問題，假設對a和flag的寫入，是立即被其他線程所知曉的，這個時候大家覺得輸出a的值為多少？10？

即使不考慮內存可見性，此時a的值還是有可能會輸出0，這就是指令重排序帶來的問題。在上述代碼中注釋1和2處的代碼是沒有依賴關系的，在單線程下先執行1還是2都沒有任何問題，根據as-if-serial 原則此時就可能會發生指令重排序。

而volatile關鍵字可以禁止指令重排序。

long，double的問題

我們都知道JMM定義的8個主內存和工作內存之間的操作都是具備原子性的，但是對long和double這兩個64位的數據類型有一些例外。

允許虛擬機將沒有被volatile修飾的long和double的64數據的讀寫操作劃分為兩次32位的讀寫操作，即不要求虛擬機保證對他們的load ,store,read,write四個操作的原子性。 但是大部分的虛擬機實現都保證了這四個操作的原子性的，所以大部分時候我們都不需要刻意的對long，double對象使用volatile修飾。

性能問題

volatile是Java提供的保證內存可見性的最輕量級操作，比起重量級的synchronized能快上不少，但是具體能快多少這部分沒辦法量化。而我們可以知道的是volatile修飾的變量讀操作的性能消耗幾乎和普通變量相差無幾，而寫操作則會慢上一些。所以當volatile能解決我們的問題的時候（內存可見性和禁止指令重排序），我們應該優先選擇使用volatile而不是鎖。

synchronized的內存語義

簡單概括就是

當程序進入synchronized塊時，把在synchronized塊中用到的變量從工作內存中清楚，這樣在需要訪問這些變量的時候會重新從主內存中獲取。當程序退出synchronized塊時，把對塊中恭喜變量的修改刷新到主內存。 如此依賴synchronized也能保證了內存的可見性。

final的內存語義

final也能保證內存的可見性

被final修飾的字段在構造器中一旦初始化完成，并且構造器沒有把this引用傳遞出去，那么其他線程中就能看見final字段的值。

后記之CPU緩存行和偽共享

什么是偽共享

根據前面的文章，我們知道CPU和Memory之間是有Cache的，而Cache內部是按行存儲的，行擁有固定的大小，這些行被稱為緩存行。 當CPU訪問的某個變量不在Cache中時，就會去內存里獲取，并將該變量所在內存的一個緩存行大小的數據讀入Cache中。由于一次讀取并不是單個對象而是一整個緩存行，所以可能會存在多個變量被讀入一個緩存行中。而一個緩存行只能同時被一個線程操作，所以當多個線程同時修改一個緩存行里的多個變量時會造成其他線程等待從而帶來性能損耗（但是在單線程情況下，偽共享反而會提升性能，因為一次性可能會緩存多個變量，節省后續變量的讀取時間）。

如何避免偽共享

在Java8之后可以使用JDK提供的@sun.misc.Contended注解來解決偽共享，像Thread中的threadLocalRandom 字段就使用了這個注解。

感謝各位的閱讀，以上就是“Java并發中的內存模型”的內容了，經過本文的學習后，相信大家對Java并發中的內存模型這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！