本JVM系列屬于本人學(xué)習(xí)過(guò)程當(dāng)中總結(jié)的一些知識(shí)點(diǎn)，目的是想讓讀者更快地掌握J(rèn)VM相關(guān)的知識(shí)要點(diǎn)，難免會(huì)有所側(cè)重，若想要更加系統(tǒng)更加詳細(xì)的學(xué)習(xí)JVM知識(shí)，還是需要去閱讀專(zhuān)業(yè)的書(shū)籍和文檔。

本文主題內(nèi)容：

1、JVM 內(nèi)存區(qū)域概覽2、堆區(qū)的空間分配是怎么樣？堆溢出的演示3、創(chuàng)建一個(gè)新對(duì)象內(nèi)存是怎么分配的？4、方法區(qū) 到 Metaspace 元空間5、棧幀是什么？棧幀里有什么？怎么理解？6、本地方法棧8、程序計(jì)數(shù)器9、Code Cache 是什么？

注：請(qǐng) 區(qū)分 JVM內(nèi)存結(jié)構(gòu)（內(nèi)存布局） 和 JMM（Java內(nèi)存模型）這兩個(gè)不同的概念！

內(nèi)存是非常重要的系統(tǒng)資源，是硬盤(pán)和CPU的中間倉(cāng)庫(kù)及橋梁，承載著操作系統(tǒng)和應(yīng)用程序的實(shí)時(shí)運(yùn)行。JVM 內(nèi)存布局規(guī)定了 Java 在運(yùn)行過(guò)程中內(nèi)存申請(qǐng)、分配、管理的策略 ，保證了 JVM 的高效穩(wěn)定運(yùn)行。

上圖描述了當(dāng)前比較經(jīng)典的Java內(nèi)存布局。（堆區(qū)畫(huà)小了2333，按理來(lái)說(shuō)應(yīng)該是最大的區(qū)域）

如果按照線(xiàn)程是否共享來(lái)分類(lèi)的話(huà)，如下圖所示：

PS：線(xiàn)程是否共享這點(diǎn)，實(shí)際上理解了每塊區(qū)域的實(shí)際用處之后，就很自然而然的就記住了。不需要死記硬背。

下面讓我們來(lái)了解下各個(gè)區(qū)域。

我們先來(lái)說(shuō)堆。堆是 OOM故障最主要的發(fā)生區(qū)域。它是內(nèi)存區(qū)域中最大的一塊區(qū)域，被所有線(xiàn)程共享，存儲(chǔ)著幾乎所有的實(shí)例對(duì)象、數(shù)組。所有的對(duì)象實(shí)例以及數(shù)組都要在堆上分配，但是隨著JIT編譯器的發(fā)展與逃逸分析技術(shù)逐漸成熟，棧上分配、標(biāo)量替換優(yōu)化技術(shù)將會(huì)導(dǎo)致一些微妙的變化發(fā)生，所有的對(duì)象都分配在堆上也漸漸變得不是那么“絕對(duì)”了。

延伸知識(shí)點(diǎn)：JIT編譯優(yōu)化中的一部分內(nèi)容 - 逃逸分析。

推薦閱讀：深入理解Java中的逃逸分析

Java堆是垃圾收集器管理的主要區(qū)域，因此很多時(shí)候也被稱(chēng)做“GC堆”。從內(nèi)存回收的角度來(lái)看，由于現(xiàn)在收集器基本都采用分代收集算法，所以Java堆中還可以細(xì)分為：新生代和老年代。再細(xì)致一點(diǎn)的有Eden空間、From Survivor空間、To Survivor空間等。從內(nèi)存分配的角度來(lái)看，線(xiàn)程共享的Java堆中可能劃分出多個(gè)線(xiàn)程私有的分配緩沖區(qū)（Thread Local Allocation Buffer,TLAB）。不過(guò)無(wú)論如何劃分，都與存放內(nèi)容無(wú)關(guān)，無(wú)論哪個(gè)區(qū)域，存儲(chǔ)的都仍然是對(duì)象實(shí)例，進(jìn)一步劃分的目的是為了更好地回收內(nèi)存，或者更快地分配內(nèi)存。

