JVM快速調優手冊之三: 內存分配策略

    了解GC其中很重要一點就是了解JVM的內存分配策略：即對象在哪里分配和對象什么時候回收。

    Java技術體系中所提倡的自動內存管理可以歸結于兩個部分：給對象分配內存以及回收分配給對象的內存。

    我們都知道，Java對象分配，都是在Java堆上進行分配的，雖然存在JIT編譯后被拆分為標量類型并簡介地在棧上進行分配。如果采用分代算法，那么新生的對象是分配在新生代的Eden區上的。如果啟動了本地線程分配緩沖，將按線程優先在TLAB上進行分配。

    事實上，Java的分配規則不是百分百固定的，其取決于當前使用的是哪一種垃圾收集器組合，還有虛擬機中與內存相關的參數的設置。

    簡單來說，對象內存分配主要是在堆中分配。但是分配的規則并不是固定的，取決于使用的收集器組合以及JVM內存相關參數的設定。

    下面Serial和Serial Old收集器做一個內存分配和回收的策略總結。

對象優先在新生代Eden分配

首先，讓我們來看一下新生代的內存分配情況

內存分配情況：將JVM內存劃分為一塊較大的Eden空間（80%）和兩塊小的Servivor（各占10%）。當回收時，將Eden和Survivor中還存活的對象一次性采用復制算法直接復制到另外一塊Servivor空間上，最后清理到院Eden空間和原先的Survivor空間中的數據。

大多數情況下，對象在新生代Eden區中分配。當Eden區沒有足夠空間進行分配時，JVM將發起一次Minor GC。
在這里先說明兩個概念：

• 新生代GC（Minor GC）：指發生在新生代的垃圾收集動作，因為Java對象大多是具有朝生夕滅的特性，所以Minor GC非常頻繁，而且該速度也比較快。
• 老年代GC（Major GC/Full GC）：指發生在老年代的GC，出現了Major GC，一般可能也會伴隨著一次Minor GC，但是與Minor GC不同的是，Major GC的速度慢十倍以上。

大對象直接進入老年代

我們先對所謂的大對象做一個定義：大對象，這里指的是需要大量連續內存空間的Java對象。最典型的大對象可以是很長的字符串和數組。

JVM對大對象的態度：大對象對于JVM的內存分配來說是十分麻煩的，如果我們將大對象分配在新生代中，那樣子的話很容易導致內存還有不少空間時就提前觸發垃圾收集以獲取足夠的連續空間來“安置”它們。

為了避免上述情況的經常發生而導致不需要的GC活動所浪費的資源和時間，可采用的分配策略是將大對象直接分配到老年代中去，虛擬機中也提供了**-XX:PretenureSizeThreshold**參數，令大于這個設置值的對象直接在老年代里面分配內容。

-XX:PretenureSizeThreshold只對Serial和ParNew收集器有效。

長期存活的對象將進入老年代

當JVM采用分代收集的思想來管理內存時，為了識別哪些對象應該放在新生代、哪些對象應該放在老年代，JVM給每個對象定義了一個對象年齡計數器。

對象年齡計數器：如果對象在Eden出生并經過第一次Minor GC后仍然存活，并且能被Survivor容納的話，便可以被移動到Survivor空間中，年齡計數器將設置該對象的年齡為1.對于對象在Survivor區每經過一次Minor GC，年齡便增加1歲，當它的年齡增加到一定程度（可通過參數-XX:MaxTenuringThreshold設置）默認15，該對象便會進入到老年代中。成為老年代的對象。

動態對象年齡判定

事實上，有的虛擬機并不永遠地要求對象的年齡必須達到MaxTeruringThreshold才能晉升老年代，如果在Survivor空間中相同年齡所有對象大小的總和大于Surivior空間的一半，年齡大于或等于該年齡的對象就可以直接進行老年代，無須等到MaxTeruringThreshold中所要求的年齡。

空間分配擔保

在發生Minor GC之前，虛擬機會先檢查老年代中最大的可用的連續空間是否大于新生代中所有對象總空間，如果這個條件成立，那么Minor GC可以確保是安全的，如果不成立，則虛擬機會查看HandlePromotionFaiure設置值是否允許擔保失敗。如果允許，那么會繼續檢查老年代最大可用的連續空間是否大于歷次晉升到老年代對象的平均大小，如果大于，將嘗試進行一次Minor GC，盡管這次GC是有風險的；如果小于，或者HandlePromotionFaiure設置不允許冒險，那么這時就要改為進行一次Full GC。

所謂冒險：也就是說當用來輪轉的Survivor區無法承受新生代中所存活的對象內存時，需要老年代進行分配擔保，把Survivor無法容納的對象直接進入老年代中，前提是老年代中。