全是干貨的技術(shù)號：
本文已收錄在【github面試知識倉庫】，歡迎 star/fork：
https://github.com/Wasabi1234/Java-Interview-Tutorial

內(nèi)存是非常重要的系統(tǒng)資源，是硬盤和CPU的中間倉庫及橋梁，承載著操作系統(tǒng)和應(yīng)用程序的實(shí)時運(yùn)行。
JVM內(nèi)存布局規(guī)定了Java在運(yùn)行過程中內(nèi)存申請、分配、管理的策略，保證了JVM的高效穩(wěn)定運(yùn)行。不同的JVM對于內(nèi)存的劃分方式和管理機(jī)制存在著部分差異。結(jié)合JVM虛擬機(jī)規(guī)范，來探討經(jīng)典的JVM內(nèi)存布局。

JVM運(yùn)行時數(shù)據(jù)區(qū)

線程獨(dú)占

每個線程都會有它獨(dú)立的空間，隨線程生命周期而創(chuàng)建和銷毀

線程共享
所有線程能訪問這塊內(nèi)存數(shù)據(jù)，隨虛擬機(jī)或者GC而創(chuàng)建和銷毀

JDK8的JVM內(nèi)存模型

1 Program Counter Register (程序計數(shù)寄存器)

Register 之名源于CPU的寄存器，CPU只有把數(shù)據(jù)裝載到寄存器才能夠運(yùn)行
寄存器存儲指令相關(guān)的現(xiàn)場信息，由于CPU時間片輪限制，眾多線程在并發(fā)執(zhí)行過程中，任何一個確定的時刻，一個處理器或者多核處理器中的一個內(nèi)核，只會執(zhí)行某個線程中的一條指令。這樣必然導(dǎo)致經(jīng)常中斷或恢復(fù)，如何保證分毫無差呢?
每個線程在創(chuàng)建后，都會產(chǎn)生自己的程序計數(shù)器和棧幀，程序計數(shù)器用來存放執(zhí)行指令的偏移量和行號指示器等，線程執(zhí)行或恢復(fù)都要依賴程序計數(shù)器。程序計數(shù)器在各個線程之間互不影響，此區(qū)域也不會發(fā)生內(nèi)存溢出異常。

1.1. 定義

這是一塊較小的內(nèi)存空間，可看作當(dāng)前線程正在執(zhí)行的字節(jié)碼的行號指示器。如果當(dāng)前線程正在執(zhí)行的是：

Java方法
計數(shù)器記錄的就是當(dāng)前線程正在執(zhí)行的字節(jié)碼指令的地址

本地方法
那么程序計數(shù)器值為undefined

1.2. 作用

程序計數(shù)器（后文簡稱為 PCR）有兩個作用：

• 字節(jié)碼解釋器通過改變PCR依次讀取指令，實(shí)現(xiàn)代碼的流程控制，如：順序執(zhí)行、選擇、循環(huán)、異常處理
• 多線程情況下，PCR用于記錄當(dāng)前線程執(zhí)行的位置，從而當(dāng)線程被切換回來的時候能夠知道該線程上次運(yùn)行到哪了

1.3. 特點(diǎn)

一塊較小的內(nèi)存空間，【線程私有】。每條線程都有一個獨(dú)立的程序計數(shù)器。
唯一一個不會出現(xiàn)OOM的內(nèi)存區(qū)域。

2. Java虛擬機(jī)棧(JVM Stack)

2.1. 定義

。相對于基于寄存器的運(yùn)行環(huán)境，JVM是基于棧結(jié)構(gòu)的運(yùn)行環(huán)境。棧結(jié)構(gòu)移植性更好，可控性更強(qiáng)。

JVM中的虛擬機(jī)棧是描述Java方法執(zhí)行的內(nèi)存區(qū)域，屬【線程私有】。

棧中的元素用于支持虛擬機(jī)進(jìn)行方法調(diào)用，每個方法從開始調(diào)用到執(zhí)行完成的過程，就是棧幀從入棧到出棧的過程。

