JVM記憶體結構、Java記憶體模型以及Java物件模型之間的區別
Java作為一種面向物件的，跨平臺語言，其物件、記憶體等一直是比較難的知識點。而且很多概念的名稱看起來又那麼相似，很多人會傻傻分不清楚。比如本文我們要討論的JVM記憶體結構、Java記憶體模型和Java物件模型，這就是三個截然不同的概念，但是很多人容易弄混。
可以這樣說，很多高階開發甚至都搞不不清楚JVM記憶體結構、Java記憶體模型和Java物件模型這三者的概念及其間的區別。甚至我見過有些面試官自己也搞的不是太清楚。不信的話，你去網上搜索Java記憶體模型，還會有很多文章的內容其實介紹的是JVM記憶體結構。
首先，這三個概念是完全不同的三個概念。本文主要對這三個概念加以區分以及簡單介紹。其中每一個知識點都可以單獨寫一篇文章，本文並不會深入介紹，感興趣的朋友可以加入我的知識星球和球友們共同學習。
JVM記憶體結構
我們都知道，Java程式碼是要執行在虛擬機器上的，而虛擬機器在執行Java程式的過程中會把所管理的記憶體劃分為若干個不同的資料區域，這些區域都有各自的用途。其中有些區域隨著虛擬機器程序的啟動而存在，而有些區域則依賴使用者執行緒的啟動和結束而建立和銷燬。在《Java虛擬機器規範（Java SE 8）》中描述了JVM執行時記憶體區域結構如下：
各個區域的功能不是本文重點，就不在這裡詳細介紹了。這裡簡單提幾個需要特別注意的點：
1、以上是Java虛擬機器規範，不同的虛擬機器實現會各有不同，但是一般會遵守規範。
2、規範中定義的方法區，只是一種概念上的區域，並說明了其應該具有什麼功能。但是並沒有規定這個區域到底應該處於何處。所以，對於不同的虛擬機器實現來說，是由一定的自由度的。
3、不同版本的方法區所處位置不同，上圖中劃分的是邏輯區域，並不是絕對意義上的物理區域。因為某些版本的JDK中方法區其實是在堆中實現的。
4、執行時常量池用於存放編譯期生成的各種字面量和符號應用。但是，Java語言並不要求常量只有在編譯期才能產生。比如在執行期，String.intern也會把新的常量放入池中。
5、除了以上介紹的JVM執行時記憶體外，還有一塊記憶體區域可供使用，那就是直接記憶體。Java虛擬機器規範並沒有定義這塊記憶體區域，所以他並不由JVM管理，是利用本地方法庫直接在堆外申請的記憶體區域。
6、堆和棧的資料劃分也不是絕對的，如HotSpot的JIT會針對物件分配做相應的優化。
如上，做個總結，JVM記憶體結構，由Java虛擬機器規範定義。描述的是Java程式執行過程中，由JVM管理的不同資料區域。各個區域有其特定的功能。
Java記憶體模型
Java記憶體模型看上去和Java記憶體結構（JVM記憶體結構）差不多，很多人會誤以為兩者是一回事兒，這也就導致面試過程中經常答非所為。
在前面的關於JVM的記憶體結構的圖中，我們可以看到，其中Java堆和方法區的區域是多個執行緒共享的資料區域。也就是說，多個執行緒可能可以操作儲存在堆或者方法區中的同一個資料。這也就是我們常說的“Java的執行緒間通過共享記憶體進行通訊”。
Java記憶體模型是根據英文Java Memory Model（JMM）翻譯過來的。其實JMM並不像JVM記憶體結構一樣是真實存在的。他只是一個抽象的概念。JSR-133: Java Memory Model and Thread Specification中描述了，JMM是和多執行緒相關的，他描述了一組規則或規範，這個規範定義了一個執行緒對共享變數的寫入時對另一個執行緒是可見的。
那麼，簡單總結下，Java的多執行緒之間是通過共享記憶體進行通訊的，而由於採用共享記憶體進行通訊，在通訊過程中會存在一系列如可見性、原子性、順序性等問題，而JMM就是圍繞著多執行緒通訊以及與其相關的一系列特性而建立的模型。JMM定義了一些語法集，這些語法集對映到Java語言中就是volatile、synchronized等關鍵字。
在Java中，JMM是一個非常重要的概念，正是由於有了JMM，Java的併發程式設計才能避免很多問題。這裡就不對Java記憶體模型做更加詳細的介紹了，想了解更多的朋友可以參考《Java併發程式設計的藝術》。
Java物件模型
Java是一種面向物件的語言，而Java物件在JVM中的儲存也是有一定的結構的。而這個關於Java物件自身的儲存模型稱之為Java物件模型。
HotSpot虛擬機器中，設計了一個OOP-Klass Model。OOP（Ordinary Object Pointer）指的是普通物件指標，而Klass用來描述物件例項的具體型別。
每一個Java類，在被JVM載入的時候，JVM會給這個類建立一個instanceKlass，儲存在方法區，用來在JVM層表示該Java類。當我們在Java程式碼中，使用new建立一個物件的時候，JVM會建立一個instanceOopDesc物件，這個物件中包含了物件頭以及例項資料。
這就是一個簡單的Java物件的OOP-Klass模型，即Java物件模型。
總結
我們再來區分下JVM記憶體結構、 Java記憶體模型 以及 Java物件模型 三個概念。
JVM記憶體結構，和Java虛擬機器的執行時區域有關。 Java記憶體模型，和Java的併發程式設計有關。 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中記憶體模型做了什麼事情等。關於Java中這些和記憶體模型有關的關鍵字，希望讀者還可以繼續深入學習，並且自己寫幾個例子親自體會一下。
可以參考《深入理解Java虛擬機器》和《Java併發程式設計的藝術》兩本書。