根據(jù)Java虛擬機(jī)規(guī)范的規(guī)定，Java堆可以處于物理上不連續(xù)的內(nèi)存空間中，只要邏輯上是連續(xù)的即可，就像我們的磁盤(pán)空間一樣。在實(shí)現(xiàn)時(shí)，既可以實(shí)現(xiàn)成固定大小的，也可以在運(yùn)行時(shí)動(dòng)態(tài)地調(diào)整。

如何調(diào)整呢？

通過(guò)設(shè)置如下參數(shù)，可以設(shè)定堆區(qū)的初始值和最大值，比如 -Xms256M-Xmx1024M，其中 -X這個(gè)字母代表它是JVM運(yùn)行時(shí)參數(shù)， ms是 memory start的簡(jiǎn)稱(chēng)，中文意思就是內(nèi)存初始值， mx 是 memory max的簡(jiǎn)稱(chēng)，意思就是最大內(nèi)存。

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

另外，再?gòu)?qiáng)調(diào)一下堆空間內(nèi)存分配的大體情況。

這里可能就會(huì)有人來(lái)問(wèn)了，你從哪里知道的呢？如果我想配置這個(gè)比例，要怎么修改呢？

我先來(lái)告訴你怎么看虛擬機(jī)的默認(rèn)配置。命令行上執(zhí)行如下命令，就可以查看當(dāng)前JDK版本所有默認(rèn)的JVM參數(shù)。

對(duì)應(yīng)的輸出應(yīng)該有幾百行，我們這里去看和堆內(nèi)存分配相關(guān)的兩個(gè)參數(shù)

>java -XX:+PrintFlagsFinal -version[Global flags]    ...    uintx InitialSurvivorRatio                      = 8    uintx NewRatio                                  = 2    ...java version '1.8.0_131'Java(TM) SE Runtime Environment (build 1.8.0_131-b11)Java HotSpot(TM) 64-Bit Server VM (build 25.131-b11, mixed mode)

參數(shù)作用-XX:InitialSurvivorRatio新生代Eden/Survivor空間的初始比例-XX:NewRatioOld區(qū)/Young區(qū)的內(nèi)存比例

因?yàn)樾律怯蒃den + S0 + S1組成的，所以按照上述默認(rèn)比例，如果eden區(qū)內(nèi)存大小是40M，那么兩個(gè)survivor區(qū)就是5M，整個(gè)young區(qū)就是50M，然后可以算出Old區(qū)內(nèi)存大小是100M，堆區(qū)總大小就是150M。

java.lang.OutOfMemoryError: Java heap spaceDumping heap to java_pid32372.hprof ...Heapdump file created [7774077 bytes in0.009 secs]Exceptionin thread 'main' java.lang.OutOfMemoryError: Java heap space    at jvm.HeapOOMTest.main(HeapOOMTest.java:18)

-XX:+HeapDumpOnOutOfMemoryError 可以讓JVM在遇到OOM異常時(shí)，輸出堆內(nèi)信息，特別是對(duì)相隔數(shù)月才出現(xiàn)的OOM異常尤為重要。

看完上面對(duì)堆的介紹，我們趁熱打鐵再學(xué)習(xí)一下JVM創(chuàng)建一個(gè)新對(duì)象的內(nèi)存分配流程。

絕大部分對(duì)象在Eden區(qū)生成，當(dāng)Eden區(qū)裝填滿(mǎn)的時(shí)候，會(huì)觸發(fā) YoungGarbageCollection，即 YGC。垃圾回收的時(shí)候，在Eden區(qū)實(shí)現(xiàn)清除策略，沒(méi)有被引用的對(duì)象則直接回收。依然存活的對(duì)象會(huì)被移送到Survivor區(qū)。Survivor區(qū)分為so和s1兩塊內(nèi)存空間。每次 YGC的時(shí)候，它們將存活的對(duì)象復(fù)制到未使用的那塊空間，然后將當(dāng)前正在使用的空間完全清除，交換兩塊空間的使用狀態(tài)。如果 YGC要移送的對(duì)象大于Survivor區(qū)容量的上限，則直接移交給老年代。一個(gè)對(duì)象也不可能永遠(yuǎn)呆在新生代，就像人到了18歲就會(huì)成年一樣，在JVM中 －XX:MaxTenuringThreshold參數(shù)就是來(lái)配置一個(gè)對(duì)象從新生代晉升到老年代的閾值。默認(rèn)值是15， 可以在Survivor區(qū)交換14次之后，晉升至老年代。