2.2 結(jié)構(gòu)

棧幀是方法運(yùn)行的基本結(jié)構(gòu)。

• 在活動線程中，只有位于棧頂?shù)膸攀怯行У模Q為當(dāng)前棧幀
• 正在執(zhí)行的方法稱為當(dāng)前方法

在執(zhí)行引擎運(yùn)行時，所有指令都只能針對當(dāng)前棧幀操作，StackOverflowError表示請求的棧溢出，導(dǎo)致內(nèi)存耗盡，通常出現(xiàn)在遞歸方法。

當(dāng)前方法的棧幀，都是正在戰(zhàn)斗的戰(zhàn)場，其中的操作棧是參與戰(zhàn)斗的士兵

操作棧的壓棧與出棧

虛擬機(jī)棧通過壓/出棧，對每個方法對應(yīng)的活動棧幀進(jìn)行運(yùn)算處理，方法正常執(zhí)行結(jié)束，肯定會跳轉(zhuǎn)到另一個棧幀上。
在執(zhí)行的過程中，如果出現(xiàn)異常，會進(jìn)行異?；厮?，返回地址通過異常處理表確定。

棧幀在整個JVM體系中的地位頗高，包括：局部變量表、操作棧、動態(tài)連接、方法返回地址等。

局部變量表

存放方法參數(shù)和局部變量。
相對于類屬性變量的準(zhǔn)備階段和初始化階段，局部變量沒有準(zhǔn)備階段，必須顯式初始化。
如果是非靜態(tài)方法，則在index[0]位置上存儲的是方法所屬對象的實(shí)例引用，隨后存儲的是參數(shù)和局部變量。
字節(jié)碼指令中的STORE指令就是將操作棧中計算完成的局部變量寫回局部變量表的存儲空間內(nèi)。

操作數(shù)棧

一個初始狀態(tài)為空的桶式結(jié)構(gòu)棧。由于 Java 沒有寄存器，所有參數(shù)傳遞使用操作數(shù)棧。在方法執(zhí)行過程中，會有各種指令往棧中寫入和提取信息。JVM的執(zhí)行引擎是基于棧的執(zhí)行引擎，其中的棧指的就是操作棧。

字節(jié)碼指令集的定義都是基于棧類型的，棧的深度在方法元信息的stack屬性中。

操作棧與局部變量表交互

詳細(xì)的字節(jié)碼操作順序如下:

第1處說明:局部變量表就像個中藥柜，里面有很多抽屜,依次編號為0, 1, 2,3，.,. n
字節(jié)碼指令istore_ 1就是打開1號抽屜，把棧頂中的數(shù)13存進(jìn)去
棧是一個很深的豎桶，任何時候只能對桶口元素進(jìn)行操作，所以數(shù)據(jù)只能在棧頂進(jìn)行存取

某些指令可以直接在抽屜里進(jìn)行，比如inc指令，直接對抽屜里的數(shù)值進(jìn)行+1操作
程序員面試過程中，常見的i++和++i的區(qū)別，可以從字節(jié)碼上對比出來

• iload_ 1 從局部變量表的第1號抽屜里取出一個數(shù),壓入棧頂，下一步直接在抽屜里實(shí)現(xiàn)+1的操作，而這個操作對棧頂元素的值沒有影響
• 所以istore_ 2只是把棧頂元素賦值給a
• 表格右列，先在第1號抽屜里執(zhí)行+1操作，然后通過iload_ 1 把第1號抽屜里的數(shù)壓入棧頂，所以istore_ 2存入的是+1之后的值

i++并非原子操作。即使通過volatile關(guān)鍵字進(jìn)行修飾，多個線程同時寫的話，也會產(chǎn)生數(shù)據(jù)互相覆蓋的問題。

動態(tài)連接

每個棧幀中包含一個在常量池中對當(dāng)前方法的引用，目的是支持方法調(diào)用過程的動態(tài)連接。

方法返回地址

