GC流程是每一个Java开发人员都应该掌握的内容。你知道什么时候触发Minor GC？什么时候触发
Minor GC 的过程是怎么样的？Full GC 的过程又是怎么样的？这一切都要从「压死骆驼的最后一根稻草」说起。
**看图，看图，看图。**跟着我画的流程图走一遍，就清楚了！
# 挤满新生代的最后一个对象
我们应当知道，新创建的对象一般会被分配在新生代中。常用的新生代的垃圾回收器是 ParNew 垃圾回收器，它按照 8:1:1 将新生代分成 Eden 区，以及两个 Survivor 区。
某一时刻，我们创建的对象将 Eden 区全部挤满，这个对象就是「挤满新生代的最后一个对象」。此时，Minor GC 就触发了。
# 正式 Minor GC 前的检查
在正式 Minor GC 前，JVM 会先检查新生代中对象，是比老年代中剩余空间大还是小。**为什么要做这样的检查呢？**原因很简单，假如 Minor GC 之后 Survivor 区放不下剩余对象，这些对象就要进入到老年代，所以要提前检查老年代是不是够用。这样就有两种情况：
1. 老年代剩余空间大于新生代中的对象大小，那就直接 Minor GC，GC 完 survivor 不够放，老年代也绝对够放
2. 老年代剩余空间小于新生代中的对象大小，这个时候就要查看是否启用了「老年代空间分配担保规则」，具体来说就是看`-XX:-HandlePromotionFailure`参数是否设置了（一般都会设置）
老年代空间分配担保规则是这样的。如果老年代中剩余空间大小，大于历次 Minor GC 之后剩余对象的大小，那就允许进行 Minor GC。因为从概率上来说，以前的放的下，这次的也应该放的下。那就有两种情况：
1. 老年代中剩余空间大小，大于历次 Minor GC 之后剩余对象的大小，进行 Minor GC
2. 老年代中剩余空间大小，小于历次 Minor GC 之后剩余对象的大小，进行 Full GC，把老年代空出来再检查
# Minor GC 后的处境
前面说了，开启**老年代空间分配担保规则**只能说是大概率上来说，Minor GC 剩余后的对象够放到老年代，所以当然也会有万一，Minor GC 后会有这样三种情况：
1. Minor GC 之后的对象足够放到 Survivor 区，皆大欢喜，GC 结束
2. Minor GC 之后的对象不够放到 Survivor 区，接着进入到老年代，老年代能放下，那也可以，GC 结束
3. Minor GC 之后的对象不够放到 Survivor 区，老年代也放不下，那就只能 Full GC
# 实在不行只能 OOM
前面都是成功 GC 的例子，还有 3 中情况，会导致 GC 失败，报 OOM：
1. 紧接上一节 Full GC 之后，老年代任然放不下剩余对象，就只能 OOM
2. 未开启老年代分配担保机制，且一次 Full GC 后，老年代任然放不下剩余对象，也只能 OOM
3. 开启老年代分配担保机制，但是担保不通过，一次 Full GC 后，老年代任然放不下剩余对象，也是能 OOM