上述涉及到一部分垃圾回收的名詞，不熟悉的讀者可以查閱資料或者看下本系列的垃圾回收章節(jié)。

在 HotSpot JVM 中，永久代（ ≈ 方法區(qū)）中用于存放類(lèi)和方法的元數(shù)據(jù)以及常量池，比如 Class和 Method。每當(dāng)一個(gè)類(lèi)初次被加載的時(shí)候，它的元數(shù)據(jù)都會(huì)放到永久代中。

永久代是有大小限制的，因此如果加載的類(lèi)太多，很有可能導(dǎo)致永久代內(nèi)存溢出，即萬(wàn)惡的 java.lang.OutOfMemoryError:PermGen，為此我們不得不對(duì)虛擬機(jī)做調(diào)優(yōu)。

那么，Java 8 中 PermGen 為什么被移出 HotSpot JVM 了？（詳見(jiàn)：JEP 122: Remove the Permanent Generation）：

1、由于 PermGen 內(nèi)存經(jīng)常會(huì)溢出，引發(fā)惱人的 java.lang.OutOfMemoryError:PermGen，因此 JVM 的開(kāi)發(fā)者希望這一塊內(nèi)存可以更靈活地被管理，不要再經(jīng)常出現(xiàn)這樣的 OOM

2、移除 PermGen 可以促進(jìn) HotSpot JVM 與 JRockit VM 的融合，因?yàn)?JRockit 沒(méi)有永久代。

根據(jù)上面的各種原因，PermGen 最終被移除，方法區(qū)移至 Metaspace，字符串常量池移至堆區(qū)。

準(zhǔn)確來(lái)說(shuō)，Perm 區(qū)中的字符串常量池被移到了堆內(nèi)存中是在Java7 之后，Java 8 時(shí)，PermGen 被元空間代替，其他內(nèi)容比如類(lèi)元信息、字段、靜態(tài)屬性、方法、常量等都移動(dòng)到元空間區(qū)。比如 java/lang/Object類(lèi)元信息、靜態(tài)屬性 System.out、整形常量 100000等。

元空間的本質(zhì)和永久代類(lèi)似，都是對(duì)JVM規(guī)范中方法區(qū)的實(shí)現(xiàn)。不過(guò)元空間與永久代之間最大的區(qū)別在于：元空間并不在虛擬機(jī)中，而是使用本地內(nèi)存。因此，默認(rèn)情況下，元空間的大小僅受本地內(nèi)存限制。（和后面提到的直接內(nèi)存一樣，都是使用本地內(nèi)存）

In JDK 8, classes metadata is now stored in the native heap and this space is called Metaspace.

對(duì)應(yīng)的JVM調(diào)參：

對(duì)于每一個(gè)線(xiàn)程，JVM 都會(huì)在線(xiàn)程被創(chuàng)建的時(shí)候，創(chuàng)建一個(gè)單獨(dú)的棧。也就是說(shuō)虛擬機(jī)棧的生命周期和線(xiàn)程是一致，并且是線(xiàn)程私有的。除了Native方法以外，Java方法都是通過(guò)Java 虛擬機(jī)棧來(lái)實(shí)現(xiàn)調(diào)用和執(zhí)行過(guò)程的（需要程序技術(shù)器、堆、元空間內(nèi)數(shù)據(jù)的配合）。所以Java虛擬機(jī)棧是虛擬機(jī)執(zhí)行引擎的核心之一。而Java虛擬機(jī)棧中出棧入棧的元素就稱(chēng)為「棧幀」。

棧幀(Stack Frame)是用于支持虛擬機(jī)進(jìn)行方法調(diào)用和方法執(zhí)行的數(shù)據(jù)結(jié)構(gòu)。棧幀存儲(chǔ)了方法的局部變量表、操作數(shù)棧、動(dòng)態(tài)連接和方法返回地址等信息。每一個(gè)方法從調(diào)用至執(zhí)行完成的過(guò)程，都對(duì)應(yīng)著一個(gè)棧幀在虛擬機(jī)棧里從入棧到出棧的過(guò)程。

棧對(duì)應(yīng)線(xiàn)程，棧幀對(duì)應(yīng)方法