方法執(zhí)行時有兩種退出情況：

正常退出
正常執(zhí)行到任何方法的返回字節(jié)碼指令，如RETURN、IRETURN、ARETURN等。

異常退出

無論何種，都將返回至方法當(dāng)前被調(diào)用的位置。方法退出的過程相當(dāng)于彈出當(dāng)前棧幀。

退出可能有三種方式:

• 返回值壓入，上層調(diào)用棧幀
• 異常信息拋給能夠處理的棧幀
• PC計數(shù)器指向方法調(diào)用后的下一條指令

Java虛擬機(jī)棧是描述Java方法運(yùn)行過程的內(nèi)存模型。Java虛擬機(jī)棧會為每一個即將運(yùn)行的Java方法創(chuàng)建“棧幀”。用于存儲該方法在運(yùn)行過程中所需要的一些信息。

• 局部變量表
• 存放基本數(shù)據(jù)類型變量、引用類型的變量、returnAddress類型的變量
• 操作數(shù)棧
• 動態(tài)鏈接
• 當(dāng)前方法的常量池指針
• 當(dāng)前方法的返回地址
• 方法出口等信息

每一個方法從被調(diào)用到執(zhí)行完成的過程,都對應(yīng)著一個個棧幀在JVM棧中的入棧和出棧過程

注意：人們常說，Java的內(nèi)存空間分為“?！焙汀岸选?，棧中存放局部變量，堆中存放對象。
這句話不完全正確！這里的“堆”可以這么理解，但這里的“?！本褪乾F(xiàn)在講的虛擬機(jī)棧,或者說Java虛擬機(jī)棧中的局部變量表部分.
真正的Java虛擬機(jī)棧是由一個個棧幀組成，而每個棧幀中都擁有：局部變量表、操作數(shù)棧、動態(tài)鏈接、方法出口信息.

特點(diǎn)

局部變量表的創(chuàng)建是在方法被執(zhí)行的時候，隨棧幀創(chuàng)建而創(chuàng)建。
表的大小在編譯期就確定，在創(chuàng)建的時候只需分配事先規(guī)定好的大小即可。在方法運(yùn)行過程中，表的大小不會改變。Java虛擬機(jī)棧會出現(xiàn)兩種異常：

StackOverFlowError
若Java虛擬機(jī)棧的內(nèi)存大小不允許動態(tài)擴(kuò)展,那么當(dāng)線程請求的棧深度大于虛擬機(jī)允許的最大深度時(但內(nèi)存空間可能還有很多),就拋出此異常
棧內(nèi)存默認(rèn)最大是1M,超出則拋出StackOverflowError

OutOfMemoryError
若Java虛擬機(jī)棧的內(nèi)存大小允許動態(tài)擴(kuò)展,且當(dāng)線程請求棧時內(nèi)存用完了,無法再動態(tài)擴(kuò)展了,此時拋出OutOfMemoryError異常

Java虛擬機(jī)棧也是線程私有的，每個線程都有各自的Java虛擬機(jī)棧，而且隨著線程的創(chuàng)建而創(chuàng)建，隨線程的死亡而死亡。

3. 本地方法棧(Native Method Stack)

和虛擬機(jī)棧功能類似，虛擬機(jī)棧是為虛擬機(jī)執(zhí)行JAVA方法而準(zhǔn)備的
虛擬機(jī)規(guī)范沒有規(guī)定具體的實(shí)現(xiàn)，由不同的虛擬機(jī)廠商去實(shí)現(xiàn)。
HotSpot虛擬機(jī)中虛擬機(jī)棧和本地方法棧的實(shí)現(xiàn)式一樣的。同樣，超出大小以后
也會拋出StackOverflowError.

本地方法棧和Java虛擬機(jī)棧實(shí)現(xiàn)的功能與拋出異常幾乎相同
只不過虛擬機(jī)棧是為虛擬機(jī)執(zhí)行Java方法(也就是字節(jié)碼)服務(wù),本地方法區(qū)則為虛擬機(jī)使用到的Native方法服務(wù).

