JVM 運行時內存分代結構
對于Java應用程序來說，Java堆(Java Heap)是虛擬機所管理的內存中最大的一塊。Java堆是被所有線程共享的一塊內存區域，在虛擬機啟動時創建。此內存區域的唯一目的就是存放對象實例，所有的對象實例都在這里分配內存。
Java堆是垃圾收集器管理的內存區域。從回收內存的角度看，由于大部分垃圾收集器大部分都是基于分代收集理論設計的，所以 Java 堆中經常會出現“新生代”“老年代”“永久代”“Eden空間”“From Survivor空 間”“To Survivor空間”等區域。這些區域劃分僅僅是一部分垃圾收集器的共同特性或者說設計風格而已，而非某個Java虛擬機具體實現的固有內存布局，不是《Java虛擬機規范》里對Java堆的官方的定義。比如：Shenandoah、ZGC 就不支持分代。
JDK 1.7 分代結構
在 JDK 1.7 以及之前堆空間分為 3 部分：新生代，老年代，永久代。然后新生代分為：Eden 區， 和兩個 Survivor 區。如下圖所示
JDK 1.8 分代結構
在 JDK 1.8 及其以后，堆空間中移除了永久代。為什么刪除永久代的緣由可以閱讀以下文檔：http://openjdk.java.net/jeps/122。其核心原因主要有以下幾點：這是 Hotspot 和 JRockit 虛擬機融合。JRockit 客戶不需要配置永久代(因為JRockit 沒有永久代)，習慣不配置永久代。增加元空間解決類加載所需要的內存空間，而且元空間默認是自動拓容的。這樣減少內存溢出的可能。堆空間移除永久代過后，堆空間的結構如下圖所示：
運行時數據區結構如下圖所示：
G1 收集器
G1將新生代，老年代的物理空間劃分取消了。取而代之的是，G1算法將堆劃分為若干個區域(Region)，它仍然屬于分代收集器。不過，這些區域的一部分包含新生代，新生代的垃圾收集依然采用暫停所有應用線程的方式，將存活對象拷貝到老年代或者Survivor空間。老年代也分成很多區域，G1收集器通過將對象從一個區域復制到另外一個區域，完成了清理工作。這就意味著，在正常的處理過程中，G1完成了堆的壓縮(至少是部分堆的壓縮)，這樣也就不會有cms內存碎片問題的存在了。
在G1中，還有一種特殊的區域，叫Humongous區域。如果一個對象占用的空間超過了分區容量50%以上，G1收集器就認為這是一個巨型對象。這些巨型對象，默認直接會被分配在年老代，但是如果它是一個短期存在的巨型對象，就會對垃圾收集器造成負面影響。為了解決這個問題，G1劃分了一個Humongous區，它用來專門存放巨型對象。如果一個H區裝不下一個巨型對象，那么G1會尋找連續的H分區來存儲。為了能找到連續的H區，有時候不得不啟動Full GC。
對象內存分配
對象內存分配過程如下：
下面是具體的幾種內存分配規則描述
對象優先分配在 Eden 區
大多數情況下，對象在新生代 Eden 區中分配。當Eden區沒有足夠空間進行分配時，虛擬機將發起一次 Minor GC。HotSpot虛擬機提供了-XX:+PrintGCDetails 這個收集器日志參數，告訴虛擬機在發生垃圾收集行為時打印內存回收日志，并且在進程退出的時候輸出當前的內存各區域分配情況。測試代碼：
- /**
- * -XX:+PrintGCDetails
- */
- public class GCTest {
- public static void main(String[] args) {
- byte[] allcation2 = new byte[8000 * 1024];
- }
- }
輸出結果
- Heap
- PSYoungGen total 38400K, used 11353K [0x0000000795580000, 0x0000000798000000, 0x00000007c0000000)
- eden space 33280K, 34% used [0x0000000795580000,0x00000007960966f8,0x0000000797600000)
- from space 5120K, 0% used [0x0000000797b00000,0x0000000797b00000,0x0000000798000000)
- to space 5120K, 0% used [0x0000000797600000,0x0000000797600000,0x0000000797b00000)
- ParOldGen total 87552K, used 0K [0x0000000740000000, 0x0000000745580000, 0x0000000795580000)
- object space 87552K, 0% used [0x0000000740000000,0x0000000740000000,0x0000000745580000)
- Metaspace used 3017K, capacity 4556K, committed 4864K, reserved 1056768K
- class space used 319K, capacity 392K, committed 512K, reserved 1048576K
我們可以通過內存空間的分布可以看出 allcation2 是被分配到 eden 區中的。
大對象直接進入老年代
大對象就是指需要大量連續內存空間的Java對象(比如：字符串、數組)，JVM 參數 -XX:PretenureSizeThreshold 參數可以設置大對象的大小，指定大于該設置值的對象直接在老年代分配，不會進入年輕代，這個參數只有在 Serial 和 ParNew 兩個收集器下有效。比如設置：JVM 參數：-XX:PretenureSizeThreshold=1000000(單位直接)-XX:+UseSerialGC, 在執行上面的第一個程序就會發現大對象直接進入了老年代。這樣做的目的就是避免在Eden區及兩個Survivor區之間來回復制，產生大量的內存復制操作。
長期存活的對象將進入老年代
HotSpot虛擬機中多數收集器都采用了分代收集來管理堆內存，那內存回收時就必須能決策哪些存活對象應當放在新生代，哪些存活對象放在老年代中。為做到這點，虛擬機給每個對象定義了一個對象年齡(Age)計數器，存儲在對象頭中。對象通常在Eden區里誕生，如果經過第一次 Minor GC 后仍然存活，并且能被 Survivor 容納的話，該對象會被移動到 Survivor 空間中，并且將其對象年齡設為1歲。對象在Survivor區中每熬過一次Minor GC，年齡就增加1歲，當它的年齡增加到一定程度(默認為15)，就會被晉升到老年代中。對象晉升老年代的年齡閾值，可以通過參數 -XX:MaxTenuringThreshold 設置。
動態對象年齡判斷
為了能更好地適應不同程序的內存狀況，HotSpot 虛擬機并不是永遠要求對象的年齡必須達到 -XX:MaxTenuringThreshold 才能晉升老年代，如果在 Survivor 空間中相同年齡所有對象大小的總和大于 Survivor 空間的一半，年齡大于或等于該年齡的對象就可以直接進入老年代，無須等到 -XX:MaxTenuringThreshold 中要求的年齡。
空間分配擔保
在發生 Minor GC 之前，虛擬機必須先檢查老年代最大可用的連續空間是否大于新生代所有對象總空間。
本文轉載自微信公眾號「運維開發故事」
【編輯推薦】
