CMS收集过程和优化思路

CMS(Concurrent Mark Sweep),是JDK1.5时的默认收集器(1.6及其之后版本不再使用)。回收区域是老年代,使用标记-清楚算法。设计初衷暂且认为是对并发回收的大胆尝试。

通常的收集搭档是:
ParNew(针对新生代)+CMS(针对老年代)+Serial Old(老年代兜底后续会讲)
(Parallel Scavenge 因无法与CMS搭配使用,在 Parallel Old 没出来前,它都处于一个很尴尬的位置)

  • 优点:在垃圾收集过程中,时间占比比较多的操作阶段(可达性分析和收集垃圾),垃圾收集线程与用户线程并发进行,可以减少GC带来的用户线程的停顿时间
  • 缺点:1.基于标记-清除算法,导致内存碎片化,在没有足够的情况下只能依赖于Serial old收集器(标记-整理算法)做兜底。2.由于收集收集过程中,用户线程仍在运行(浮动垃圾),因此需要预留一些空间,收集过程中空间不足以分配对象也会导致STP(Stop The World)做Full GC。
    这两个条件也就意味着,GC的频率会变得频繁,整体吞吐量反而降低了

GC吞吐量 = 用户代码运行时间 / (用户代码运行时间+GC停顿时间)

作为JVM众多GC收集器中,第一款可以与用户线程并行的垃圾收集器,了解其原理对后续G1、Shenandoah和ZGC有重要的意义。

CMS运行过程

CMS_work.png
  1. 初始标记(initial mark):重点做枚举根节点操作,需要STW,但借助于OopMap结构,这个过程可以在ms级别快速完成。
  2. 并发标记(concurrent mark):可达性分析阶段,耗时,并行,不需要STW。用户线程在新增对象引用时,会通过写屏障,将这些引用保存下来,用于重新标记阶段。
  3. 重新标记(remark):处理并发标记阶段,用户线程新增的引用关系(浮动垃圾)。需要STW。整体来讲,采用的是增量更新的方式,解决用户线程在并发阶段修改对象引用图引发的问题。
  4. 并发清除(concurrent sweep):使用标记-清楚算法,清除无用对象,不需要STW。

CMS在并发阶段,用户线程仍然会产生对象。如果此时预留内存不满足程序分配对象需要,就会出现一次“并发失败”(Concurrent Mode Failure),STW 临时启用Serial Old。

CMS优化思路

  1. GC线程数:CMS默认启动线程数=(CPU核心数+3)/4,CPU核心数越多,极限越趋向n/4(25%)。在单核情况下表现糟糕,因考虑Serial Old,对于CPU资源敏感成需要应适当调小小点。-XX: ParallelCMSThreads=4
  2. 并发阶段由于浮动垃圾引发Full GC:并发阶段,用户线程仍会产生新的对象,当新对象无处存放时,启用Serial Old收集器做预案操作。据此,CMS在进行垃圾收集时,要预留一定空闲空间。这个空间不易太小,也不易太大。-XX:CMSInitiatingOccupancyFraction设置。
  3. 内存碎片化,大对象没有空隙分配,导致Full GC:-XX:+UseCMSCompactAtFullCollection,在进行Full GC是开启合并整理过程,默认开启。-XX:CMSFullGCsBeforeCompaction(JDK9废弃),在执行了若干次不整理内存空间的GC后,下一次进入FullGC前先进行碎片整理,默认值为0,表示每次进入Full GC时都进行内存碎片整理。

你可能感兴趣的:(CMS收集过程和优化思路)