在JVM內(nèi)存布局中，也是線程對象私有的,但是虛擬機(jī)?！爸鲀?nèi)”，而本地方法棧“主外”
這個“內(nèi)外”是針對JVM來說的，本地方法棧為Native方法服務(wù)
線程開始調(diào)用本地方法時，會進(jìn)入一個不再受JVM約束的世界
本地方法可以通過JNI(Java Native Interface)來訪問虛擬機(jī)運(yùn)行時的數(shù)據(jù)區(qū)，甚至可以調(diào)用寄存器,具有和JVM相同的能力和權(quán)限
當(dāng)大量本地方法出現(xiàn)時,勢必會削弱JVM對系統(tǒng)的控制力,因?yàn)樗某鲥e信息都比較黑盒.
對于內(nèi)存不足的情況，本地方法棧還是會拋出native heap OutOfMemory

最著名的本地方法應(yīng)該是System.currentTimeMillis()，JNI 使Java深度使用OS的特性功能，復(fù)用非Java代碼
但是在項(xiàng)目過程中，如果大量使用其他語言來實(shí)現(xiàn)JNI,就會喪失跨平臺特性，威脅到程序運(yùn)行的穩(wěn)定性
假如需要與本地代碼交互，就可以用中間標(biāo)準(zhǔn)框架進(jìn)行解耦，這樣即使本地方法崩潰也不至于影響到JVM的穩(wěn)定
當(dāng)然，如果要求極高的執(zhí)行效率、偏底層的跨進(jìn)程操作等，可以考慮設(shè)計為JNI調(diào)用方式

4 Java堆(Java Heap)

JVM啟動時創(chuàng)建，存放對象的實(shí)例。垃圾回收器主要就是管理堆內(nèi)存。
Heap是OOM故障最主要的發(fā)源地，它存儲著幾乎所有的實(shí)例對象，堆由垃圾收集器自動回收，堆區(qū)由各子線程共享使用
通常情況下，它占用的空間是所有內(nèi)存區(qū)域中最大的，但如果無節(jié)制地創(chuàng)建大量對象，也容易消耗完所有的空間
堆的內(nèi)存空間既可以固定大小，也可運(yùn)行時動態(tài)地調(diào)整，通過如下參數(shù)設(shè)定初始值和最大值，比如

-Xms256M. -Xmx1024M

其中-X表示它是JVM運(yùn)行參數(shù)

• ms是memorystart的簡稱 最小堆容量
• mx是memory max的簡稱 最大堆容量

但是在通常情況下，服務(wù)器在運(yùn)行過程中，堆空間不斷地擴(kuò)容與回縮，勢必形成不必要的系統(tǒng)壓力，所以在線上生產(chǎn)環(huán)境中，JVM的Xms和Xmx設(shè)置成一樣大小，避免在GC后調(diào)整堆大小時帶來的額外壓力

堆分成兩大塊:新生代和老年代
對象產(chǎn)生之初在新生代，步入暮年時進(jìn)入老年代，但是老年代也接納在新生代無法容納的超大對象

新生代= 1個Eden區(qū)+ 2個Survivor區(qū)
絕大部分對象在Eden區(qū)生成，當(dāng)Eden區(qū)裝填滿的時候，會觸發(fā)Young GC。垃圾回收的時候，在Eden區(qū)實(shí)現(xiàn)清除策略，沒有被引用的對象則直接回收。依然存活的對象會被移送到Survivor區(qū)，這個區(qū)真是名副其實(shí)的存在
Survivor 區(qū)分為S0和S1兩塊內(nèi)存空間，送到哪塊空間呢?每次Young GC的時候，將存活的對象復(fù)制到未使用的那塊空間，然后將當(dāng)前正在使用的空間完全清除，交換兩塊空間的使用狀態(tài)
如果YGC要移送的對象大于Survivor區(qū)容量上限，則直接移交給老年代
假如一些沒有進(jìn)取心的對象以為可以一直在新生代的Survivor區(qū)交換來交換去，那就錯了。每個對象都有一個計數(shù)器，每次YGC都會加1。

