啃碎併發（九）：內存模型之基礎概述

0 前言

在併發編程中，須要解決兩個關鍵問題：

1. 線程之間如何通訊；
2. 線程之間如何同步；

線程通訊是指線程之間以何種機制來交換信息。在命令式編程中，線程之間的通訊機制有兩種：共享內存和消息傳遞。

在共享內存的併發模型裏，線程之間共享程序的公共狀態，線程之間經過寫-讀內存中的公共狀態來隱式進行通訊。

在消息傳遞的併發模型裏，線程之間沒有公共狀態，線程之間必須經過明確的發送消息來顯式進行通訊。

線程同步是指程序用於控制不一樣線程之間操做發生相對順序的機制。

在共享內存的併發模型裏，同步是顯式進行的。程序員必須顯式指定某個方法或某段代碼須要在線程之間互斥執行。

在消息傳遞的併發模型裏，因爲消息的發送必須在消息的接收以前，所以同步是隱式進行的。

Java的併發採用的是共享內存模型，Java線程之間的通訊老是隱式進行，整個通訊過程對程序員徹底透明。若是你想設計表現良好的併發程序，理解Java內存模型是很是重要的。Java內存模型規定了如何和什麼時候能夠看到由其餘線程修改事後的共享變量的值，以及在必須時如何同步的訪問共享變量。

1 爲何要有內存模型

在介紹Java內存模型以前，先來看一下到底什麼是計算機內存模型，而後再來看Java內存模型在計算機內存模型的基礎上作了哪些事情。要說計算機的內存模型，就要說一下一段古老的歷史，看一下爲何要有內存模型。

1.1 CPU和緩存一致性

咱們應該都知道，計算機在執行程序的時候，每條指令都是在CPU中執行的，而執行的時候，又免不了要和數據打交道。而計算機上面的數據，是存放在主存當中的，也就是計算機的物理內存啦。

剛開始，還相安無事的，可是隨着CPU技術的發展，CPU的執行速度愈來愈快。而因爲內存的技術並無太大的變化，因此從內存中讀取和寫入數據的過程和CPU的執行速度比起來差距就會愈來愈大，這就致使CPU每次操做內存都要耗費不少等待時間。

這就像一家創業公司，剛開始，創始人和員工之間工做關係其樂融融，可是隨着創始人的能力和野心愈來愈大，逐漸和員工之間出現了差距，普通員工原來越跟不上CEO的腳步。老闆的每個命令，傳到到基層員工以後，因爲基層員工的理解能力、執行能力的欠缺，就會耗費不少時間。這也就無形中拖慢了整家公司的工做效率。

但是，不能由於內存的讀寫速度慢，就不發展CPU技術了吧，總不能讓內存成爲計算機處理的瓶頸吧。

因此，人們想出來了一個好的辦法，就是在CPU和內存之間增長高速緩存。緩存的概念你們都知道，就是保存一份數據拷貝。它的特色是速度快，內存小，而且昂貴。

那麼，程序的執行過程就變成了：當程序在運行過程當中，會將運算須要的數據從主存複製一份到CPU的高速緩存當中，那麼CPU進行計算時就能夠直接從它的高速緩存讀取數據和向其中寫入數據，當運算結束以後，再將高速緩存中的數據刷新到主存當中。

以後，這家公司開始設立中層管理人員，管理人員直接歸CEO領導，領導有什麼指示，直接告訴管理人員，而後就能夠去作本身的事情了。管理人員負責去協調底層員工的工做。由於管理人員是瞭解手下的人員以及本身負責的事情的。因此，大多數時候，公司的各類決策，通知等，CEO只要和管理人員之間溝通就夠了。

而隨着CPU能力的不斷提高，一層緩存就慢慢的沒法知足要求了，就逐漸的衍生出多級緩存。