在活動(dòng)線(xiàn)程中， 只有位于棧頂?shù)膸攀怯行У模?稱(chēng)為當(dāng)前棧幀。正在執(zhí)行的方法稱(chēng)為當(dāng)前方法。在執(zhí)行引擎運(yùn)行時(shí)， 所有指令都只能針對(duì)當(dāng)前棧幀進(jìn)行操作。而 StackOverflowError 表示請(qǐng)求的棧溢出， 導(dǎo)致內(nèi)存耗盡， 通常出現(xiàn)在遞歸方法中。

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

可以看出棧幀在整個(gè)JVM 體系中的地位頗高。下面也具體介紹一下棧幀中的存儲(chǔ)信息。

局部變量表就是存放方法參數(shù)和方法內(nèi)部定義的局部變量的區(qū)域。

局部變量表所需的內(nèi)存空間在編譯期間完成分配，當(dāng)進(jìn)入一個(gè)方法時(shí)，這個(gè)方法需要在幀中分配多大的局部變量空間是完全確定的，在方法運(yùn)行期間不會(huì)改變局部變量表的大小。

這里直接上代碼，更好理解。

如果局部變量是Java的8種基本基本數(shù)據(jù)類(lèi)型，則存在局部變量表中，如果是引用類(lèi)型。如new出來(lái)的String，局部變量表中存的是引用，而實(shí)例在堆中。

操作數(shù)棧（Operand Stack）看名字可以知道是一個(gè)棧結(jié)構(gòu)。Java虛擬機(jī)的解釋執(zhí)行引擎稱(chēng)為“基于棧的執(zhí)行引擎”，其中所指的“?！本褪遣僮鲾?shù)棧。當(dāng)JVM為方法創(chuàng)建棧幀的時(shí)候，在棧幀中為方法創(chuàng)建一個(gè)操作數(shù)棧，保證方法內(nèi)指令可以完成工作。

還是用實(shí)操理解一下。

/** * @author Richard_yyf */public class OperandStackTest {    public int sum(int a, int b) {        return a + b;    }}

編譯生成 .class文件之后，再反匯編查看匯編指令

  public int sum(int, int);    descriptor: (II)I    flags: ACC_PUBLIC    Code:      stack=2, locals=3, args_size=3 // 最大棧深度為2 局部變量個(gè)數(shù)為3         0: iload_1 // 局部變量1 壓棧         1: iload_2 // 局部變量2 壓棧         2: iadd    // 棧頂兩個(gè)元素相加，計(jì)算結(jié)果壓棧         3: ireturn      LineNumberTable:        line 10: 0

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

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

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

無(wú)論何種退出情況，都將返回至方法當(dāng)前被調(diào)用的位置。方法退出的過(guò)程相當(dāng)于彈出當(dāng)前棧幀，退出可能有三種方式：

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

延伸閱讀：JVM機(jī)器指令集圖解

本地方法棧（Native Method Stack）與虛擬機(jī)棧所發(fā)揮的作用是非常相似的，它們之間的區(qū)別不過(guò)是虛擬機(jī)棧為虛擬機(jī)執(zhí)行Java方法（也就是字節(jié)碼）服務(wù)，而本地方法棧則為虛擬機(jī)使用到的Native方法服務(wù)。在虛擬機(jī)規(guī)范中對(duì)本地方法棧中方法使用的語(yǔ)言、使用方式與數(shù)據(jù)結(jié)構(gòu)并沒(méi)有強(qiáng)制規(guī)定，因此具體的虛擬機(jī)可以自由實(shí)現(xiàn)它。甚至有的虛擬機(jī)（譬如Sun HotSpot虛擬機(jī)）直接就把本地方法棧和虛擬機(jī)棧合二為一。與虛擬機(jī)棧一樣，本地方法棧區(qū)域也會(huì)拋出StackOverflowError和OutOfMemoryError異常。

程序計(jì)數(shù)器（Program Counter Register）是一塊較小的內(nèi)存空間。是線(xiàn)程私有的。它可以看作是當(dāng)前線(xiàn)程所執(zhí)行的字節(jié)碼的行號(hào)指示器。什么意思呢？