-XX:MaxTenuringThreshold 

參數(shù)能配置計數(shù)器的值到達(dá)某個閾值的時候，對象從新生代晉升至老年代。如果該參數(shù)配置為1,那么從新生代的Eden區(qū)直接移至老年代。默認(rèn)值是15，可以在Survivor 區(qū)交換14次之后，晉升至老年代

若Survivor區(qū)無法放下，或者超大對象的閾值超過上限，則嘗試在老年代中進(jìn)行分配;
如果老年代也無法放下，則會觸發(fā)Full Garbage Collection(Full GC);
如果依然無法放下，則拋OOM.

堆出現(xiàn)OOM的概率是所有內(nèi)存耗盡異常中最高的
出錯時的堆內(nèi)信息對解決問題非常有幫助，所以給JVM設(shè)置運(yùn)行參數(shù)-

XX:+HeapDumpOnOutOfMemoryError

讓JVM遇到OOM異常時能輸出堆內(nèi)信息

在不同的JVM實(shí)現(xiàn)及不同的回收機(jī)制中，堆內(nèi)存的劃分方式是不一樣的

存放所有的類實(shí)例及數(shù)組對象
除了實(shí)例數(shù)據(jù)，還保存了對象的其他信息，如Mark Word（存儲對象哈希碼，GC標(biāo)志，GC年齡，同步鎖等信息），Klass Pointy(指向存儲類型元數(shù)據(jù)的指針）及一些字節(jié)對齊補(bǔ)白的填充數(shù)據(jù)（若實(shí)例數(shù)據(jù)剛好滿足8字節(jié)對齊，則可不存在補(bǔ)白）

特點(diǎn)

Java虛擬機(jī)所需要管理的內(nèi)存中最大的一塊.

堆內(nèi)存物理上不一定要連續(xù),只需要邏輯上連續(xù)即可,就像磁盤空間一樣.
堆是垃圾回收的主要區(qū)域,所以也被稱為GC堆.

堆的大小既可以固定也可以擴(kuò)展,但主流的虛擬機(jī)堆的大小是可擴(kuò)展的(通過-Xmx和-Xms控制),因此當(dāng)線程請求分配內(nèi)存,但堆已滿,且內(nèi)存已滿無法再擴(kuò)展時,就拋出OutOfMemoryError.

線程共享
整個Java虛擬機(jī)只有一個堆,所有的線程都訪問同一個堆.
它是被所有線程共享的一塊內(nèi)存區(qū)域,在虛擬機(jī)啟動時創(chuàng)建.
而程序計數(shù)器、Java虛擬機(jī)棧、本地方法棧都是一個線程對應(yīng)一個

5 方法區(qū)

5.1 定義

Java虛擬機(jī)規(guī)范中定義方法區(qū)是堆的一個邏輯區(qū)劃部分,具體實(shí)現(xiàn)根據(jù)不同虛擬機(jī)來實(shí)現(xiàn),如: HotSpot在Java7中方法區(qū)放在永久代，Java8放在元數(shù)據(jù)空間，并且通過GC機(jī)制對這個區(qū)域進(jìn)行管理。

別名Non-Heap(非堆)，以與Java堆區(qū)分。方法區(qū)中存放已經(jīng)被虛擬機(jī)加載的：

• 類信息
• 常量
• 常量存儲在【運(yùn)行時常量池】
• 靜態(tài)變量
• 即時編譯器(JIT)編譯后的代碼等數(shù)據(jù)

5.2 特點(diǎn)

線程共享
方法區(qū)是堆的一個邏輯部分,因此和堆一樣,都是線程共享的.整個虛擬機(jī)中只有一個方法區(qū).
永久代
方法區(qū)中的信息一般需要長期存在，而且它又是堆的邏輯分區(qū)，因此用堆的劃分方法，我們把方法區(qū)稱為永久代.
內(nèi)存回收效率低
Java虛擬機(jī)規(guī)范對方法區(qū)的要求比較寬松,可以不實(shí)現(xiàn)垃圾收集.
方法區(qū)中的信息一般需要長期存在,回收一遍內(nèi)存之后可能只有少量信息無效.
對方法區(qū)的內(nèi)存回收的主要目標(biāo)是:對常量池的回收和對類型的卸載
和堆一樣，允許固定大小，也允許可擴(kuò)展的大小，還允許不實(shí)現(xiàn)垃圾回收。

當(dāng)方法區(qū)內(nèi)存空間無法滿足內(nèi)存分配需求時,將拋出OutOfMemoryError異常.

5.3 運(yùn)行時常量池(Runtime Constant Pool)

5.3.1 定義

方法區(qū)的一部分。

.java文件被編譯之后生成的.class文件中除了包含：類的版本、字段、方法、接口等描述信息外，還有一項(xiàng)就是常量池。
常量池中存放編譯時期產(chǎn)生的各種字面量和符號引用，.class文件中的常量池中的所有的內(nèi)容在類被加載后存放到方法區(qū)的運(yùn)行時常量池中。

// age 是一個變量，可被賦值
// 21 是一個字面值常量，不能被賦值
PS：int age = 21; 
// pai 是一個符號常量，一旦被賦值之后就不能被修改
int final pai = 3.14;

JDK6、7、8三個版本中， 運(yùn)行時常量池的所處區(qū)域一直在不斷的變化：

• 6時，是方法區(qū)的一部分
• 7時，又放到堆內(nèi)存
• 8時，出現(xiàn)了元空間，又回到了方法區(qū)

這也說明了官方對“永久代”的優(yōu)化從7就已經(jīng)開始了。

5.3.2 特性

運(yùn)行時常量池相對于class文件常量池的另外一個特性是具備動態(tài)性，Java語言并不要求常量一定只有編譯器才產(chǎn)生，也就是并非預(yù)置入class文件中常量池的內(nèi)容才能進(jìn)入方法區(qū)運(yùn)行時常量池，運(yùn)行期間也可能將新的常量放入池中。

String類的intern()方法就是采用了運(yùn)行時常量池的動態(tài)性。當(dāng)調(diào)用 intern 方法時，看池中已包含一個等于此 String 對象的字符串：

是
則返回池中的字符串

否
將此 String 對象添加到池中，并返回此 String 對象的引用

5.3.3 可能拋出的異常

運(yùn)行時常量池是方法區(qū)的一部分,所以會受到方法區(qū)內(nèi)存的限制,因此當(dāng)常量池?zé)o法再申請到內(nèi)存時就會拋出OutOfMemoryError異常.

