Java虛擬機的內存分配策略是怎樣的，很多新手對此不是很清楚，為了幫助大家解決這個難題，下面小編將為大家詳細講解，有這方面需求的人可以來學習下，希望你能有所收獲。
Java技術體系中的自動內存管理可以歸結為自動化的解決了兩個問題：給對象分配內存和回收分配給對象的內存。
對象的內存分分配主要是指堆上分配（也可棧上分配），對象主要分配在新生代Eden區，如果啟動了本地線程分配緩沖，則按照線程優先在TLAB上分配。少數情況下也會直接分配在老年代，分配的規則不固定，取決于垃圾回收器組合以及JVM中與內存相關參數的設置。
我們以Serial/Serial Old收集器為例進行介紹。
大多數情況下，對象在新生代的Eden區中分配，當Eden區沒有足夠空間進行分配時，虛擬機將會發起一次Minor GC。
大對象是指需要大量連續內存空間的Java對象，典型大對象有長字符串和數組，大對象對虛擬機的內存分配來說是一個壞消息，寫程序時還要避免創建一些朝生夕死的短命大對象，經常出現大對象容易導致內存還有不少空間時就提前觸發垃圾收集以獲取足夠的連續空間來安置他們。
虛擬機提供-XX:PretenureSizeThreshold參數，令大于這個設置值的對象直接在老年代分配，這樣避免再Eden及兩個Survivor區間發生大量的內存復制，這個參數只對Serial和ParNew兩款收集器有效，如果遇到必須使用此參數的場合，可以考慮ParNew加CMS的組合。
大對象直接在老年代進行分配的目的是避免在Eden區和兩個Survivor區之間發生大量的內存復制。
虛擬機給每個對象定義了一個對象年齡計數器，如果對象在Eden出生并經過第一次Minor GC后仍然存活，并且能被Survivor容納的話，將被移動到Survivor空間中，并且對象年齡設為1，對象在Survivor區中每熬過一次Minor GC，年齡就增加1歲，當它的年齡增加到一定程度（默認為15歲），就會被晉升到老年代中，可以通過-XX:MaxTenuringThreshold參數來設置年齡閾值。
為了能更好的適應不同程序的內存情況，虛擬機不是永遠的要求對象的年齡必須達到閾值才能晉升老年代；如果在Survivor區中的相同年齡所有對象大小的總和大于Survivor空間的一半，年齡大于或者等于該年齡的對象就可以直接進入老年代，無須等到-XX:MaxTenuringThreshold 中要求的年齡。
關于分配擔保機制JDK6前后有差別的。
當發生Minor GC時，JVM會首先檢查老年代最大的可用連續空間是否大于新生代所有對象的總和，如果大于，那么這次Minor GC是安全的，如果不大于的話，JVM就需要判斷HandlePromotionFailure是否允許空間分配擔保。
如果允許擔保失敗，那么JVM會繼續檢查老年代最大的可用連續空間是否大于歷次晉升到老年代的對象的平均大?。?/p>
如果大于，則正常進行一次YGC，盡管有風險（因為判斷的是平均大小，有可能這次的晉升對象比平均值大很多）；
如果小于，或者HandlePromotionFailure設置不允許空間分配擔保，這時要進行一次FGC。
對以上的步驟歸納一下，先看老年代的可用空間能否容下新生代的所有對象，不能的話看是否開啟了分配擔保機制，允許就先執行Minor GC，否則直接進行Full GC。大部分情況下還是會將HandlePromotionFailure開啟分配擔保，避免頻繁Full GC。
HandlePromotionFailure不再影響到虛擬機的空間分配擔保策略，變為只要老年代的連續空間大于新生代對象總大小或歷次晉升的平均大小就會進行Minor GC，否則將進行Full GC。
Minor GC和Major GC/Full GC:
新生代GC(Minor GC：縮寫YGC，指發生在新生代的垃圾回收動作，因為Java對象大多都具備朝生夕滅的特性，所以Monir GC非常頻繁，一般回收速度也比較快。
老年代GC(Major GC/Full GC)：指發生在老年代的GC，出現了Major GC，經常會伴隨至少一次的Minor GC(但并非絕對的，在Parallel Scavenge)收集器的收集策略里就有直接進行Major GC的策略選擇過程。Major GC的速度一般比Major GC慢10倍以上。
看完上述內容是否對您有幫助呢？如果還想對相關知識有進一步的了解或閱讀更多相關文章，請關注億速云行業資訊頻道，感謝您對億速云的支持。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
