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