我們一般在一個類中通過public static final來聲明一個常量。這個類被編譯后便生成Class文件，這個類的所有信息都存儲在這個class文件中。

當(dāng)這個類被Java虛擬機(jī)加載后，class文件中的常量就存放在方法區(qū)的運(yùn)行時常量池中。而且在運(yùn)行期間，可以向常量池中添加新的常量。如：String類的intern()方法就能在運(yùn)行期間向常量池中添加字符串常量。

當(dāng)運(yùn)行時常量池中的某些常量沒有被對象引用，同時也沒有被變量引用，那么就需要垃圾收集器回收。

6 直接內(nèi)存(Direct Memory)

直接內(nèi)存不是虛擬機(jī)運(yùn)行時數(shù)據(jù)區(qū)的一部分,也不是JVM規(guī)范中定義的內(nèi)存區(qū)域,但在JVM的實(shí)際運(yùn)行過程中會頻繁地使用這塊區(qū)域.而且也會拋OOM

在JDK 1.4中加入了NIO(New Input／Output)類,引入了一種基于管道和緩沖區(qū)的IO方式,它可以使用Native函數(shù)庫直接分配堆外內(nèi)存,然后通過一個存儲在堆里的DirectByteBuffer對象作為這塊內(nèi)存的引用來操作堆外內(nèi)存中的數(shù)據(jù).
這樣能在一些場景中顯著提升性能,因?yàn)楸苊饬嗽贘ava堆和Native堆中來回復(fù)制數(shù)據(jù).

