JVM在進行GC時候，并非每次都對上面三個內(nèi)存區(qū)域一起回收，大部分時間回收都是指新生代

針對HotSpot VM的實現(xiàn)，它里面的GC按照回收區(qū)域又分為兩大種類型，一種是部分收集(Partial GC)，一種是整堆收集(Full GC)

部分收集:不是完整收集整個Java堆的垃圾收集，其中又分為

1.新生代收集(Minor GC / Young GC) ：只是新生代的垃圾收集

2.老年代收集(Major GC / Old GC) ：只是老年代的垃圾收集

? ? ? 目前，只有CMS GC 會有單獨收集老年代的行為

? ? ? 注意，很多時候Major GC會和Full GC混淆使用，需要具體分辨是老年代回收還是整堆回收

3.混合收集(Mixed GC):收集整個新生代以及部分老年代的垃圾收集

? ? ? 目前，只有G1 GC會有這種行為，因為他是劃分為 region區(qū)域來回收的，會涉及到新生代和老年代

整堆收集(Full GC)：收集整個Java堆和方法區(qū)的垃圾收集

年輕代GC(Minor GC)觸發(fā)機制

1.當年輕代空間不足時，就會觸發(fā)Minor GC，這里的年輕代滿指的是Eden代滿，Survivor滿不會引發(fā)GC，每次Minor GC會清理年輕代的內(nèi)存

2.因為Java對象大多具備朝生夕死的特性，所以Minor GC 非常頻繁，一般回收速度也很快?

Minor GC 會引發(fā)STW(stop the world)，暫停其他用戶的線程，等垃圾回收結(jié)束，用戶線程才會恢復(fù)運行

老年代GC(Major GC / Full GC)觸發(fā)機制

1.出現(xiàn)了Major GC 經(jīng)常會伴隨至少一次的Minor GC(但非絕對的，在Parallel Scavenge收集器的收集策略里就有直接進行Major GC的策略選擇過程),也就是說老年代空間不足時，會先嘗試觸發(fā)Minor GC 如果之后空間還不足，觸發(fā)Major GC

2.Major GC的速度一般要比Minor GC 滿十倍以上，STW的時間更長

3.如果Major GC 后，內(nèi)存還不足，oom錯誤

Full GC 觸發(fā)機制

1.調(diào)用System.gc()，系統(tǒng)建議Full GC ，不一定執(zhí)行

2.老年代空間不足

3.方法區(qū)空間不足

4.通過Minor GC后進入老年代的平均大小大于老年代的可用內(nèi)存

5.由Eden區(qū)，from區(qū)向to區(qū)復(fù)制時，對象大小大于to區(qū)可用內(nèi)存，則把對象轉(zhuǎn)存到老年代，且老年代的可用內(nèi)存小于這些對象的大小

Full GC 是開發(fā)調(diào)優(yōu)中要盡量避免的

總結(jié) 內(nèi)存分配策略

針對不同年齡段的對象分配的原則如下所示

1.優(yōu)先分配eden區(qū)

2.大對象直接分配到老年代

? ?盡量避免程序中出現(xiàn)過多的大對象

3.長期存活的對象分配到老年代

4.動態(tài)對象年齡判斷

? ? 如果Survivor區(qū)中相同年齡的所有對象大小的總和大于Survivor空間的一半，則年齡大于或者等于該年齡的對象可以直接進入老年代，無需等到MaxTenuringThreshold中要求的年齡

5.空間分配擔(dān)保