華為技術專傢講解JVM內存模型(收藏)
全是幹貨的技術號：
本文已收錄在【github面試知識倉庫】，歡迎 star/fork：
https://github.com/Wasabi1234/Java-Interview-Tutorial
內存是非常重要的系統資源，是硬盤和CPU的中間倉庫及橋梁，承載著操作系統和應用程序的實時運行。
JVM內存佈局規定瞭Java在運行過程中內存申請、分配、管理的策略，保證瞭JVM的高效穩定運行。不同的JVM對於內存的劃分方式和管理機制存在著部分差異。結合JVM虛擬機規范，來探討經典的JVM內存佈局。
JVM運行時數據區
線程獨占
每個線程都會有它獨立的空間，隨線程生命周期而創建和銷毀
線程共享
所有線程能訪問這塊內存數據，隨虛擬機或者GC而創建和銷毀
JDK8的JVM內存模型
1 Program Counter Register (程序計數寄存器)
Register 之名源於CPU的寄存器，CPU隻有把數據裝載到寄存器才能夠運行
寄存器存儲指令相關的現場信息，由於CPU時間片輪限制，眾多線程在並發執行過程中，任何一個確定的時刻，一個處理器或者多核處理器中的一個內核，隻會執行某個線程中的一條指令。這樣必然導致經常中斷或恢復，如何保證分毫無差呢?
每個線程在創建後，都會產生自己的程序計數器和棧幀，程序計數器用來存放執行指令的偏移量和行號指示器等，線程執行或恢復都要依賴程序計數器。程序計數器在各個線程之間互不影響，此區域也不會發生內存溢出異常。
1.1. 定義
這是一塊較小的內存空間，可看作當前線程正在執行的字節碼的行號指示器。如果當前線程正在執行的是：
Java方法
計數器記錄的就是當前線程正在執行的字節碼指令的地址
本地方法
那麼程序計數器值為undefined
1.2. 作用
程序計數器（後文簡稱為 PCR）有兩個作用：
- 字節碼解釋器通過改變PCR依次讀取指令，實現代碼的流程控制，如：順序執行、選擇、循環、異常處理
- 多線程情況下，PCR用於記錄當前線程執行的位置，從而當線程被切換回來的時候能夠知道該線程上次運行到哪瞭
1.3. 特點
一塊較小的內存空間，【線程私有】。每條線程都有一個獨立的程序計數器。
唯一一個不會出現OOM的內存區域。
2. Java虛擬機棧(JVM Stack)
2.1. 定義
。相對於基於寄存器的運行環境，JVM是基於棧結構的運行環境。棧結構移植性更好，可控性更強。
JVM中的虛擬機棧是描述Java方法執行的內存區域，屬【線程私有】。
棧中的元素用於支持虛擬機進行方法調用，每個方法從開始調用到執行完成的過程，就是棧幀從入棧到出棧的過程。
2.2 結構
棧幀是方法運行的基本結構。
- 在活動線程中，隻有位於棧頂的幀才是有效的，稱為
當前棧幀 - 正在執行的方法稱為
當前方法
在執行引擎運行時，所有指令都隻能針對當前棧幀操作，StackOverflowError表示請求的棧溢出，導致內存耗盡，通常出現在遞歸方法。
當前方法的棧幀，都是正在戰鬥的戰場，其中的操作棧是參與戰鬥的士兵
操作棧的壓棧與出棧
虛擬機棧通過壓/出棧，對每個方法對應的活動棧幀進行運算處理，方法正常執行結束，肯定會跳轉到另一個棧幀上。
在執行的過程中，如果出現異常，會進行異常回溯，返回地址通過異常處理表確定。
棧幀在整個JVM體系中的地位頗高，包括：局部變量表、操作棧、動態連接、方法返回地址等。
局部變量表
存放方法參數和局部變量。
相對於類屬性變量的準備階段和初始化階段，局部變量沒有準備階段，必須顯式初始化。
如果是非靜態方法，則在index[0]位置上存儲的是方法所屬對象的實例引用，隨後存儲的是參數和局部變量。
字節碼指令中的STORE指令就是將操作棧中計算完成的局部變量寫回局部變量表的存儲空間內。
操作數棧
一個初始狀態為空的桶式結構棧。由於 Java 沒有寄存器，所有參數傳遞使用操作數棧。在方法執行過程中，會有各種指令往棧中寫入和提取信息。JVM的執行引擎是基於棧的執行引擎，其中的棧指的就是操作棧。
字節碼指令集的定義都是基於棧類型的，棧的深度在方法元信息的stack屬性中。
操作棧與局部變量表交互
詳細的字節碼操作順序如下:
第1處說明:局部變量表就像個中藥櫃，裡面有很多抽屜,依次編號為0, 1, 2,3，.,. n
字節碼指令istore_ 1就是打開1號抽屜，把棧頂中的數13存進去
棧是一個很深的豎桶，任何時候隻能對桶口元素進行操作，所以數據隻能在棧頂進行存取
某些指令可以直接在抽屜裡進行，比如inc指令，直接對抽屜裡的數值進行+1操作
程序員面試過程中，常見的i++和++i的區別，可以從字節碼上對比出來
iload_ 1從局部變量表的第1號抽屜裡取出一個數,壓入棧頂，下一步直接在抽屜裡實現+1的操作，而這個操作對棧頂元素的值沒有影響- 所以istore_ 2隻是把棧頂元素賦值給a
- 表格右列，先在第1號抽屜裡執行+1操作，然後通過iload_ 1 把第1號抽屜裡的數壓入棧頂，所以istore_ 2存入的是+1之後的值
i++並非原子操作。即使通過volatile關鍵字進行修飾，多個線程同時寫的話，也會產生數據互相覆蓋的問題。
動態連接
每個棧幀中包含一個在常量池中對當前方法的引用，目的是支持方法調用過程的動態連接。
方法返回地址
方法執行時有兩種退出情況：
正常退出
正常執行到任何方法的返回字節碼指令，如RETURN、IRETURN、ARETURN等。
異常退出
無論何種，都將返回至方法當前被調用的位置。方法退出的過程相當於彈出當前棧幀。
退出可能有三種方式:
- 返回值壓入，上層調用棧幀
- 異常信息拋給能夠處理的棧幀
- PC計數器指向方法調用後的下一條指令
Java虛擬機棧是描述Java方法運行過程的內存模型。Java虛擬機棧會為每一個即將運行的Java方法創建“棧幀”。用於存儲該方法在運行過程中所需要的一些信息。
- 局部變量表
- 存放基本數據類型變量、引用類型的變量、returnAddress類型的變量
- 操作數棧
- 動態鏈接
- 當前方法的常量池指針
- 當前方法的返回地址
- 方法出口等信息
每一個方法從被調用到執行完成的過程,都對應著一個個棧幀在JVM棧中的入棧和出棧過程
註意：人們常說，Java的內存空間分為“棧”和“堆”，棧中存放局部變量，堆中存放對象。
這句話不完全正確！這裡的“堆”可以這麼理解，但這裡的“棧”就是現在講的虛擬機棧,或者說Java虛擬機棧中的局部變量表部分.
真正的Java虛擬機棧是由一個個棧幀組成，而每個棧幀中都擁有：局部變量表、操作數棧、動態鏈接、方法出口信息.
特點
局部變量表的創建是在方法被執行的時候，隨棧幀創建而創建。
表的大小在編譯期就確定，在創建的時候隻需分配事先規定好的大小即可。在方法運行過程中，表的大小不會改變。Java虛擬機棧會出現兩種異常：
StackOverFlowError
若Java虛擬機棧的內存大小不允許動態擴展,那麼當線程請求的棧深度大於虛擬機允許的最大深度時(但內存空間可能還有很多),就拋出此異常
棧內存默認最大是1M,超出則拋出StackOverflowError
OutOfMemoryError
若Java虛擬機棧的內存大小允許動態擴展,且當線程請求棧時內存用完瞭,無法再動態擴展瞭,此時拋出OutOfMemoryError異常
Java虛擬機棧也是線程私有的，每個線程都有各自的Java虛擬機棧，而且隨著線程的創建而創建，隨線程的死亡而死亡。
3. 本地方法棧(Native Method Stack)
和虛擬機棧功能類似，虛擬機棧是為虛擬機執行JAVA方法而準備的
虛擬機規范沒有規定具體的實現，由不同的虛擬機廠商去實現。
HotSpot虛擬機中虛擬機棧和本地方法棧的實現式一樣的。同樣，超出大小以後
也會拋出StackOverflowError.
本地方法棧和Java虛擬機棧實現的功能與拋出異常幾乎相同
隻不過虛擬機棧是為虛擬機執行Java方法(也就是字節碼)服務,本地方法區則為虛擬機使用到的Native方法服務.
在JVM內存佈局中，也是線程對象私有的,但是虛擬機棧“主內”，而本地方法棧“主外”
這個“內外”是針對JVM來說的，本地方法棧為Native方法服務
線程開始調用本地方法時，會進入一個不再受JVM約束的世界
本地方法可以通過JNI(Java Native Interface)來訪問虛擬機運行時的數據區，甚至可以調用寄存器,具有和JVM相同的能力和權限
當大量本地方法出現時,勢必會削弱JVM對系統的控制力,因為它的出錯信息都比較黑盒.
對於內存不足的情況，本地方法棧還是會拋出native heap OutOfMemory
最著名的本地方法應該是System.currentTimeMillis()，JNI 使Java深度使用OS的特性功能，復用非Java代碼
但是在項目過程中，如果大量使用其他語言來實現JNI,就會喪失跨平臺特性，威脅到程序運行的穩定性
假如需要與本地代碼交互，就可以用中間標準框架進行解耦，這樣即使本地方法崩潰也不至於影響到JVM的穩定
當然，如果要求極高的執行效率、偏底層的跨進程操作等，可以考慮設計為JNI調用方式
4 Java堆(Java Heap)
JVM啟動時創建，存放對象的實例。垃圾回收器主要就是管理堆內存。
Heap是OOM故障最主要的發源地，它存儲著幾乎所有的實例對象，堆由垃圾收集器自動回收，堆區由各子線程共享使用
通常情況下，它占用的空間是所有內存區域中最大的，但如果無節制地創建大量對象，也容易消耗完所有的空間
堆的內存空間既可以固定大小，也可運行時動態地調整，通過如下參數設定初始值和最大值，比如
-Xms256M. -Xmx1024M
其中-X表示它是JVM運行參數
- ms是memorystart的簡稱 最小堆容量
- mx是memory max的簡稱 最大堆容量
但是在通常情況下，服務器在運行過程中，堆空間不斷地擴容與回縮，勢必形成不必要的系統壓力，所以在線上生產環境中，JVM的Xms和Xmx設置成一樣大小，避免在GC後調整堆大小時帶來的額外壓力
堆分成兩大塊:新生代和老年代
對象產生之初在新生代，步入暮年時進入老年代，但是老年代也接納在新生代無法容納的超大對象
新生代= 1個Eden區+ 2個Survivor區
絕大部分對象在Eden區生成，當Eden區裝填滿的時候，會觸發Young GC。垃圾回收的時候，在Eden區實現清除策略，沒有被引用的對象則直接回收。依然存活的對象會被移送到Survivor區，這個區真是名副其實的存在
Survivor 區分為S0和S1兩塊內存空間，送到哪塊空間呢?每次Young GC的時候，將存活的對象復制到未使用的那塊空間，然後將當前正在使用的空間完全清除，交換兩塊空間的使用狀態
如果YGC要移送的對象大於Survivor區容量上限，則直接移交給老年代
假如一些沒有進取心的對象以為可以一直在新生代的Survivor區交換來交換去，那就錯瞭。每個對象都有一個計數器，每次YGC都會加1。
-XX:MaxTenuringThreshold
參數能配置計數器的值到達某個閾值的時候，對象從新生代晉升至老年代。如果該參數配置為1,那麼從新生代的Eden區直接移至老年代。默認值是15，可以在Survivor 區交換14次之後，晉升至老年代
若Survivor區無法放下，或者超大對象的閾值超過上限，則嘗試在老年代中進行分配;
如果老年代也無法放下，則會觸發Full Garbage Collection(Full GC);
如果依然無法放下，則拋OOM.
堆出現OOM的概率是所有內存耗盡異常中最高的
出錯時的堆內信息對解決問題非常有幫助，所以給JVM設置運行參數-
XX:+HeapDumpOnOutOfMemoryError
讓JVM遇到OOM異常時能輸出堆內信息
在不同的JVM實現及不同的回收機制中，堆內存的劃分方式是不一樣的
存放所有的類實例及數組對象
除瞭實例數據，還保存瞭對象的其他信息，如Mark Word（存儲對象哈希碼，GC標志，GC年齡，同步鎖等信息），Klass Pointy(指向存儲類型元數據的指針）及一些字節對齊補白的填充數據（若實例數據剛好滿足8字節對齊，則可不存在補白）
特點
Java虛擬機所需要管理的內存中最大的一塊.
堆內存物理上不一定要連續,隻需要邏輯上連續即可,就像磁盤空間一樣.
堆是垃圾回收的主要區域,所以也被稱為GC堆.
堆的大小既可以固定也可以擴展,但主流的虛擬機堆的大小是可擴展的(通過-Xmx和-Xms控制),因此當線程請求分配內存,但堆已滿,且內存已滿無法再擴展時,就拋出OutOfMemoryError.
線程共享
整個Java虛擬機隻有一個堆,所有的線程都訪問同一個堆.
它是被所有線程共享的一塊內存區域,在虛擬機啟動時創建.
而程序計數器、Java虛擬機棧、本地方法棧都是一個線程對應一個
5 方法區
5.1 定義
Java虛擬機規范中定義方法區是堆的一個邏輯區劃部分,具體實現根據不同虛擬機來實現,如: HotSpot在Java7中方法區放在永久代，Java8放在元數據空間，並且通過GC機制對這個區域進行管理。
別名Non-Heap(非堆)，以與Java堆區分。方法區中存放已經被虛擬機加載的：
- 類信息
- 常量
- 常量存儲在【運行時常量池】
- 靜態變量
- 即時編譯器(JIT)編譯後的代碼等數據
5.2 特點
線程共享
方法區是堆的一個邏輯部分,因此和堆一樣,都是線程共享的.整個虛擬機中隻有一個方法區.
永久代
方法區中的信息一般需要長期存在，而且它又是堆的邏輯分區，因此用堆的劃分方法，我們把方法區稱為永久代.
內存回收效率低
Java虛擬機規范對方法區的要求比較寬松,可以不實現垃圾收集.
方法區中的信息一般需要長期存在,回收一遍內存之後可能隻有少量信息無效.
對方法區的內存回收的主要目標是:對常量池的回收和對類型的卸載
和堆一樣，允許固定大小，也允許可擴展的大小，還允許不實現垃圾回收。
當方法區內存空間無法滿足內存分配需求時,將拋出OutOfMemoryError異常.
5.3 運行時常量池(Runtime Constant Pool)
5.3.1 定義
方法區的一部分。
.java文件被編譯之後生成的.class文件中除瞭包含：類的版本、字段、方法、接口等描述信息外，還有一項就是常量池。
常量池中存放編譯時期產生的各種字面量和符號引用，.class文件中的常量池中的所有的內容在類被加載後存放到方法區的運行時常量池中。
// age 是一個變量，可被賦值 // 21 是一個字面值常量，不能被賦值 PS：int age = 21; // pai 是一個符號常量，一旦被賦值之後就不能被修改 int final pai = 3.14;
JDK6、7、8三個版本中， 運行時常量池的所處區域一直在不斷的變化：
- 6時，是方法區的一部分
- 7時，又放到堆內存
- 8時，出現瞭元空間，又回到瞭方法區
這也說明瞭官方對“永久代”的優化從7就已經開始瞭。
5.3.2 特性
運行時常量池相對於class文件常量池的另外一個特性是具備動態性，Java語言並不要求常量一定隻有編譯器才產生，也就是並非預置入class文件中常量池的內容才能進入方法區運行時常量池，運行期間也可能將新的常量放入池中。
String類的intern()方法就是采用瞭運行時常量池的動態性。當調用 intern 方法時，看池中已包含一個等於此 String 對象的字符串：
是
則返回池中的字符串
否
將此 String 對象添加到池中，並返回此 String 對象的引用
5.3.3 可能拋出的異常
運行時常量池是方法區的一部分,所以會受到方法區內存的限制,因此當常量池無法再申請到內存時就會拋出OutOfMemoryError異常.
我們一般在一個類中通過public static final來聲明一個常量。這個類被編譯後便生成Class文件，這個類的所有信息都存儲在這個class文件中。
當這個類被Java虛擬機加載後，class文件中的常量就存放在方法區的運行時常量池中。而且在運行期間，可以向常量池中添加新的常量。如：String類的intern()方法就能在運行期間向常量池中添加字符串常量。
當運行時常量池中的某些常量沒有被對象引用，同時也沒有被變量引用，那麼就需要垃圾收集器回收。
6 直接內存(Direct Memory)
直接內存不是虛擬機運行時數據區的一部分,也不是JVM規范中定義的內存區域,但在JVM的實際運行過程中會頻繁地使用這塊區域.而且也會拋OOM
在JDK 1.4中加入瞭NIO(New Input／Output)類,引入瞭一種基於管道和緩沖區的IO方式,它可以使用Native函數庫直接分配堆外內存,然後通過一個存儲在堆裡的DirectByteBuffer對象作為這塊內存的引用來操作堆外內存中的數據.
這樣能在一些場景中顯著提升性能,因為避免瞭在Java堆和Native堆中來回復制數據.
綜上看來
程序計數器、Java虛擬機棧、本地方法棧是線程私有的，即每個線程都擁有各自的程序計數器、Java虛擬機棧、本地方法區。並且他們的生命周期和所屬的線程一樣。
而堆、方法區是線程共享的，在Java虛擬機中隻有一個堆、一個方法棧。並在JVM啟動的時候就創建，JVM停止才銷毀。
7 Metaspace (元空間)
到瞭JDK8，元空間的前身Perm區（永久代）被淘汰，在JDK7及之前的版本中，隻有Hotspot才有Perm區，它在啟動時固定大小，很難進行調優，並且Full GC時會移動類元信息。
在某些場景下，若動態加載類過多，容易產生Perm區的OOM。比如某工程因為功能點較多，運行過程中，要不斷動態加載很多類，經常出現錯誤：
Exception in thread ‘dubbo client x.x connector’
java.lang.OutOfMemoryError: PermGenspac
為解決該問題，需要設定運行參數
-XX:MaxPermSize= l280m
如果部署到新機器上，往往會因為JVM參數沒有修改導致故障再現。不熟悉此應用的人排查問題時都苦不堪言。此外，永久代在GC過程中還存在諸多問題。
所以，JDK8使用元空間替換永久代。區別於永久代，元空間在本地內存中分配。即，
隻要本地內存足夠，它不會出現類似永久代的java.lang.OutOfMemoryError: PermGen space
對永久代的設置參數 PermSize 和MaxPermSize也會失效。在JDK8及以上版本，設定MaxPermSize參數，JVM在啟動時並不會報錯，但會提示:
Java HotSpot 64Bit Server VM warning:ignoring option MaxPermSize=2560m; support was removed in 8.0
默認情況下，“元空間”的大小可以動態調整，或者使用新參數MaxMetaspaceSize來限制本地內存分配給類元數據的大小。
在JDK8裡，Perm 區所有內容中
- 字符串常量移至堆內存
- 其他內容包括類元信息、字段、靜態屬性、方法、常量等都移動至元空間
比如上圖中的Object類元信息、靜態屬性System.out、整型常量000000等
圖中顯示在常量池中的String，其實際對象是被保存在堆內存中的。
元空間特色
- 充分利用瞭Java語言規范：類及相關的元數據的生命周期與類加載器的一致
- 每個類加載器都有它的內存區域-元空間
- 隻進行線性分配
- 不會單獨回收某個類（除瞭重定義類 RedefineClasses 或類加載失敗）
- 沒有GC掃描或壓縮
- 元空間裡的對象不會被轉移
- 如果GC發現某個類加載器不再存活，會對整個元空間進行集體回收
GC
- Full GC時，指向元數據指針都不用再掃描，減少瞭Full GC的時間
- 很多復雜的元數據掃描的代碼（尤其是CMS裡面的那些）都刪除瞭
- 元空間隻有少量的指針指向Java堆
- 這包括：類的元數據中指向java.lang.Class實例的指針;數組類的元數據中，指向java.lang.Class集合的指針。
- 沒有元數據壓縮的開銷
- 減少瞭GC Root的掃描（不在掃描虛擬機裡面的已加載類的目錄和其它的內部哈希表）
- G1中，並發標記階段完成後就可以進行類的卸載
元空間內存分配模型
- 絕大多數的類元數據的空間都在本地內存中分配
- 用來描述類元數據的對象也被移除
- 為元數據分配瞭多個映射的虛擬內存空間
- 為每個類加載器分配一個內存塊列表
塊的大小取決於類加載器的類型
Java反射的字節碼存取器（sun.reflect.DelegatingClassLoader ）占用內存更小
- 空閑塊內存返還給塊內存列表
- 當元空間為空，虛擬內存空間會被回收
- 減少瞭內存碎片
最後,從線程共享的角度來看
- 堆和元空間是所有線程共享的
- 虛擬機棧、本地方法棧、程序計數器是線程內部私有的
從這個角度看一下Java內存結構
8 從GC角度看Java堆
堆和方法區都是線程共享的區域，主要用來存放對象的相關信息。一個接口中的多個實現類需要的內存可能不一樣，一個方法中的多個分支需要的內存也可能不一樣，我們隻有在程序運行期間才能知道會創建哪些對象，因此， 這部分的內存和回收都是動態的，垃圾收集器所關註的就是這部分內存（本節後續所說的“內存”分配與回收也僅指這部分內存）。而在JDK1.7和1.8對這部分內存的分配也有所不同：
Java8中堆內存分配如下圖：
9 JVM關閉
- 正常關閉：當最後一個非守護線程結束或調用瞭System.exit或通過其他特定於平臺的方式,比如ctrl+c。
- 強制關閉：調用Runtime.halt方法，或在操作系統中直接kill（發送single信號）掉JVM進程。
- 異常關閉：運行中遇到RuntimeException 異常等
在某些情況下，我們需要在JVM關閉時做一些掃尾的工作，比如刪除臨時文件、停止日志服務。為此JVM提供瞭關閉鉤子（shutdown hocks）來做這些事件。
Runtime類封裝java應用運行時的環境，每個java應用程序都有一個Runtime類實例，使用程序能與其運行環境相連。
關閉鉤子本質上是一個線程（也稱為hock線程），可以通過Runtime的addshutdownhock （Thread hock）向主jvm註冊一個關閉鉤子。hock線程在jvm正常關閉時執行，強制關閉不執行。
對於在jvm中註冊的多個關閉鉤子，他們會並發執行，jvm並不能保證他們的執行順序。
參考
《碼出高效》
到此這篇關於華為技術專傢講解JVM內存模型(收藏)的文章就介紹到這瞭,更多相關JVM內存模型內容請搜索WalkonNet以前的文章或繼續瀏覽下面的相關文章希望大傢以後多多支持WalkonNet！