CMS垃圾回收器运行机制与优缺点

清疚 2022-08-31 11:01 223阅读 0赞

### 文章目录 ###

*  1 简介
 *  2 运行机制
 *  3 缺点
 *   *  3.1 对CPU资源敏感
     *  3.2 浮动垃圾
     *  3.3 内存碎片

# 1 简介 #

CMS（Concurrent Mark Sweep）收集器将低GC停顿作为目标的并发收集器，采用“标记-清除”算法，尽可能降低GC的停顿时间，关注应用的响应速度，所以它在Web应用服务中被大量使用。

# 2 运行机制 #

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM0ODAyNDE2_size_16_color_FFFFFF_t_70_pic_center]

CMS进行GC的两个阶段

（1）标记阶段

*  初始标记（STW）：标记GC Roots能**直接关联**到的对象，速度较快
 *  并发标记：从初始标记过程标记到的对象**遍历对象图**，该过程与用户进程并发执行
 *  重新标记（STW）：**增量**地对并发标记过程产生变动的对象进行标记，稍长于初始标记

（2）清除阶段

*  并发清除：仅清理标记阶段判断的已死亡的对象，不移动存活对象，与用户线程并发执行

对于CMS GC的过程来说，在初始标记和重新标记有停顿，其余过程都与用户进程并发执行。

# 3 缺点 #

## 3.1 对CPU资源敏感 ##

由于GC线程是CPU密集型线程，且它与用户线程在“并发标记”与“并发清除”阶段是并发执行的，所以GC线程会与用户线程竞争CPU资源，使得部分用户线程得不到执行，导致应用程序的总吞吐量降低。

机器的CPU核数越少，该问题越明显。

CMS默认启动回收线程数为(CPU+3)/4。对于一个4核CPU来说，并发过程中GC线程会占用不超过25%的CPU资源，对于2核CPU则为不超过50%，即核数越多影响越小。

## 3.2 浮动垃圾 ##

由于“清除阶段”与用户线程是并发执行的，所以该过程产生的新的垃圾对象（浮动垃圾）是无法在当前这次GC中进行清理的，只能等到下一次GC。如果该过程中产生的新的垃圾对象太多了，则会使当前这次CMS GC抛出“Concurrent Mode Failure”失败，进而导致另外一次完全STW的Full GC（Serial Old）的产生，此时将严重影响用户程序性能。

考虑到浮动垃圾的产生，CMS必须在GC时预留足够空间，而不能等到内存空间被完全填满时才进行GC。可以通过自定义-XX:CMSInitiatingOccu-pancyFraction（默认92%）的值来调整CMS GC的触发阈值。该值设置得过低则会因频繁进行CMS GC导致应用程序吞吐量下降，设置得过高则会因“Concurrent Mode Failure”而频繁触发Full GC导致应用程序停顿。

## 3.3 内存碎片 ##

由于CMS 采用的是“标记-清除”算法，该GC算法不会对内存空间进行整理，所以会产生内存碎片，可能无法正常为大对象分配连续的内存空间，导致不得不提前触发一次Full GC。

CMS收集器提供-XX:+UseCMS-CompactAtFullCollection开关（默认打开）参数，用于在CMS不得不进行Full GC时开启内存碎片的合并整理过程，因为涉及移动存活对象，该过程需要STW。

为了不必每次Full GC都对内存空间做合并整理，还提供-XX: CMSFullGCsBeforeCompaction（默认0）以自定义经过多少次Full GC后才执行合并整理操作。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM0ODAyNDE2_size_16_color_FFFFFF_t_70_pic_center]: /images/20220829/3f5dc7d438074dde959d5dba437bb2a1.png