綜上看來
程序計數(shù)器、Java虛擬機(jī)棧、本地方法棧是線程私有的，即每個線程都擁有各自的程序計數(shù)器、Java虛擬機(jī)棧、本地方法區(qū)。并且他們的生命周期和所屬的線程一樣。
而堆、方法區(qū)是線程共享的，在Java虛擬機(jī)中只有一個堆、一個方法棧。并在JVM啟動的時候就創(chuàng)建，JVM停止才銷毀。

7 Metaspace (元空間)

到了JDK8，元空間的前身Perm區(qū)（永久代）被淘汰，在JDK7及之前的版本中，只有Hotspot才有Perm區(qū)，它在啟動時固定大小，很難進(jìn)行調(diào)優(yōu)，并且Full GC時會移動類元信息。

在某些場景下，若動態(tài)加載類過多，容易產(chǎn)生Perm區(qū)的OOM。比如某工程因?yàn)楣δ茳c(diǎn)較多，運(yùn)行過程中，要不斷動態(tài)加載很多類，經(jīng)常出現(xiàn)錯誤：

Exception in thread ‘dubbo client x.x connector'
java.lang.OutOfMemoryError: PermGenspac

為解決該問題，需要設(shè)定運(yùn)行參數(shù)

-XX:MaxPermSize= l280m

如果部署到新機(jī)器上，往往會因?yàn)镴VM參數(shù)沒有修改導(dǎo)致故障再現(xiàn)。不熟悉此應(yīng)用的人排查問題時都苦不堪言。此外，永久代在GC過程中還存在諸多問題。

所以，JDK8使用元空間替換永久代。區(qū)別于永久代，元空間在本地內(nèi)存中分配。即，
只要本地內(nèi)存足夠，它不會出現(xiàn)類似永久代的java.lang.OutOfMemoryError: PermGen space

對永久代的設(shè)置參數(shù) PermSize 和MaxPermSize也會失效。在JDK8及以上版本，設(shè)定MaxPermSize參數(shù)，JVM在啟動時并不會報錯，但會提示:

Java HotSpot 64Bit Server VM warning:ignoring option MaxPermSize=2560m; support was removed in 8.0

默認(rèn)情況下，“元空間”的大小可以動態(tài)調(diào)整，或者使用新參數(shù)MaxMetaspaceSize來限制本地內(nèi)存分配給類元數(shù)據(jù)的大小。

在JDK8里，Perm 區(qū)所有內(nèi)容中

• 字符串常量移至堆內(nèi)存
• 其他內(nèi)容包括類元信息、字段、靜態(tài)屬性、方法、常量等都移動至元空間
  

比如上圖中的Object類元信息、靜態(tài)屬性System.out、整型常量000000等
圖中顯示在常量池中的String，其實(shí)際對象是被保存在堆內(nèi)存中的。

元空間特色

• 充分利用了Java語言規(guī)范：類及相關(guān)的元數(shù)據(jù)的生命周期與類加載器的一致
• 每個類加載器都有它的內(nèi)存區(qū)域-元空間
• 只進(jìn)行線性分配
• 不會單獨(dú)回收某個類（除了重定義類 RedefineClasses 或類加載失?。?/li>
• 沒有GC掃描或壓縮
• 元空間里的對象不會被轉(zhuǎn)移
• 如果GC發(fā)現(xiàn)某個類加載器不再存活，會對整個元空間進(jìn)行集體回收

GC

