CMS 回收器——低延迟

淩亂°似流年 2022-09-02 05:16 22阅读 0赞

# 一 点睛 #

在 JDK1.5 时期，Hotspot 推出了一款在强交互应用中几乎可认为有划时代意义的垃圾收集器：CMS（Concurrent-Mark-Sweep）收集器，这款收集器是 HotSpot 虚拟机中第一款真正意义上的并发收集器，它第一次实现了让垃圾收集线程与用户线程同时工作。

CMS 收集器的关注点是尽可能缩短垃圾收集时用户线程的停顿时间。停顿时间越短（低延迟）就越适合与用户交互的程序，良好的响应速度能提升用户体验。

目前很大一部分的 Java 应用集中在互联网站或者 B/S 系统的服务端上，这类应用尤其重视服务的响应速度，希望系统停顿时间最短，以给用户带来较好的体验。CMS 收集器就非常符合这类应用的需求。

CMS 的垃圾收集算法采用标记-清除算法，并且也会"stop-the-world"。

不幸的是，CMS 作为老年代的收集器，却无法与 JDK1.4 中已经存在的新生代收集器 Parallel Scavenge 配合工作，所以在 JDK1.5 中使用 CMS 来收集老年代的时候，新生代只能选择 ParNew 或者 Serial 收集器中的一个。

在 G1 出现之前，CMS 使用还是非常广泛的。一直到今天，仍然有很多系统使用 CMS GC。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2NoZW5ncWl1bWluZw_size_16_color_FFFFFF_t_70][]

CMS 整个过程比之前的收集器要复杂，整个过程分为4个主要阶段，即初始标记阶段、并发标记阶段、重新标记阶段和并发清除阶段。(涉及 STW 的阶段主要是：初始标记和重新标记)。

*  初始标记（Initial-Mark）阶段：在这个阶段中，程序中所有的工作线程都将会因为“stop-the-world”机制而出现短暂的暂停，这个阶段的主要任务仅仅只是标记出 GC Roots 能直接关联到的对象。一旦标记完成之后就会恢复之前被暂停的所有应用线程。由于直接关联对象比较少，所以这里的速度非常快。
 *  并发标记（Concurrent-Mark）阶段：从 GC Roots 的直接关联对象开始遍历整个对象图的过程，这个过程耗时较长但是不需要停顿用户线程，可以与垃圾收集线程一起并发运行。
 *  重新标记（Remark）阶段：由于在并发标记阶段中，程序的工作线程会和垃圾收集线程同时运行或者交叉运行，因此为了修正并发标记期间，因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间通常会比初始标记阶段稍长一些，但也远比并发标记阶段的时间短。
 *  并发清除（Concurrent-Sweep）阶段：此阶段清理删除掉标记阶段判断的已经死亡的对象，释放内存空间。由于不需要移动存活对象，所以这个阶段也是可以与用户线程同时并发的。

尽管 CMS 收集器采用的是并发回收（非独占式），但是在其初始化标记和再次标记这两个阶段中仍然需要执行“Stop-the-World”机制暂停程序中的工作线程，不过暂停时间并不会太长，因此可以说明目前所有的垃圾收集器都做不到完全不需要“stop-the-World”，只是尽可能地缩短暂停时间。

由于最耗费时间的并发标记与并发清除阶段都不需要暂停工作，所以整体的回收是低停顿的。

另外，由于在垃圾收集阶段用户线程没有中断，所以在 CMS 回收过程中，还应该确保应用程序用户线程有足够的内存可用。因此，CMS 收集器不能像其他收集器那样等到老年代几乎完全被填满了再进行收集，而是当堆内存使用率达到某一阈值时，便开始进行回收，以确保应用程序在 CMS 工作过程中依然有足够的空间支持应用程序运行。要是 CMS 运行期间预留的内存无法满足程序需要，就会出现一次“Concurrent Mode Failure”失败，这时虚拟机将启动后备预案：临时启用 Serial old 收集器来重新进行老年代的垃圾收集，这样停顿时间就很长了。

