JVM在进行GC时候，并非每次都对上面三个内存区域一起回收，大部分时间回收都是指新生代
针对HotSpot VM的实现，它里面的GC按照回收区域又分为两大种类型，一种是部分收集(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区域来回收的，会涉及到新生代和老年代
整堆收集(Full GC)：收集整个Java堆和方法区的垃圾收集
年轻代GC(Minor GC)触发机制
1.当年轻代空间不足时，就会触发Minor GC，这里的年轻代满指的是Eden代满，Survivor满不会引发GC，每次Minor GC会清理年轻代的内存
2.因为Java对象大多具备朝生夕死的特性，所以Minor GC 非常频繁，一般回收速度也很快
Minor GC 会引发STW(stop the world)，暂停其他用户的线程，等垃圾回收结束，用户线程才会恢复运行
老年代GC(Major GC / Full GC)触发机制
1.出现了Major GC 经常会伴随至少一次的Minor GC(但非绝对的，在Parallel Scavenge收集器的收集策略里就有直接进行Major GC的策略选择过程),也就是说老年代空间不足时，会先尝试触发Minor GC 如果之后空间还不足，触发Major GC
2.Major GC的速度一般要比Minor GC 满十倍以上，STW的时间更长
3.如果Major GC 后，内存还不足，oom错误
Full GC 触发机制
1.调用System.gc()，系统建议Full GC ，不一定执行
2.老年代空间不足
3.方法区空间不足
4.通过Minor GC后进入老年代的平均大小大于老年代的可用内存
5.由Eden区，from区向to区复制时，对象大小大于to区可用内存，则把对象转存到老年代，且老年代的可用内存小于这些对象的大小
Full GC 是开发调优中要尽量避免的
总结 内存分配策略
针对不同年龄段的对象分配的原则如下所示
1.优先分配eden区
2.大对象直接分配到老年代
尽量避免程序中出现过多的大对象
3.长期存活的对象分配到老年代
4.动态对象年龄判断
如果Survivor区中相同年龄的所有对象大小的总和大于Survivor空间的一半，则年龄大于或者等于该年龄的对象可以直接进入老年代，无需等到MaxTenuringThreshold中要求的年龄
5.空间分配担保
