浅谈CMS原理
CMS(Concurrent Mark Sweep)收集器以获取最短回收停顿时间为目标,是HotSpot虚拟机中第一款真正意义上的并发收集器,第一次实现了让垃圾收集线程与用户线程(基本上)同时工作。
过程
- 初始标记(CMS initial mark):标记一下GC Roots能直接关联到的对象。需要STW,速度很快。
- 并发标记(CMS concurrent mark):进行GC Roots Tracing。不需要STW。会产生浮动垃圾。
- 重新标记(CMS remark):找到并发标记期间产生的浮动垃圾。需要STW,停顿时间一般会比初始标记稍长,但远比并发标记短。
- 并发清除(CMS concurrent sweep):清除已标记的垃圾。不需要STW。会产生浮动垃圾,只能等下一次GC清理。
重新标记的过程?为什么比并发标记的时间短?
不考虑标记对象年龄等操作,最容易想到的原因是:
对象数的区别:“并发标记”过程需要扫描所有对象,标记出不可达的对象(该清除)和可达的对象(不该清除);“重新标记”只需要扫描在“并发标记”过程中被标记为可达或新创建的对象,检查其是否在“并发标记”过程中被标记为可达之后,由于用户使用变的不可达了
并发环境的区别:“并发标记”是与用户线程一起工作的,并发瓶颈较窄(工作线程少+安全检查);“重新标记”需要stop the world,之后仅有“重新标记”的线程在工作,并发瓶颈宽的多
PS:关于对象数的区别要想清楚,在对象分配后,如果对象有一瞬间不可达,则该对象以后都将不可达,可对其清理。因此,重新标记时不需要检查这部分对象。
并发清除的过程?如何才能让用户边使用,边清除?
还是那句话:
在对象分配后,如果对象有一瞬间不可达,则该对象以后都将不可达,可对其清理。
所以,已经在“并发标记”和“重新标记”过程被标记为不可达的对象,以后都不会再被用户使用,清除这些对象对用户完全无影响。
唯一可能有影响的是整理内存的过程,不过也只需要同步使用对象和整理对象两个动作。
CMS的优点、缺点?
优点:
大部分时间可与用户线程并发工作
低停顿
缺点:
对CPU资源非常敏感。并发标记和并发清理与用户线程一起工作,如果用户线程也是CPU敏感的,那么必然影响用户线程。
无法处理浮动垃圾(Floating Garbage)。并发标记与并发清除过程会产生浮动垃圾,如果CMS之前预留的内存无法满足程序需要,就会出现一次“Concurrent Mode Failure”失败,这时虚拟机将退化使用Serial Old收集器,重新进行老年代的垃圾收集,这样停顿时间就很长了。可使用XX:CMSInitiatingOccupancyFraction参数设置触发CMS时的老年代空间比例(剩余空间就是预留空间),在JDK1.6中默认为92%。
基于“标记-清除算法”,收集结束时会有大量空间碎片产生,导致明明剩余空间充足,却无法为大对象分配足够的连续内存。可打开-XX:+UseCMSCompactAtFullCollection开关参数(默认打开)在进行Full GC之前整理内存碎片(称为“压缩”);使用-XX:CMSFullGCsBeforeCompaction参数(默认0)设置多少次不带压缩的Full CG之后才进行一次带压缩的Full GC。内存整理无法并行,还需要STW,需要适当调整内存整理的频率,在GC性能与空间利用率之间平衡。
PS:
浮动垃圾:由于CMS并发清理阶段用户线程还在运行着,伴随程序运行自然就还会有新的垃圾不断产生,这一部分垃圾出现在标记过程之后,CMS无法在当次收集中处 理掉它们,只好留待下一次GC时再清理掉。这一部分垃圾就称为“浮动垃圾”。在这期间用户可能创建新的对象。为了处理这部分浮动垃圾和对象,CMS在并发清理之前,需要预留出足够空间给并发清理期间的用户线程使用。一般会显示使用-XX:CMSInitiatingOccupancyFraction参数设置触发CMS时的老年代空间比例,如果老年代增长不是太快,可以适当提高比例,以减少Full GC的次数。
关于浮动垃圾和内存碎片的问题。HDFS namenode在堆内存达到100G规模时,通常设置75%触发Full GC,不开启压缩,优先考虑STW造成的延迟。