前幾天，發了一篇文章，介紹了一下JVM內存結構、Java內存模型以及Java對象模型之間的區別。有很多小伙伴反饋希望可以深入的講解下每個知識點。Java內存模型，是這三個知識點當中最晦澀難懂的一個，而且涉及到很多背景知識和相關知識。

網上有很多關于Java內存模型的文章，在《深入理解Java虛擬機》和《Java并發編程的藝術》等書中也都有關于這個知識點的介紹。但是，很多人讀完之后還是搞不清楚，甚至有的人說自己更懵了。本文，就來整體的介紹一下Java內存模型，目的很簡單，讓你讀完本文以后，就知道到底Java內存模型是什么，為什么要有Java內存模型，Java內存模型解決了什么問題等。

本文中，有很多定義和說法，都是筆者自己理解后定義出來的。希望能夠讓讀者可以對Java內存模型有更加清晰的認識。當然，如有偏頗，歡迎指正。

[[234983]]

為什么要有內存模型

在介紹Java內存模型之前，先來看一下到底什么是計算機內存模型，然后再來看Java內存模型在計算機內存模型的基礎上做了哪些事情。要說計算機的內存模型，就要說一下一段古老的歷史，看一下為什么要有內存模型。

內存模型，英文名Memory Model，他是一個很老的老古董了。他是與計算機硬件有關的一個概念。那么我先給你介紹下他和硬件到底有啥關系。

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將某塊內存加載到緩存后，不同線程在訪問相同的物理地址的時候，都會映射到相同的緩存位置，這樣即使發生線程的切換，緩存仍然不會失效。但由于任何時刻只能有一個線程在執行，因此不會出現緩存訪問沖突。

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

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

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

如果這家公司的命令都是并行下發的話，并且這些命令都是由同一個CEO下發的，這種機制是也沒有什么問題。因為他的命令執行者只有一套管理體系。

如果這家公司的命令都是并行下發的話，并且這些命令是由多個合伙人下發的，這就有問題了。因為每個合伙人只會把命令下達給自己直屬的管理人員，而多個管理人員管理的底層員工可能是公用的。

比如，合伙人1要辭退員工a，合伙人2要給員工a升職，升職后的話他再被辭退需要多個合伙人開會決議。兩個合伙人分別把命令下發給了自己的管理人員。合伙人1命令下達后，管理人員a在辭退了員工后，他就知道這個員工被開除了。而合伙人2的管理人員2這時候在沒得到消息之前，還認為員工a是在職的，他就欣然的接收了合伙人給他的升職a的命令。

處理器優化和指令重排

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

除了現在很多流行的處理器會對代碼進行優化亂序處理，很多編程語言的編譯器也會有類似的優化，比如Java虛擬機的即時編譯器（JIT）也會做指令重排。

可想而知，如果任由處理器優化和編譯器對指令重排的話，就可能導致各種各樣的問題。

關于員工組織調整的情況，如果允許人事部在接到多個命令后進行隨意拆分亂序執行或者重排的話，那么對于這個員工以及這家公司的影響是非常大的。

并發編程的問題

前面說的和硬件有關的概念你可能聽得有點蒙，還不知道他到底和軟件有啥關系。但是關于并發編程的問題你應該有所了解，比如原子性問題，可見性問題和有序性問題。

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

這里簡單回顧下這三個問題，并不準備深入展開，感興趣的讀者可以自行學習。我們說，并發編程，為了保證數據的安全，需要滿足以下三個特性：

原子性是指在一個操作中就是cpu不可以在中途暫停然后再調度，既不被中斷操作，要不執行完成，要不就不執行。

可見性是指當多個線程訪問同一個變量時，一個線程修改了這個變量的值，其他線程能夠立即看得到修改的值。

有序性即程序執行的順序按照代碼的先后順序執行。