白話(huà)版本：因?yàn)榇a是在線(xiàn)程中運(yùn)行的，線(xiàn)程有可能被掛起。即CPU一會(huì)執(zhí)行線(xiàn)程A，線(xiàn)程A還沒(méi)有執(zhí)行完被掛起了，接著執(zhí)行線(xiàn)程B，最后又來(lái)執(zhí)行線(xiàn)程A了，CPU得知道執(zhí)行線(xiàn)程A的哪一部分指令，線(xiàn)程計(jì)數(shù)器會(huì)告訴CPU。

由于Java虛擬機(jī)的多線(xiàn)程是通過(guò)線(xiàn)程輪流切換并分配處理器執(zhí)行時(shí)間的方式來(lái)實(shí)現(xiàn)的，CPU 只有把數(shù)據(jù)裝載到寄存器才能夠運(yùn)行。寄存器存儲(chǔ)指令相關(guān)的現(xiàn)場(chǎng)信息，由于CPU 時(shí)間片輪限制，眾多線(xiàn)程在并發(fā)執(zhí)行過(guò)程中，任何一個(gè)確定的時(shí)刻，一個(gè)處理器或者多核處理器中的一個(gè)內(nèi)核，只會(huì)執(zhí)行某個(gè)線(xiàn)程中的一條指令。

因此，為了線(xiàn)程切換后能恢復(fù)到正確的執(zhí)行位置，每條線(xiàn)程都需要有一個(gè)獨(dú)立的程序計(jì)數(shù)器，各條線(xiàn)程之間計(jì)數(shù)器互不影響，獨(dú)立存儲(chǔ)。每個(gè)線(xiàn)程在創(chuàng)建后，都會(huì)產(chǎn)生自己的程序計(jì)數(shù)器和棧幀，程序計(jì)數(shù)器用來(lái)存放執(zhí)行指令的偏移量和行號(hào)指示器等，線(xiàn)程執(zhí)行或恢復(fù)都要依賴(lài)程序計(jì)數(shù)器。此區(qū)域也不會(huì)發(fā)生內(nèi)存溢出異常。

直接內(nèi)存（Direct Memory）并不是虛擬機(jī)運(yùn)行時(shí)數(shù)據(jù)區(qū)的一部分，也不是Java虛擬機(jī)規(guī)范中定義的內(nèi)存區(qū)域。但是這部分內(nèi)存也被頻繁地使用，而且也可能導(dǎo)致OutOfMemoryError異常出現(xiàn)，所以我們放到這里一起講解。

在JDK 1.4中新加入了NIO（New Input/Output）類(lèi)，引入了一種基于通道（Channel）與緩沖區(qū)（Buffer）的I/O方式，它可以使用Native函數(shù)庫(kù)直接分配堆外內(nèi)存，然后通過(guò)一個(gè)存儲(chǔ)在Java堆中的DirectByteBuffer對(duì)象作為這塊內(nèi)存的引用進(jìn)行操作。這樣能在一些場(chǎng)景中顯著提高性能，因?yàn)?strong>避免了在Java堆和Native堆中來(lái)回復(fù)制數(shù)據(jù)。

顯然，本機(jī)直接內(nèi)存的分配不會(huì)受到Java堆大小的限制，但是，既然是內(nèi)存，肯定還是會(huì)受到本機(jī)總內(nèi)存（包括RAM以及SWAP區(qū)或者分頁(yè)文件）大小以及處理器尋址空間的限制。如果內(nèi)存區(qū)域總和大于物理內(nèi)存的限制，也會(huì)出現(xiàn)OOM。

簡(jiǎn)而言之， JVM代碼緩存是JVM將其字節(jié)碼存儲(chǔ)為本機(jī)代碼的區(qū)域 。我們將可執(zhí)行本機(jī)代碼的每個(gè)塊稱(chēng)為 nmethod 。該 nmethod可能是一個(gè)完整的或內(nèi)聯(lián)Java方法。

實(shí)時(shí)（JIT）編譯器是代碼緩存區(qū)域的最大消費(fèi)者。這就是為什么一些開(kāi)發(fā)人員將此內(nèi)存稱(chēng)為JIT代碼緩存的原因。

這部分代碼所占用的內(nèi)存空間成為CodeCache區(qū)域。一般情況下我們是不會(huì)關(guān)心這部分區(qū)域的且大部分開(kāi)發(fā)人員對(duì)這塊區(qū)域也不熟悉。如果這塊區(qū)域OOM了，在日志里面就會(huì)看到 java.lang.OutOfMemoryErrorcode cache。