按照數據讀取順序和與CPU結合的緊密程度，CPU緩存能夠分爲一級緩存（L1），二級緩存（L3），部分高端CPU還具備三級緩存（L3），每一級緩存中所儲存的所有數據都是下一級緩存的一部分。這三種緩存的 技術難度和制形成本是相對遞減的，因此其容量也是相對遞增的。

那麼，在有了多級緩存以後，程序的執行就變成了：當CPU要讀取一個數據時，首先從一級緩存中查找，若是沒有找到再從二級緩存中查找，若是仍是沒有就從三級緩存或內存中查找。

隨着公司愈來愈大，老闆要管的事情愈來愈多，公司的管理部門開始改革，開始出現高層，中層，底層等管理者。一級一級之間逐層管理。

單核CPU只含有一套L1，L2，L3緩存。若是CPU含有多個核心，即多核CPU，則每一個核心都含有一套L1（甚至和L2）緩存，而共享L3（或者和L2）緩存。

公司也分不少種，有些公司只有一個大Boss，他一我的說了算。可是有些公司有好比聯席總經理、合夥人等機制。

單核CPU就像一家公司只有一個老闆，全部命令都來自於他，那麼就只須要一套管理班底就夠了。

多核CPU就像一家公司是由多個合夥人共同創辦的，那麼，就須要給每一個合夥人都設立一套供本身直接領導的高層管理人員，多個合夥人共享使用的是公司的底層員工。

還有的公司，不斷壯大，開始差分出各個子公司。各個子公司就是多個CPU了，互相以前沒有共用的資源。互不影響。

隨着計算機能力不斷提高，開始支持多線程。那麼問題就來了。咱們分別來分析下單線程、多線程在單核CPU、多核CPU中的影響。

單線程：CPU核心的緩存只被一個線程訪問。緩存獨佔，不會出現訪問衝突等問題。

單核CPU，多線程：進程中的多個線程會同時訪問進程中的共享數據，CPU將某塊內存加載到緩存後，不一樣線程在訪問相同的物理地址的時候，都會映射到相同的緩存位置，這樣即便發生線程的切換，緩存仍然不會失效。但因爲任什麼時候刻只能有一個線程在執行，所以不會出現緩存訪問衝突。

多核CPU，多線程：每一個核都至少有一個L1 緩存。多個線程訪問進程中的某個共享內存，且這多個線程分別在不一樣的核心上執行，則每一個核心都會在各自的caehe中保留一份共享內存的緩衝。因爲多核是能夠並行的，可能會出現多個線程同時寫各自的緩存的狀況，而各自的cache之間的數據就有可能不一樣。

在CPU和主存之間增長緩存，在多線程場景下就可能存在緩存一致性問題，也就是說，在多核CPU中，每一個核的本身的緩存中，關於同一個數據的緩存內容可能不一致。

若是這家公司的命令都是串行下發的話，那麼就沒有任何問題。

若是這家公司的命令都是並行下發的話，而且這些命令都是由同一個CEO下發的，這種機制是也沒有什麼問題。由於他的命令執行者只有一套管理體系。

若是這家公司的命令都是並行下發的話，而且這些命令是由多個合夥人下發的，這就有問題了。由於每一個合夥人只會把命令下達給本身直屬的管理人員，而多個管理人員管理的底層員工多是公用的。

好比，合夥人1要辭退員工a，合夥人2要給員工a升職，升職後的話他再被辭退須要多個合夥人開會決議。兩個合夥人分別把命令下發給了本身的管理人員。合夥人1命令下達後，管理人員a在辭退了員工後，他就知道這個員工被開除了。而合夥人2的管理人員2這時候在沒獲得消息以前，還認爲員工a是在職的，他就欣然的接收了合夥人給他的升職a的命令。

1.2 處理器優化和指令重排

上面提到在CPU和主存之間增長緩存，在多線程場景下會存在緩存一致性問題。除了這種狀況，還有一種硬件問題也比較重要。那就是爲了使處理器內部的運算單元可以儘可能的被充分利用，處理器可能會對輸入代碼進行亂序執行處理。這就是處理器優化。

