Java記憶體管理：分配與回收策略詳解

表3-4　垃圾收集相關的常用參數    加上-XX: UseSerialGC

物件的記憶體分配，從概念上講，應該都是在堆上分配（而實際上也有可能經過即時編譯後被拆散為標量類型並間接地在堆疊上分配[1] ）。在經典分代的設計下，新生物件通常會分配在新生代中，少數情況下（例如物件大小超過一定閾值）也可能會直接分配在老年代。物件分配的規則並不是固定的，《Java虛擬機器規格》並未規定新物件的建立和儲存細節，這取決於虛擬機器目前使用的是哪一種垃圾收集器，以及虛擬機器中與記憶體相關的參數的設定。

物件優先在Eden分配

大多數情況下，物件在新生代Eden區中分配。當Eden區沒有足夠空間進行分配時，虛擬機器將發起一次Minor GC。

大物件直接進入老年代

大物件就是指需要大量連續記憶體空間的Java對象，最典型的大物件就是那種很長的字符串，或元素數量很龐大的數組，本節例子中的byte[]數組就是典型的大物件。大物件對虛擬機器的記憶體分配來說就是一個不折不扣的壞消息，比遇到一個大物件更加壞的消息就是遇到一群“朝生夕滅”的“短命大物件”，我們寫程式的時候應注意避免。

Java虛擬機器中要避免大物件的原因是，在分配空間時，它容易導致內存明明還有不少空間時就提前觸發垃圾收集，以獲取足夠的連續空間才能安置好它們，而當複

制物件時，大物件就意味著高額的記憶體複製開銷。 HotSpot虛擬機器提供了-XX：PretenureSizeThreshold參數，指定大於該設定值的物件直接在老年代分配，這樣做的目的就是避免在Eden區及兩個Survivor區之間來回復制，產生大量的記憶體複製操作。

-XX：PretenureSizeThreshold參數只對Serial和ParNew兩款新生代收集器有效，HotSpot的其他新生代收集器，如Parallel Scavenge並不支援這個參數。如果必須使用此參數進行調優，可考慮ParNew加CMS的收集器組合。

長期存活的物件將進入老年代

虛擬機為每個物件定義了一個物件年齡（Age）計數器，儲存在物件頭中，每熬過一次Minor GC，年齡就增加1歲，當它的年齡增加到一定程

度（預設為15），就會晉升到老年代。物件晉升老年代的年齡閾值，可以透過參數-XX：MaxTenuringThreshold設定。

動態物件年齡判定

為了能更好地適應不同程式的記憶體狀況，HotSpot虛擬機並不是永遠要求物件的年齡必須達到-XX：MaxTenuringThreshold才能晉升老年代，如果在Survivor空間中相同年齡所有物件大小的總和大於Survivor空間的一半，年齡大於或等於該年齡的物件就可以直接進入老年代，無須等到-XX：MaxTenuringThreshold中要求的年齡。

空間分配擔保

在發生Minor GC之前，虛擬機器必須先檢查老年代最大可用的連續空間是否大於新生代所有物件總空間，如果這個條件成立，那這次Minor GC可以確保是安全的。如果不成立，則虛擬機會先查看-XX：HandlePromotionFailure參數的設定值是否允許擔保失敗（Handle Promotion Failure）；如果允許，那會繼續檢查老年代最大可用的連續空間是否大於歷次晉升到老年代對象的平均大小，如果大於，將嘗試進行一次Minor GC，儘管這次Minor GC是有風險的；如果小於，或者-XX：HandlePromotionFailure設定不允許冒險，那麼這時就要改為進行一次Full GC。

在JDK 6 Update 24之後，這個測試結果就有了差異，-XX：HandlePromotionFailure參數不會再影響到虛擬機器的空間分配擔保策略，觀察OpenJDK中的源碼變化（見代碼清單3 -12），雖然原始碼中也定義了-XX：HandlePromotionFailure參數，但在實際虛擬機器中已經不會再使用它。 JDK 6 Update 24之後的規則變成只要老年代的連續空間大於新生代物件總大小或歷次晉升的平均大小，就會進行Minor GC，否則將進行Full GC。

以上是Java記憶體管理：分配與回收策略詳解的詳細內容。更多資訊請關注PHP中文網其他相關文章！