原文地址: https://www.cnblogs.com/shuiyj/p/12640692.html
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 区放不下剩余对象,这些对象就要进入到老年代,所以要提前检查老年代是不是够用。这样就有两种情况:
-
老年代剩余空间大于新生代中的对象大小,那就直接 Minor GC,GC 完 survivor 不够放,老年代也绝对够放
-
老年代剩余空间小于新生代中的对象大小,这个时候就要查看是否启用了「老年代空间分配担保规则」,具体来说就是看-XX:-HandlePromotionFailure参数是否设置了(一般都会设置)
老年代空间分配担保规则是这样的。如果老年代中剩余空间大小,大于历次 Minor GC 之后剩余对象的大小,那就允许进行 Minor GC。因为从概率上来说,以前的放的下,这次的也应该放的下。那就有两种情况: -
老年代中剩余空间大小,大于历次 Minor GC 之后剩余对象的大小,进行 Minor GC
-
老年代中剩余空间大小,小于历次 Minor GC 之后剩余对象的大小,进行 Full GC,把老年代空出来再检查
Minor GC 后的处境
前面说了,开启老年代空间分配担保规则只能说是大概率上来说,Minor GC 剩余后的对象够放到老年代,所以当然也会有万一,Minor GC 后会有这样三种情况:
- Minor GC 之后的对象足够放到 Survivor 区,皆大欢喜,GC 结束
- Minor GC 之后的对象不够放到 Survivor 区,接着进入到老年代,老年代能放下,那也可以,GC 结束
- Minor GC 之后的对象不够放到 Survivor 区,老年代也放不下,那就只能 Full GC
实在不行只能 OOM
前面都是成功 GC 的例子,还有 3 中情况,会导致 GC 失败,报 OOM:
- 紧接上一节 Full GC 之后,老年代任然放不下剩余对象,就只能 OOM
- 未开启老年代分配担保机制,且一次 Full GC 后,老年代任然放不下剩余对象,也只能 OOM
- 开启老年代分配担保机制,但是担保不通过,一次 Full GC 后,老年代任然放不下剩余对象,也是能 OOM