除了如今不少流行的處理器會對代碼進行優化亂序處理，不少編程語言的編譯器也會有相似的優化，好比：Java虛擬機的即時編譯器（JIT）也會作指令重排。

可想而知，若是任由處理器優化和編譯器對指令重排的話，就可能致使各類各樣的問題。

關於員工組織調整的狀況，若是容許人事部在接到多個命令後進行隨意拆分亂序執行或者重排的話，那麼對於這個員工以及這家公司的影響是很是大的。

1.3 併發編程的問題

前面說的和硬件有關的概念你可能聽得有點蒙，還不知道他到底和軟件有啥關係。可是關於併發編程的問題你應該有所瞭解，好比：原子性問題，可見性問題和有序性問題。

其實，原子性問題，可見性問題和有序性問題，是人們抽象定義出來的。而這個抽象的底層問題就是前面提到的 緩存一致性問題、處理器優化問題和指令重排問題 等。緩存一致性問題其實就是可見性問題。而處理器優化是能夠致使原子性問題的。指令重排即會致使有序性問題。

原子性 是指在一個操做中就是CPU不能夠在中途暫停而後再調度，既不被中斷操做，要不執行完成，要不就不執行。

可見性 是指當多個線程訪問同一個變量時，一個線程修改了這個變量的值，其餘線程可以當即看獲得修改的值。

有序性 是指程序執行的順序按照代碼的前後順序執行。

2 什麼是內存模型

前面提到的，緩存一致性問題、處理器器優化的指令重排問題是硬件的不斷升級致使的。那麼，有沒有什麼機制能夠很好的解決上面的這些問題呢？

最簡單直接的作法就是廢除處理器和處理器的優化技術、廢除CPU緩存，讓CPU直接和主存交互。可是，這麼作雖然能夠保證多線程下的併發問題。可是，這就有點因噎廢食了。

因此，爲了保證併發編程中能夠知足原子性、可見性及有序性。有一個重要的概念，那就是——內存模型，定義了共享內存系統中多線程程序讀寫操做行爲的規範。

經過這些規則來規範對內存的讀寫操做，從而保證指令執行的正確性。它與處理器有關、與緩存有關、與併發有關、與編譯器也有關。它解決了CPU多級緩存、處理器優化、指令重排等致使的內存訪問問題，保證了併發場景下的一致性、原子性和有序性。

內存模型解決併發問題主要採用兩種方式：限制處理器優化和使用內存屏障。

3 什麼是Java內存模型

前面介紹過了計算機內存模型，這是解決多線程場景下併發問題的一個重要規範。那麼具體的實現是如何的呢，不一樣的編程語言，在實現上可能有所不一樣。

咱們知道，Java程序是須要運行在Java虛擬機上面的，Java內存模型（Java Memory Model ,JMM）就是一種符合內存模型規範的，屏蔽了各類硬件和操做系統的訪問差別的，保證了Java程序在各類平臺下對內存的訪問都能保證效果一致的機制及規範。

Java內存模型規定了 全部的變量都存儲在主內存中，每條線程還有本身的工做內存，線程的工做內存中保存了該線程中用到的變量的主內存副本拷貝，線程對變量的全部操做都必須在工做內存中進行，而不能直接讀寫主內存。不一樣的線程之間也沒法直接訪問對方工做內存中的變量，線程間變量的傳遞均須要本身的工做內存和主存之間進行數據同步進行。

而JMM就做用於工做內存和主存之間數據同步過程。他規定了如何作數據同步以及何時作數據同步。

特別須要注意的是，主內存和工做內存與JVM內存結構中的Java堆、棧、方法區等並非同一個層次的內存劃分，沒法直接類比。