• Full GC時，指向元數(shù)據(jù)指針都不用再掃描，減少了Full GC的時間
• 很多復(fù)雜的元數(shù)據(jù)掃描的代碼（尤其是CMS里面的那些）都刪除了
• 元空間只有少量的指針指向Java堆
• 這包括：類的元數(shù)據(jù)中指向java.lang.Class實(shí)例的指針;數(shù)組類的元數(shù)據(jù)中，指向java.lang.Class集合的指針。
• 沒有元數(shù)據(jù)壓縮的開銷
• 減少了GC Root的掃描（不在掃描虛擬機(jī)里面的已加載類的目錄和其它的內(nèi)部哈希表）
• G1中，并發(fā)標(biāo)記階段完成后就可以進(jìn)行類的卸載
  

元空間內(nèi)存分配模型

• 絕大多數(shù)的類元數(shù)據(jù)的空間都在本地內(nèi)存中分配
• 用來描述類元數(shù)據(jù)的對象也被移除
• 為元數(shù)據(jù)分配了多個映射的虛擬內(nèi)存空間
• 為每個類加載器分配一個內(nèi)存塊列表

塊的大小取決于類加載器的類型
Java反射的字節(jié)碼存取器（sun.reflect.DelegatingClassLoader ）占用內(nèi)存更小

• 空閑塊內(nèi)存返還給塊內(nèi)存列表
• 當(dāng)元空間為空，虛擬內(nèi)存空間會被回收
• 減少了內(nèi)存碎片
  

最后,從線程共享的角度來看

• 堆和元空間是所有線程共享的
• 虛擬機(jī)棧、本地方法棧、程序計數(shù)器是線程內(nèi)部私有的
  

從這個角度看一下Java內(nèi)存結(jié)構(gòu)

8 從GC角度看Java堆

堆和方法區(qū)都是線程共享的區(qū)域，主要用來存放對象的相關(guān)信息。一個接口中的多個實(shí)現(xiàn)類需要的內(nèi)存可能不一樣，一個方法中的多個分支需要的內(nèi)存也可能不一樣，我們只有在程序運(yùn)行期間才能知道會創(chuàng)建哪些對象，因此， 這部分的內(nèi)存和回收都是動態(tài)的，垃圾收集器所關(guān)注的就是這部分內(nèi)存（本節(jié)后續(xù)所說的“內(nèi)存”分配與回收也僅指這部分內(nèi)存）。而在JDK1.7和1.8對這部分內(nèi)存的分配也有所不同：

Java8中堆內(nèi)存分配如下圖：

9 JVM關(guān)閉

• 正常關(guān)閉：當(dāng)最后一個非守護(hù)線程結(jié)束或調(diào)用了System.exit或通過其他特定于平臺的方式,比如ctrl+c。
• 強(qiáng)制關(guān)閉：調(diào)用Runtime.halt方法，或在操作系統(tǒng)中直接kill（發(fā)送single信號）掉JVM進(jìn)程。
• 異常關(guān)閉：運(yùn)行中遇到RuntimeException 異常等

在某些情況下，我們需要在JVM關(guān)閉時做一些掃尾的工作，比如刪除臨時文件、停止日志服務(wù)。為此JVM提供了關(guān)閉鉤子（shutdown hocks）來做這些事件。

Runtime類封裝java應(yīng)用運(yùn)行時的環(huán)境，每個java應(yīng)用程序都有一個Runtime類實(shí)例，使用程序能與其運(yùn)行環(huán)境相連。

關(guān)閉鉤子本質(zhì)上是一個線程（也稱為hock線程），可以通過Runtime的addshutdownhock （Thread hock）向主jvm注冊一個關(guān)閉鉤子。hock線程在jvm正常關(guān)閉時執(zhí)行，強(qiáng)制關(guān)閉不執(zhí)行。

對于在jvm中注冊的多個關(guān)閉鉤子，他們會并發(fā)執(zhí)行，jvm并不能保證他們的執(zhí)行順序。

參考

《碼出高效》

到此這篇關(guān)于華為技術(shù)專家講解JVM內(nèi)存模型(收藏)的文章就介紹到這了,更多相關(guān)JVM內(nèi)存模型內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論