CMS 收集器的垃圾收集算法采用的是标记清除算法，这意味着每次执行完内存回收后，由于被执行内存回收的无用对象所占用的内存空间极有可能是不连续的一些内存块，不可避免地将会产生一些内存碎片。那么 CMS 在为新对象分配内存空间时，将无法使用指针碰撞（Bump the Pointer）技术，而只能够选择空闲列表（Free List）执行内存分配。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2NoZW5ncWl1bWluZw_size_16_color_FFFFFF_t_70 1][]

# 二 CMS 为什么不使用标记整理算法？ #

因为当并发清除的时候，用 Compact 整理内存的话，原来的用户线程使用的内存还怎么用呢？要保证用户线程能继续执行，前提是它运行的资源不受影响。Mark Compact 更适合“stop the world”这种场景下使用。

# 三 优点 #

*  并发收集
 *  低延迟

# 四 缺点 #

*  会产生内存碎片，导致并发清除后，用户线程可用的空间不足。在无法分配大对象的情况下，不得不提前触发 Full GC。
 *  CMS 收集器对 CPU 资源非常敏感。在并发阶段，它虽然不会导致用户停顿，但是会因为占用了一部分线程而导致应用程序变慢，总吞吐量会降低。
 *  CMS 收集器无法处理浮动垃圾。可能出现“Concurrent Mode Failure"失败而导致另一次 Full GC 的产生。在并发标记阶段由于程序的工作线程和垃圾收集线程是同时运行或者交叉运行的，那么在并发标记阶段如果产生新的垃圾对象，CMS 将无法对这些垃圾对象进行标记，最终会导致这些新产生的垃圾对象没有被及时回收，从而只能在下一次执行 GC 时释放这些之前未被回收的内存空间。

# 五 设置的参数 #

> \-XX:+UseConcMarkSweepGC 手动指定使用 CMS 收集器执行内存回收任务。

*  开启该参数后会自动将 -XX:+UseParNewGC 打开。即：ParNew（Young区用）+CMS（old区用）+ Serial old 的组合。

> \-XX:CMSInitiatingOccupanyFraction 设置堆内存使用率的阈值，一旦达到该阈值，便开始进行回收。

*  JDK5 及以前版本的默认值为68，即当老年代的空间使用率达到68%时，会执行一次 CMS 回收。JDK6 及以上版本默认值为92%。
 *  如果内存增长缓慢，则可以设置一个稍大的值，大的阀值可以有效降低 CMS 的触发频率，减少老年代回收的次数可以较为明显地改善应用程序性能。反之，如果应用程序内存使用率增长很快，则应该降低这个阈值，以避免频繁触发老年代串行收集器。因此通过该选项便可以有效降低 Full GC 的执行次数。

> \-XX:+UseCMSCompactAtFullCollection 用于指定在执行完 Full GC 后对内存空间进行压缩整理，以此避免内存碎片的产生。
> 
> \-XX:CMSFullGCsBeforeCompaction 设置在执行多少次 Full GC 后对内存空间进行压缩整理。

*  不过由于内存压缩整理过程无法并发执行，所带来的问题就是停顿时间变得更长了。

> \-XX:ParallelCMSThreads 设置 CMS 的线程数量。

CMS 默认启动的线程数是（ParallelGCThreads+3）/4，ParallelGCThreads 是年轻代并行收集器的线程数（CPU的个数）。当 CPU 资源比较紧张时，受到 CMS 收集器线程的影响，应用程序的性能在垃圾回收阶段可能会非常糟糕。

# 六 实战 #

## 1 代码 ##