有沒有發現，緩存一致性問題其實就是可見性問題。而處理器優化是可以導致原子性問題的。指令重排即會導致有序性問題。所以，后文將不再提起硬件層面的那些概念，而是直接使用大家熟悉的原子性、可見性和有序性。

什么是內存模型

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

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

所以，為了保證并發編程中可以滿足原子性、可見性及有序性。有一個重要的概念，那就是——內存模型。

為了保證共享內存的正確性（可見性、有序性、原子性），內存模型定義了共享內存系統中多線程程序讀寫操作行為的規范。通過這些規則來規范對內存的讀寫操作，從而保證指令執行的正確性。它與處理器有關、與緩存有關、與并發有關、與編譯器也有關。他解決了CPU多級緩存、處理器優化、指令重排等導致的內存訪問問題，保證了并發場景下的一致性、原子性和有序性。

內存模型解決并發問題主要采用兩種方式：限制處理器優化和使用內存屏障。本文就不深入底層原理來展開介紹了，感興趣的朋友可以自行學習。

什么是Java內存模型

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

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

提到Java內存模型，一般指的是JDK 5 開始使用的新的內存模型，主要由JSR-133: JavaTM Memory Model and Thread Specification 描述。感興趣的可以參看下這份PDF文檔（http://www.cs.umd.edu/~pugh/java/memoryModel/jsr133.pdf）

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

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

這里面提到的主內存和工作內存，讀者可以簡單的類比成計算機內存模型中的主存和緩存的概念。特別需要注意的是，主內存和工作內存與JVM內存結構中的Java堆、棧、方法區等并不是同一個層次的內存劃分，無法直接類比。《深入理解Java虛擬機》中認為，如果一定要勉強對應起來的話，從變量、主內存、工作內存的定義來看，主內存主要對應于Java堆中的對象實例數據部分。工作內存則對應于虛擬機棧中的部分區域。

所以，再來總結下，JMM是一種規范，目的是解決由于多線程通過共享內存進行通信時，存在的本地內存數據不一致、編譯器會對代碼指令重排序、處理器會對代碼亂序執行等帶來的問題。目的是保證并發編程場景中的原子性、可見性和有序性。

Java內存模型的實現

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

在開發多線程的代碼的時候，我們可以直接使用synchronized等關鍵字來控制并發，從來就不需要關心底層的編譯器優化、緩存一致性等問題。所以，Java內存模型，除了定義了一套規范，還提供了一系列原語，封裝了底層實現后，供開發者直接使用。

本文并不準備把所有的關鍵字逐一介紹其用法，因為關于各個關鍵字的用法，網上有很多資料。讀者可以自行學習。本文還有一個重點要介紹的就是，我們前面提到，并發編程要解決原子性、有序性和一致性的問題，我們就再來看下，在Java中，分別使用什么方式來保證。

原子性

在Java中，為了保證原子性，提供了兩個高級的字節碼指令monitorenter和monitorexit。在synchronized的實現原理文章中，介紹過，這兩個字節碼，在Java中對應的關鍵字就是synchronized。

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

可見性

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

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

除了volatile，Java中的synchronized和final兩個關鍵字也可以實現可見性。只不過實現方式不同，這里不再展開了。

有序性

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

volatile關鍵字會禁止指令重排。synchronized關鍵字保證同一時刻只允許一條線程操作。

好了，這里簡單的介紹完了Java并發編程中解決原子性、可見性以及有序性可以使用的關鍵字。讀者可能發現了，好像synchronized關鍵字是***的，他可以同時滿足以上三種特性，這其實也是很多人濫用synchronized的原因。

但是synchronized是比較影響性能的，雖然編譯器提供了很多鎖優化技術，但是也不建議過度使用。

總結

在讀完本文之后，相信你應該了解了什么是Java內存模型、Java內存模型的作用以及Java中內存模型做了什么事情等。

【本文是51CTO專欄作者Hollis的原創文章，作者微信公眾號Hollis(ID：hollischuang)】

戳這里，看該作者更多好文