添加VX:ruyuan0220,回复:CSDN,领取更多精品学习资料!
目录
背景知识
对象分配在新生代的Eden区,每次垃圾回收之后,存活对象都进入Survivor区,然后下一次垃圾回收后的存活对象都进入另外一个Survivor区。
这样几乎很少很少的对象会进入老年代里去,也就几乎不太会触发老年代的垃圾回收了。
但是理想很丰满,现实很骨干。其实大家想想,你们在写代码的时候,有谁会考虑垃圾回收啥的?不会有人考虑这个吧,就是不停的狂写代码,然后直接上线部署,根本没多少人会考虑自己的代码对垃圾回收的影响。
最多有经验的工程师上线之前,通过我们之前的案例讲解的方法估算一下系统的内存压力以及垃圾回收的运行模型,然后合理设置一下内存各个区域的大小,尽量避免太多对象进行老年代里去。
但是真实情况是,线上系统很可能就会因为各种各样的情况,导致很多对象进入老年代,然后甚至频繁触发老年代的Full GC。
之前我们用案例给大家演示过很多这种情况,比如说Survivor区太小,容纳不了每次Minor GC后的存活对象,导致对象频繁进入老年代,频繁触发老年代Full GC。
类似的情况其实很多,所以,咱们不能过于理想化的期待永远没有老年代GC,还是要对老年代的垃圾回收器是如何回收的,有一个了解和认识。
CMS垃圾回收的基本原理
一般老年代我们选择的垃圾回收器是CMS,他采用的是标记清理算法,其实非常简单,就是先用之前文章里讲过的标记方法去标记出哪些对象是垃圾对象,然后就把这些垃圾对象清理掉,如下图所示。
上面图里是一个老年代内存区域的对象分布情况,现在假设因为老年代内存空间小于了历次Minor GC后升入老年代对象的平均大小,判断Minor GC有风险,可能就会提前触发Full GC回收老年代的垃圾对象。
或者是一次Minor GC后的对象太多了,都要升入老年代,发现空间不足,出