[JVM]聊聊 CMS 收集器

如果要问 JVM 垃圾回收器有哪些, CMS 收集器就肯定是绕不过去

CMS 收集器是基于标记-清除算法实现的,整个回收过程分为四个步骤:

• 初始标记
• 并发标记
• 重新标记
• 并发清除

初始标记时,就是标记一下 GC Roots 能直接关联到的对象,这个过程会很快,在这期间会发生 Stop the world ,这个阶段垃圾收集线程是独占的,不会和用户线程一起运行
并发标记则是从 GC Roots 的直接关联对象开始遍历整个对象,这个过程耗时较长,但是不需要停顿用户线程,用户线程可以和垃圾收集线程一起并发运行
重新标记就是为了修正并发标记期间,因为用户程序继续运作而导致标记产生变动的那一部分对象的标记记录,这个阶段相对于初始标记来说,它的停顿时间是比较长的,但是跟并发标记阶段相比的话,那它的停顿时间还是挺少的,这期间也会发生 Stop the world
最后就是并发清除阶段,在这个阶段就是要清理删除掉标记阶段判断的已经死亡的对象,这个时候由于不需要移动存活对象,所以这个阶段也是可以和用户线程一起并发运行的

CMS 它的优点主要在于:并发收集,低停顿,但是它也有自己的缺点:

• CMS 收集器对处理器资源非常敏感,在并发标记和并发清除阶段,它虽然不会导致用户线程停顿,但是会因为占用了一部分线程导致应用程序变慢,降低总吞吐量
  CMS 默认启动的回收线程数是(处理器核心数量 + 3)/4,也就是如果处理器核心数在四个或以上,并发回收时垃圾收集线程只占用不超过 25% 的处理器运算资源,但是当处理器核心数量不足四个时, CMS 对用户程序的影响就可能变得很大
• CMS 没办法处理"浮动垃圾",在 CMS 并发标记和并发清理阶段,用户线程还在继续运行的,程序在运行自然就会有新的垃圾对象不断产生,但是这一部分垃圾对象是出现在标记过程结束以后, CMS 没有办法在当次收集中处理掉它们,只要等到下一次垃圾收集时再清理掉,这一部分垃圾就是"浮动垃圾"
• CMS 是基于"标记-清除"算法实现的收集器,这就意味着收集结束时会有大量空间碎片产生,空间碎片如果过多的话,就有可能出现一种情况:明明老年代还有很多剩余空间,但就是无法找到足够大的连续空间来分配当前对象,这样就不得不提前触发一次 Full GC
  为了解决这个问题, CMS 收集器提供了一个 -XX: +UseCMS-CompactAtFullCollection 开关参数(默认是开启的,这个参数从 JDK 9 开始废弃),这个参数就是让 CMS 收集器不得不进行 Full GC 时开启内存碎片合并整理,那如果想要进行合并整理的话,就必须移动存活对象,就没有办法做到并发,这样去做的话,空间碎片问题是解决了,但是停顿时间就又会变长
  所以虚拟机设计者还给了另外一个参数 -XX: CMSFullGcBeforeCompaction ,设置了这个参数就会让 CMS 收集器在执行若干次不整理空间的 Full GC 之后,下一次进入 Full GC 之前会先进行碎片整理(默认值为 0,表示每次进入 Full GC 时都会进行碎片整理)

想要分享的大概就是这些了~