再來總結下，JMM是一種規範，規範了Java虛擬機與計算機內存是如何協同工做的，目的是解決因爲多線程經過共享內存進行通訊時，存在的本地內存數據不一致、編譯器會對代碼指令重排序、處理器會對代碼亂序執行等帶來的問題。目的是保證併發編程場景中的原子性、可見性和有序性。

因此，若是你想設計表現良好的併發程序，理解Java內存模型是很是重要的。Java內存模型規定了如何和什麼時候能夠看到由其餘線程修改事後的共享變量的值，以及在必須時如何同步的訪問共享變量。

3.1 Java內存模型抽象

在Java中，全部實例域、靜態域和數組元素存儲在堆內存中，堆內存在線程之間共享。局部變量（Local variables），方法定義參數（formal method parameters）和異常處理器參數（exception handler parameters） 不會在線程之間共享，它們不會有內存可見性問題，也不受內存模型的影響。

Java線程之間的通訊由Java內存模型（JMM）控制，JMM決定一個線程對共享變量的寫入什麼時候對另外一個線程可見。從抽象的角度來看，JMM定義了線程和主內存之間的抽象關係：

線程之間的共享變量存儲在主內存（main memory）中，每一個線程都有一個私有的本地內存（local memory），本地內存中存儲了該線程以讀/寫共享變量的副本。本地內存是JMM的一個抽象概念，並不真實存在。它涵蓋了緩存，寫緩衝區，寄存器以及其餘的硬件和編譯器優化。

從上圖來看，線程A與線程B之間如要通訊的話，必需要經歷下面2個步驟：

1. 首先，線程A把本地內存A中更新過的共享變量刷新到主內存中去；
2. 而後，線程B到主內存中去讀取線程A以前已更新過的共享變量；

下面經過示意圖來講明這兩個步驟：

如上圖所示，本地內存A和B有主內存中共享變量x的副本。假設初始時，這三個內存中的x值都爲0。線程A在執行時，把更新後的x值（假設值爲1）臨時存放在本身的本地內存A中。當線程A和線程B須要通訊時，線程A首先會把本身本地內存中修改後的x值刷新到主內存中，此時主內存中的x值變爲了1。隨後，線程B到主內存中去讀取線程A更新後的x值，此時線程B的本地內存的x值也變爲了1。

從總體來看，這兩個步驟實質上是線程A在向線程B發送消息，並且這個通訊過程必需要通過主內存。JMM經過控制主內存與每一個線程的本地內存之間的交互，來爲Java程序員提供內存可見性保證。

3.2 重排序

在執行程序時爲了提升性能，編譯器和處理器經常會對指令作重排序。重排序分三種類型：

1. 編譯器優化的重排序。編譯器在不改變單線程程序語義的前提下，能夠從新安排語句的執行順序。
2. 指令級並行的重排序。現代處理器採用了指令級並行技術（Instruction-Level Parallelism， ILP）來將多條指令重疊執行。若是不存在數據依賴性，處理器能夠改變語句對應機器指令的執行順序。
3. 內存系統的重排序。因爲處理器使用緩存和讀/寫緩衝區，這使得加載和存儲操做看上去多是在亂序執行。

從Java源代碼到最終實際執行的指令序列，會分別經歷下面三種重排序：

上述的1屬於編譯器重排序，2和3屬於處理器重排序。這些重排序均可能會致使多線程程序出現內存可見性問題。

對於編譯器，JMM的編譯器重排序規則會禁止特定類型的編譯器重排序（不是全部的編譯器重排序都要禁止）。

對於處理器重排序，JMM的處理器重排序規則會要求Java編譯器在生成指令序列時，插入特定類型的內存屏障（memory barriers，intel稱之爲memory fence）指令，經過內存屏障指令來禁止特定類型的處理器重排序（不是全部的處理器重排序都要禁止）。

JMM屬於語言級的內存模型，它確保在不一樣的編譯器和不一樣的處理器平臺之上，經過禁止特定類型的編譯器重排序和處理器重排序，爲程序員提供一致的內存可見性保證。

