CMS垃圾收集器&三色标记-JVM(十二)

上篇文章说了CMS垃圾收集器是赋值清除,所以他不可以碎片整理,于是jvm支持两个参数,几次fullGC之后碎片整理压缩空间。Cms他会抢占cpu资源,因为是并行运行,所以会有浮动垃圾。还有执行不确定性,垃圾收集完,继续进入新的对象,导致异常concurrent mode faliture,最后用serial old处理,可以用jvm的fraction参数来参数百分之多少的时候需要GC,这样就预留充足的空间存储新对象。

垃圾收集器CMS-JVM(十一)

  • 实际场景

前面介绍了cms的参数,那么我们如何应用呢?

前面文章我们介绍了parallel作用于年轻代和老年代回收,当时场景是因为回收的对象比较大,不能进入survivor,导致直接从eden进入old,这时候eden满的那一瞬间,也就是minor GC时候最后一个对象不会在年轻代回收,进入老年代,当时我们通过设置年轻代大小的参数,来解决了减少fullGC的问题。

CMS垃圾收集器&三色标记-JVM(十二)_第1张图片

 

那我们现在既然学习了cms和parNew,就试着用新的方法来解决。

前面我们的参数jvm参数配置是:

Java -Xms3072M -Xmx3072M -Xmn2048M -Xss1M -XX:MetaspaceSize=256M

-XX:MaxMetaspaceSize=256M -XX SurvivorRatio=8

这样配合当时的应用场景绝对不发生fullGc是不可能的。当时我们的场景是每秒产生60MB,但如果峰值增加,在23秒,24秒的时候,每次cpu分配给单个线程的运行已经超过几秒,这时候minor GC的时候会超过60M的数据移动到survivor,这时候200M的S0已经未必放的下这些存活的数据,需要移动到old,这时候当old满的时候又会触发fullGC。

但这种秒杀场景,即使出现这种情况影响也不大,因为当old满的时候,秒杀的前10分钟已经过去,这时候发生一次fullGC也不影响。

Java -Xms3072M -Xmx3072M -Xmn2048M -Xss1M -XX:MetaspaceSize=256M

-XX:MaxMetaspaceSize=256M -XX SurvivorRatio=8

-XX:MaxTenuringThreshold=5 -XX:PretenureSizeThreshold=1M

-XX:UseParNewGC -XX:+UseConcMarkSweepGC

-XX:UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=3

这个参数一次的fullGC不会存在大量参数,所以一次未必需要整理,配置两到三次都没有问题。

  • 三色标记

这个底层并不是java实现,而是c++实现的。

前面说了在gc发生的时候,用户线程和垃圾回收线程并行运行,对于多标和漏标的情况可能会发生。

多标影响还好,可以在下一次gc的时候清除,在并发标记的时候,就会存在多标的现象,但是少标或者漏标影响比较大。

三色标记指GCroots 可达性分析遍历对象过程中遇到的对象,按照是否访问过标记为三种颜色。

黑色:表示对象已经被垃圾收集器访问过,且这个对象所有引用都扫描过,它是存活的对象。如果其他对象引用指向黑色,无须重新扫描。黑色对象不可以直接(不经过灰色对象)指向某个白色对象。

灰色:表示对象已经被垃圾回收访问过,但至少还有一个或者以上引用没被扫描到。

白色:表示对象未被垃圾回收器访问过。

前面说的多标浮动垃圾对象,三色标记的处理办法则是直接标记成黑色,本轮GC不会清除,但是下一轮则可能部分对象变为垃圾对象。

漏标-读写屏障

漏标则会把未标记的对象无删除,这种验证bug则会有两种办法解决,增量更新和原始快照

漏标会找到之前的引用,重新去扫描。

增量更新指一旦有新插入的指向白色,则会变成灰色对象。

原始快照则是让对象在本轮gc存活,在下一次gc再清理,可以理解为浮动垃圾。

这些都是在写屏障实现的。

  • 记忆集与卡表

新生代做gcRoots 的时候可能遇到跨代应用场景,这时候总不能再去old代理扫描一遍。

于是新生代里有一个记录集(remember set)数据结构,记录这种跨代应用的对象,避免GC roots去老年代扫描。事实上,老年代也有这种问题,G1和ZGC收集器都有这种问题。

hotSpot使用叫做卡表Cardtable的方式实现这种收集,也是目前最常用的一种方式。

你可能感兴趣的:(jvm)