/**
    * -XX:+UseConcMarkSweepGC：表明老年代使用CMS GC。同时，年轻代会触发对 ParNew 的使用
    */
    public class GCUseTest {
        public static void main(String[] args) {
            ArrayList<byte[]> list = new ArrayList<>();
    
    
            while (true) {
                byte[] arr = new byte[100];
                list.add(arr);
                try {
                    Thread.sleep(10);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }
        }
    }

## 2 测试——老年代使用 CMS GC，年轻代会触发对 ParNew 的使用 ##

JDK 9下测试

> D:\\ProgramFiles\\Java\\jdk-9\\bin\\java.exe -XX:+PrintCommandLineFlags -XX:+UseConcMarkSweepGC -javaagent:D:\\ProgramFiles\\JetBrains\\IDEA\\lib\\idea\_rt.jar=57512:D:\\ProgramFiles\\JetBrains\\IDEA\\bin -Dfile.encoding=UTF-8 -classpath E:\\JVMDemo\\out\\production\\chapter17 com.atguigu.java.GCUseTest
> 
> \-XX:InitialHeapSize=250603712 -XX:MaxHeapSize=4009659392 -XX:MaxNewSize=697933824 -XX:MaxTenuringThreshold=6 -XX:+PrintCommandLineFlags -XX:ReservedCodeCacheSize=251658240 -XX:+SegmentedCodeCache -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC -XX:-UseLargePagesIndividualAllocation -XX:+UseParNewGC
> 
> OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release.

JDK 8 测试

> D:\\ProgramFiles\\Java\\jdk1.8.0\_251\\bin\\java.exe -XX:+PrintCommandLineFlags -XX:+UseConcMarkSweepGC -javaagent:D:\\ProgramFiles\\JetBrains\\IDEA\\lib\\idea\_rt.jar=57627:D:\\ProgramFiles\\JetBrains\\IDEA\\bin -Dfile.encoding=UTF-8 -classpath D:\\ProgramFiles\\Java\\jdk1.8.0\_251\\lib\\ant-javafx.jar;D:\\ProgramFiles\\Java\\jdk1.8.0\_251\\lib\\dt.jar;D:\\ProgramFiles\\Java\\jdk1.8.0\_251\\lib\\javafx-mx.jar;D:\\ProgramFiles\\Java\\jdk1.8.0\_251\\lib\\jconsole.jar;D:\\ProgramFiles\\Java\\jdk1.8.0\_251\\lib\\packager.jar;D:\\ProgramFiles\\Java\\jdk1.8.0\_251\\lib\\sa-jdi.jar;D:\\ProgramFiles\\Java\\jdk1.8.0\_251\\lib\\tools.jar;E:\\JVMDemo\\out\\production\\chapter17 com.atguigu.java.GCUseTest
> 
> \-XX:InitialHeapSize=250603712 -XX:MaxHeapSize=4009659392 -XX:MaxNewSize=697933824 -XX:MaxTenuringThreshold=6 -XX:OldPLABSize=16 -XX:+PrintCommandLineFlags -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC -XX:-UseLargePagesIndividualAllocation -XX:+UseParNewGC

# 七 小结 #

HotSpot 有这么多的垃圾回收器，Serial GC、Parallel GC、Concurrent Mark Sweep GC 这三个 GC 有什么不同呢？

请记住以下口令：

*  如果想要最小化地使用内存和并行开销，请选 Serial GC
 *  如果想要最大化应用程序的吞吐量，请选 Parallel GC
 *  如果想要最小化 GC 的中断或停顿时间，请选 CMS GC

# 八 JDK 后续版本中 CMS 的变化 #

## **1 JDK9 新特性：CMS 被标记为 deprecate（JEP291）** ##

如果对 JDK9 及以上版本的 HotSpot 虚拟机使用参数 -XX:+UseConcMarkSweepGC 来开启 CMS 收集器的话，用户会收到一个警告信息，提示 CMS 未来将会被废弃。

## **2 JDK14 新特性：删除 CMS 垃圾回收器（JEP363）** ##

移除了 CMS 垃圾收集器，如果在 JDK14 中使用 XX:+UseConcMarkSweepGC 的话，JVM 不会报错，只是给出一个 warning 信息，但是不会 exit。JVM 会自动回退以默认 GC 方式启动 JVM。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2NoZW5ncWl1bWluZw_size_16_color_FFFFFF_t_70]: /images/20220829/8fd87f770fe84cc994e90097156c5674.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2NoZW5ncWl1bWluZw_size_16_color_FFFFFF_t_70 1]: /images/20220829/0c04a49d82f949c6a0b4807413347c6c.png