3.3 處理器重排序

現代的處理器使用 寫緩衝區 來臨時保存向內存寫入的數據。寫緩衝區能夠保證指令流水線持續運行，它能夠避免因爲處理器停頓下來等待向內存寫入數據而產生的延遲。同時，經過以批處理的方式刷新寫緩衝區，以及合併寫緩衝區中對同一內存地址的屢次寫，能夠減小對內存總線的佔用。雖然寫緩衝區有這麼多好處，但每一個處理器上的寫緩衝區，僅僅對它所在的處理器可見。這個特性會對內存操做的執行順序產生重要的影響：

處理器對內存的讀/寫操做的執行順序，不必定與內存實際發生的讀/寫操做順序一致！

假設處理器A和處理器B按程序的順序並行執行內存訪問，最終卻可能獲得 x = y = 0。具體的緣由以下圖所示：

處理器 A 和 B 同時把共享變量寫入在寫緩衝區中（A一、B1），而後再從內存中讀取另外一個共享變量（A二、B2），最後才把本身寫緩衝區中保存的髒數據刷新到內存中（A三、B3）。當以這種時序執行時，程序就能夠獲得 x = y = 0 的結果。

從內存操做實際發生的順序來看，直處處理器 A 執行 A3 來刷新本身的寫緩存區，寫操做 A1 纔算真正執行了。雖然處理器 A 執行內存操做的順序爲：A1 -> A2，但內存操做實際發生的順序倒是：A2 -> A1。此時，處理器 A 的內存操做順序被重排序了。

這裏的關鍵是，因爲寫緩衝區僅對本身的處理器可見，它會致使處理器執行內存操做的順序可能會與內存實際的操做執行順序不一致。因爲現代的處理器都會使用寫緩衝區，所以現代的處理器都會容許對內存寫-讀操做重排序。

3.4 內存屏障指令

下面是常見處理器容許的重排序類型的列表：

上表單元格中的「N」表示處理器不容許兩個操做重排序，「Y」表示容許重排序。從上表咱們能夠看出：常見的處理器都容許Store-Load重排序；常見的處理器都不容許對存在數據依賴的操做作重排序。sparc-TSO和x86擁有相對較強的處理器內存模型，它們僅容許對寫-讀操做作重排序（由於它們都使用了寫緩衝區）。

爲了保證內存可見性，Java 編譯器在生成指令序列的適當位置會插入內存屏障指令來禁止特定類型的處理器重排序。JMM 把內存屏障指令分爲下列四類：

3.5 happens-before

JSR-133 內存模型使用 happens-before 的概念來闡述操做之間的內存可見性。在 JMM 中，若是一個操做執行的結果須要對另外一個操做可見，那麼這兩個操做之間必需要存在 happens-before 關係。這裏提到的兩個操做既能夠是在一個線程以內，也能夠是在不一樣線程之間。

與程序員密切相關的 happens-before 規則以下：

程序順序規則：一個線程中的每一個操做，happens- before 於該線程中的任意後續操做。

監視器鎖規則：對一個監視器鎖的解鎖，happens- before 於隨後對這個監視器鎖的加鎖。

volatile變量規則：對一個volatile域的寫，happens- before 於任意後續對這個volatile域的讀。

傳遞性規則：若是A happens- before B，且B happens- before C，那麼A happens- before C。

注意，兩個操做之間具備happens-before關係，並不意味着前一個操做必需要在後一個操做以前執行！happens-before僅僅要求前一個操做（執行的結果）對後一個操做可見，且前一個操做按順序排在第二個操做以前（the first is visible to and ordered before the second）。

如上圖所示，一個happens-before規則一般對應於多個編譯器和處理器重排序規則。對於Java程序員來講，happens-before規則簡單易懂，它避免java程序員爲了理解JMM提供的內存可見性保證而去學習複雜的重排序規則以及這些規則的具體實現。

