內存管理機制-內存分配策略

 

 

RoadMap

 

 

對象優先在Eden分配

        大多數狀況下，對象在新生代Eden區中分配。當Eden區沒有足夠空間進行分配時，虛擬機將發起一次Minor GC。 虛擬機提供了-XX：+PrintGCDetails這個收集器日誌參數，告訴虛擬機在發生垃圾收集行爲時打印內存回收日誌，而且在進程退出的時候輸出當前的內存各區域分配狀況。在實際應用中，內存回收日誌通常是打印到文件後經過日誌工具進行分析，不過本實驗的日誌並很少，直接閱讀就能看得很清楚。

        新生代GC（Minor GC）：指發生在新生代的垃圾收集動做，由於Java對象大多都具有朝生夕滅的特性，因此Minor GC很是頻繁，通常回收速度也比較快。

        老年代GC（Major GC/Full GC）：指發生在老年代的GC，出現了Major GC，常常會伴隨至少一次的Minor GC（但非絕對的，在Parallel Scavenge收集器的收集策略裏就有直接進行Major GC的策略選擇過程）。Major GC的速度通常會比Minor GC慢10倍以上。

 

大對象直接進入老年代

        所謂的大對象是指，須要大量連續內存空間的Java對象，最典型的大對象就是那種很長的字符串以及數組（筆者列出的例子中的byte[]數組就是典型的大對象）。大對象對虛擬機的內存分配來講就是一個壞消息（替Java虛擬機抱怨一句，比遇到一個大對象更加壞的消息就是遇到一羣「朝生夕滅」的「短命大對象」，寫程序的時候應當避免），常常出現大對象容易致使內存還有很多空間時就提早觸發垃圾收集以獲取足夠的連續空間來「安置」它們。 虛擬機提供了一個-XX：PretenureSizeThreshold參數，令大於這個設置值的對象直接在老年代分配。這樣作的目的是避免在Eden區及兩個Survivor區之間發生大量的內存複製

 

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

        既然虛擬機採用了分代收集的思想來管理內存，那麼內存回收時就必須能識別哪些對象應放在新生代，哪些對象應放在老年代中。爲了作到這點，虛擬機給每一個對象定義了一個對象年齡（Age）計數器。若是對象在Eden出生並通過第一次Minor GC後仍然存活，而且能被Survivor容納的話，將被移動到Survivor空間中，而且對象年齡設爲1。對象在Survivor區中每「熬過」一次Minor GC，年齡就增長1歲，當它的年齡增長到必定程度（默認爲15歲），就將會被晉升到老年代中。對象晉升老年代的年齡閾值，能夠經過參數-XX：MaxTenuringThreshold設置。

動態對象年齡斷定

    爲了能更好地適應不一樣程序的內存情況，虛擬機並非永遠地要求對象的年齡必須達到了MaxTenuringThreshold才能晉升老年代，若是在Survivor空間中相同年齡全部對象大小的總和大於Survivor空間的一半，年齡大於或等於該年齡的對象就能夠直接進入老年代，無須等到MaxTenuringThreshold中要求的年齡。

 

空間分配擔保

 

    在發生Minor GC以前，虛擬機會先檢查老年代最大可用的連續空間是否大於新生代全部對象總空間，若是這個條件成立，那麼Minor GC能夠確保是安全的。若是不成立，則虛擬機會查看HandlePromotionFailure設置值是否容許擔保失敗。

    若是容許，那麼會繼續檢查老年代最大可用的連續空間是否大於歷次晉升到老年代對象的平均大小，若是大於，將嘗試着進行一次Minor GC，儘管此次Minor GC是有風險的；若是小於，或者HandlePromotionFailure設置不容許冒險，那這時也要改成進行一次Full GC。

    下面解釋一下「冒險」是冒了什麼風險，前面提到過，新生代使用複製收集算法，但爲了內存利用率，只使用其中一個Survivor空間來做爲輪換備份，所以當出現大量對象在Minor GC後仍然存活的狀況（最極端的狀況就是內存回收後新生代中全部對象都存活），就須要老年代進行分配擔保，把Survivor沒法容納的對象直接進入老年代。

    與生活中的貸款擔保相似，老年代要進行這樣的擔保，前提是老年代自己還有容納這些對象的剩餘空間，一共有多少對象會活下來在實際完成內存回收以前是沒法明確知道的，因此只好取以前每一次回收晉升到老年代對象容量的平均大小值做爲經驗值，與老年代的剩餘空間進行比較，決定是否進行Full GC來讓老年代騰出更多空間。 取平均值進行比較其實仍然是一種動態機率的手段，也就是說，若是某次Minor GC存活後的對象突增，遠遠高於平均值的話，依然會致使擔保失敗（Handle Promotion Failure）。若是出現了HandlePromotionFailure失敗，那就只好在失敗後從新發起一次Full GC。雖然擔保失敗時繞的圈子是最大的，但大部分狀況下都仍是會將HandlePromotionFailure開關打開，避免Full GC過於頻繁。