垃圾回收过程

老年代剩余内存n

没设置

新生代

可以冒点风险尝试一下Minor GC，会产生三种情况

老年代已用内存m

设置了

Minor GC过后，剩余的存活对象的大小，是小于Survivor区的大小的，那么此时存活对象进入Survivor区域即可

Eden区

to

老年代还是没有足够的空间存放Minor GC过后的剩余存活对象，那么此时就会导致“OOM”内存溢出了

老年代剩余内存大小空间足够，安心的把From区放不下的数据放进来

查看老年代的内存大小，是否大于之前每一次Minor GC后进入老年代的对象的平均大小。

Full GC就是对老年代进行垃圾回收，同时也一般会对新生代进行垃圾回收。

当Eden再次塞满的时候，去标记出来Eden和from区中的存活对象然后一次性把存活对象转移到to区中去，接着把Eden和from区中的垃圾对象都回收掉，把To区变成From区，以后在执行淘汰算法，重复此次操作

触发一次“FullGC”，对老年代进行垃圾回收，尽量腾出来一些内存空间，然后再执行Minor GC

老年代

先查看“-XX:-HandlePromotionFailure”的参数是否设置了

GC之前判断q，n大小

如果剩余的存活对象内存大小大于From区内存大小，直接进入到老年代

Minor GC过后，剩余的存活对象的大小，大于了Survivor区域的大小，也大于了老年代可用内存的大小。此时老年代都放不下这些存活对象了，这个时候就会触发一次“Full GC”

Minor GC过后，剩余的存活对象的大小，是大于 Survivor区域的大小，但是是小于老年代可用内存大小的，此时就直接进入老年代即可

1.判断进入的对象是否为大对象，是的话直接进入到老年代2.默认在新生代存活15次，进入到老年代3.动态对象年龄判断：年龄1+年龄2+年龄n的多个年龄对象总和超过了Survivor区域的50%，此时就会把年龄n以上的对象都放入老年代。

大于

第一次Eden区满了，把Eden区中的存活对象都标记出来，然后全部转移到from区去，接着一次性清空掉Eden中的垃圾对象

qn

最不幸运的

但是“-XX:HandlePromotionFailure”参数在JDK 1.6以后就被废弃了，所以现在一般都不会在生产环境里设置这个参数了。在JDK1.6以后，只要判断“老年代可用空间”> “新生代对象总和”，或者“老年代可用空间”> “历次Minor GC升入老年代对象的平均大小”，两个条件满足一个，就可以直接进行Minor GC，不需要提前触发Full GC了。

触发Minor GC之前需要先判断老年代可用内存是否大于新生代所有的对象内存大小（假设于新生代所有对象的总大小为q）

小于

对象代对象进入到老年代的规则

from