3.6 數據依賴性

若是兩個操做訪問同一個變量，且這兩個操做中有一個爲寫操做，此時這兩個操做之間就存在數據依賴性。數據依賴分下列三種類型：

上面三種狀況，只要重排序兩個操做的執行順序，程序的執行結果將會被改變。

前面提到過，編譯器和處理器可能會對操做作重排序。編譯器和處理器在重排序時，會遵照數據依賴性，編譯器和處理器不會改變存在數據依賴關係的兩個操做的執行順序。

注意，這裏所說的數據依賴性僅針對單個處理器中執行的指令序列和單個線程中執行的操做，不一樣處理器之間和不一樣線程之間的數據依賴性不被編譯器和處理器考慮。

3.7 as-if-serial 語義

as-if-serial 語義的意思指：無論怎麼重排序（編譯器和處理器爲了提升並行度），（單線程）程序的執行結果不能被改變。編譯器，runtime 和處理器都必須遵照 as-if-serial 語義。

爲了遵照 as-if-serial 編譯器和處理器不會對存在數據依賴關係的操做作重排序，由於這種重排序會改變執行結果。可是若是操做之間沒有數據依賴關係，這些操做就可能被編譯器和處理器重排序。

舉個例子：

double pi = 3.14; // A

double r = 1.0; // B

double area = pi * r * r; // C
複製代碼

上面三個操做的數據依賴關係以下圖所示：

如上圖所示，A 和 C 之間存在數據依賴關係，同時 B 和 C 之間也存在數據依賴關係。所以在最終執行的指令序列中，C 不能被重排序到 A 和 B 的前面（C 排到 A 和 B 的前面，程序的結果將會被改變）。但 A 和 B 之間沒有數據依賴關係，編譯器和處理器能夠重排序 A 和 B 之間的執行順序。下圖是該程序的兩種可能執行順序：

在計算機中，軟件技術和硬件技術有一個共同的目標：在不改變程序執行結果的前提下，儘量的開發並行度。編譯器和處理器聽從這一目標，從 happens-before 的定義咱們能夠看出，JMM 一樣聽從這一目標。

4 Java內存模型實現

瞭解Java多線程的朋友都知道，在Java中提供了一系列和併發處理相關的關鍵字，好比：volatile、synchronized、final、concurrent 包等。其實這些就是 Java內存模型封裝了底層的實現後提供給程序員使用的一些關鍵字。

在開發多線程的代碼的時候，咱們能夠直接使用 synchronized 等關鍵字來控制併發，歷來就不須要關心底層的編譯器優化、緩存一致性等問題。因此，Java內存模型，除了定義了一套規範，還提供了一系列原語，封裝了底層實現後，供開發者直接使用。

4.1 原子性

在Java中，爲了保證原子性，提供了兩個高級的字節碼指令 monitorenter 和 monitorexit，這兩個字節碼，在Java中對應的關鍵字就是 synchronized。

所以，在Java中可使用 synchronized 來保證方法和代碼塊內的操做是原子性的。

4.2 可見性

Java內存模型是經過在變量修改後將新值同步回主內存，在變量讀取前從主內存刷新變量值的這種依賴主內存做爲傳遞媒介的方式來實現的。

Java中的 volatile 關鍵字提供了一個功能，那就是被其修飾的變量在被修改後能夠當即同步到主內存，被其修飾的變量在每次是用以前都從主內存刷新。所以，可使用 volatile 來保證多線程操做時變量的可見性。

除了 volatile，Java中的 synchronized 和 final 兩個關鍵字也能夠實現可見性。只不過實現方式不一樣，這裏再也不展開了。

4.3 有序性

在Java中，可使用 synchronized 和 volatile 來保證多線程之間操做的有序性。實現方式有所區別：

volatile關鍵字會禁止指令重排；

synchronized關鍵字保證同一時刻只容許一條線程操做；