Java 虚拟机之 CMS 垃圾收集器
1. 前言
Concurrent Mark Sweep (CMS) 收集器是 hotspot 虚拟机中一款低延迟的并发型垃圾收集器。CMS 垃圾收集器的关注点是：尽可能缩短垃圾收集时用户线程的停顿时间，停顿时间越短（低延迟）就是越适合与用户交互的程序，良好的响应速度能提升用户体验。
CMS 垃圾收集器 以获取最短回收停顿时间为目标，采用“标记-清除”算法，分 4 大步进行垃圾收集，其中初始标记和重新标记会 STW ，多数应用于互联网站或者 B/S 系统的服务器端上，JDK9 被标记弃用，JDK14 被删除，详情可见 JEP 363。
不幸的是，CMS 作为老年代的垃圾收集器，却无法与 Jdk 1.4 中以及存在的新生代收集器 Parallel Scavenge 配合工作，所以在 jdk 1.5 中 使用 CMS 来收集老年代的时候，新生代就只能选择 ParNew 或者 Serial 收集器中的一个。
在 G1 出现之前，CMS 使用还是非常广泛的。
CMS 收集器通过命令行选项启用-XX:+UseConcMarkSweepGC。
2. CMS 工作原理
CMS 提出时最大的创新在于其针对老年代并发收集的理念，下面来分析并发收集的过程。根据 oracle 提供的关于 CMS 的官方文档描述
整个并发收集通常包括以下步骤：
初始标记
并发标记
重新标记
并发清除
并发重置
上述步骤只有初始化标记和重新标记会 STW(Stop The World)，其余三个步骤与应用程序 mutator 都是并发的，下面来看每个步骤具体的细节。
(1) 初始标记（Initial Mark）
初始标记 目标是标记老年代中的所有对象，这些对象包括直接的 GC Root 关联的对象和从年轻代中的某个活动对象引用的对象，该过程会发生第一次 STW.
（2）并发标记
通过遍历第一个阶段（Initial Mark）标记出来的存活对象，继续递归遍历老年代，并标记可直接或间接到达的所有老年代存活对象在并发标记阶段， 应用线程和 GC 线程是并发执行的，因此可能产生新的对象或对象关系发生变化。
比如：
新生代的对象晋升到老年代
直接在老年代分配对象
老年代对象的引用关系发生变更
对于这些对象，需要重新标记以防止被遗漏。 为了提高重新标记的效率，本阶段会把这些发生变化的对象所在的 Card 标识为 Dirty ，这样后续就只需要扫描这些 Dirty Card 的对象，从而避免扫描整个老年代。
并发预清理该阶段预标记线程和应用线程并行运行，此阶段将会重新扫描前一个阶段标记的 Dirty 对象，并标记被 Dirty 对象直接或间接引用的对象，对于一些对象引用有变动的堆区域标记为 Dirty 。
预清理阶段，这些脏对象被计算在内，并且可以从它们可到达的对象也被标记
可终止预清理
可中止的并发预清理 这个阶段是尽量为下一个步骤减轻任务，默认时间是 5s 期望在时间内做一次 YGC，从而减少下一次 STW 的时候扫描标记新生代引用老年代的对象个数。由于这个阶段是循环的做两件事直到发生 abort 的条件，如：重复的次数、多少量的工作、持续的时间等：
处理 From 和 To 区的对象，标记可达的老年代对象；
和上一个阶段一样，扫描处理 Dirty Card 中的对象。
（3）最终标记
该阶段发生第二次 STW, 目标是完成标记老年代中所有活动的对象,由于之前的预清理阶段是并发的，它们可能无法跟上应用程序的变化速度,所以需要 STW 二次验证。
遍历新生代对象，重新标记；（新生代会被分块，多线程扫描）
根据 GC Roots，重新标记；
遍历老年代的 Dirty Card，重新标记。这里的 Dirty Card，大部分已经在 Preclean 阶段被处理过了。
在三个标记阶段之后，老年代的所有存活对象都被标记，现在垃圾收集器将通过清除老年代来回收所有未使用的对象：
（4）并发清除与应用程序同时执行，无需 STW。该阶段的目的是移除未使用的对象并回收它们占用的空间以备将来使用。
(5)并发重置将清理并恢复在 CMS GC 过程中的各种状态，重新初始化 CMS 相关数据结构，为下一个垃圾收集周期做好准备。 CSM 执行日志：
3. CMS 优劣势
3.1 优点
并发收集
低停顿
所以 CMS 收集器适合与用户交互较多的场景，注重服务的响应速度，能给用户带来较好的体验！所以我们在做 WEB 开发的时候，经常会使用 CMS 收集器作为老年代的收集器！
3.2 缺点
会产生内存碎片， 导致并发清除后，用户线程可用的空间不足。在年轻代无法分配大对象的情况下，不得不提前触发 Full GC。
CMS 收集器对 CPU 资源非常敏感。在并发阶段，它虽然不会导致用户线程停顿，但会因为占用了一部分线程而导致引用程序变慢，总吞吐量会变低。
CMS 收集器无法处理浮动垃圾。可能出现“Concurrent Mode Failure” 失败而导致另一次 FUll GC 产生。在并发标记和并发清除阶段，用户线程与 GC 线程并发工作，这会导致在清理的时候又会有用户的线程在拼命的创建对象，本身垃圾回收时候肯定是可用内存不够了，可万一这时候用户线程创建了大量的对象怎么办呢？所以一般 CMS 收集器的垃圾回收的动作不会在完全无法分配内存的时候进行，可以通过“-XX:CMSInitiatingOccupancyFraction”参数来设置 CMS 预留的内存空间！
如果预留的空间无法满足 CMS 的需要，就会出现 “Concurrent Mode Failure”失败。
这时候 JVM 会启用后备方案，也就是前面介绍过的 Serial Old 收集器，这样会导致另一次的 Full GC 的产生，这样的代价是很大的，所以 CMSInitiatingOccupancyFraction 这个参数设置需要根据程序合理设置！
4. GC 分类
堆内存划分为 Eden、Survivor 和 Tenured/Old 空间，在整个过程中，经常对 Minor、Major、和 Full GC 事件的使用感到困惑。下面分别说明一下。
4.1 Minor GC
从年轻代空间（包括 Eden 和 Survivor 区域）回收内存被称为 Minor GC
这一定义既清晰又易于理解。但是,当发生 Minor GC 事件的时候，有一些有趣的地方需要注意到：
JVM 无法为一个新的对象分配空间时会触发 Minor GC，比如当 Eden 区满了。所以分配率越高，越频繁执行 Minor GC。
内存池被填满的时候，其中的内容全部会被复制，指针会从 0 开始跟踪空闲内存。Eden 和 Survivor 区进行了标记和复制操作，取代了经典的标记、扫描、压缩、清理操作。所以 Eden 和 Survivor 区不存在内存碎片。写指针总是停留在所使用内存池的顶部。
执行 Minor GC 操作时，不会影响到永久代。从永久代到年轻代的引用被当成 GC roots，从年轻代到永久代的引用在标记阶段被直接忽略掉。
质疑常规的认知，所有的 Minor GC 都会触发“全世界的暂停（stop-the-world）”，停止应用程序的线程。对于大部分应用程序，停顿导致的延迟都是可以忽略不计的。其中的真相就 是，大部分 Eden 区中的对象都能被认为是垃圾，永远也不会被复制到 Survivor 区或者老年代空间。如果正好相反，Eden 区大部分新生对象不符合 GC 条件，Minor GC 执行时暂停的时间将会长很多。
所以 Minor GC 的情况就相当清楚了——每次 Minor GC 会清理年轻代的内存。
YGC 是什么时候触发的？
大多数情况下，对象直接在年轻代中的 Eden 区进行分配，如果 Eden 区域没有足够的空间，那么就会触发 YGC（Minor GC），YGC 处理的区域只有新生代。因为大部分对象在短时间内都是可收回掉的，因此 YGC 后只有极少数的对象能存活下来，而被移动到 S0 区（采用的是复制算法）。
当触发下一次 YGC 时，会将 Eden 区和 S0 区的存活对象移动到 S1 区，同时清空 Eden 区和 S0 区。当再次触发 YGC 时，这时候处理的区域就变成了 Eden 区和 S1 区（即 S0 和 S1 进行角色交换）。每经过一次 YGC，存活对象的年龄就会加 1。
4.2 Major GC vs Full GC
大家应该注意到，目前，这些术语无论是在 JVM 规范还是在垃圾收集研究论文中都没有正式的定义。但是我们一看就知道这些在我们已经知道的基础之上做出的定义是正确的，Minor GC 清理年轻带内存应该被设计得简单：
Major GC 是清理永久代。
Full GC 是清理整个堆空间—包括年轻代和永久代。
Full GC 又是什么时候触发的？
下面 4 种情况，对象会进入到老年代中：
YGC 时，To Survivor 区不足以存放存活的对象，对象会直接进入到老年代。
经过多次 YGC 后，如果存活对象的年龄达到了设定阈值，则会晋升到老年代中。
动态年龄判定规则，To Survivor 区中相同年龄的对象，如果其大小之和占到了 To Survivor 区一半以上的空间，那么大于此年龄的对象会直接进入老年代，而不需要达到默认的分代年龄。
大对象：由-XX:PretenureSizeThreshold 启动参数控制，若对象大小大于此值，就会绕过新生代, 直接在老年代中分配。
当晋升到老年代的对象大于了老年代的剩余空间时，就会触发 FGC（Major GC），FGC 处理的区域同时包括新生代和老年代。除此之外，还有以下 4 种情况也会触发 FGC：
老年代的内存使用率达到了一定阈值（可通过参数调整），直接触发 FGC。
空间分配担保：在 YGC 之前，会先检查老年代最大可用的连续空间是否大于新生代所有对象的总空间。如果小于，说明 YGC 是不安全的，则会查看参数 HandlePromotionFailure 是否被设置成了允许担保失败，如果不允许则直接触发 Full GC；如果允许，那么会进一步检查老年代最大可用的连续空间是否大于历次晋升到老年代对象的平均大小，如果小于也会触发 Full GC。
Metaspace（元空间）在空间不足时会进行扩容，当扩容到了-XX:MetaspaceSize 参数的指定值时，也会触发 FGC。
System.gc() 或者 Runtime.gc() 被显式调用时，触发 FGC。
5. CMS GC 参数配置
CMS（Concurrent Mark Sweep，并发-标记-清除）是目前最常用的 JVM 垃圾回收器，这里不解释 CMS 的工作过程，只记录一些基础要点以帮助理解后面的内容：
CMS 是一种基于并发、使用标记清除算法的垃圾回收器。CMS 会尽可能让 GC 线程与用户线程并发执行，可以消除长时间的 GC 停顿（STW）。
CMS 不会对新生代做垃圾回收，默认只针对老年代进行垃圾回收。此外，CMS 还可以开启对永久代的垃圾回收（或元空间），避免由于 PermGen 空间耗尽带来 Full GC，JDK6 以上受参数 -XX:+CMSClassUnloadingEnabled 控制，这个参数在 JDK8 之前默认关闭，JDK8 默认开启了。
CMS 要与一个新生代垃圾回收器搭配使用，所谓"分代收集"。能与 CMS 配合工作的新生代回收器有 Serial 收集器和 ParNew 收集器，我们一般使用支持多线程执行的 ParNew 收集器。
使用 CMS GC 策略时，GC 类别可以分为：Young GC（又称 Minor GC），Old GC（又称 Major GC、CMS GC），以及 Full GC。其中 Full GC 是对整个堆的垃圾回收，STW 时间较长，对业务影响较大，应该尽量避免 Full GC
5.1 JVM 参数配置
经过理解各个参数的含义及取值影响，总结了以下的 JVM 参数配置，可以几乎不用调整使用：
如果是 64G 及以上的大堆，-Xmn 可以调整到 2g，其他参数不变或微调。下面对一些重要的 JVM 参数介绍说明。
重点参数解析
以下参数解析都建立在使用 CMS GC 策略基础上，这里使用 CMS GC 表示老年代垃圾回收，Young GC 表示新生代垃圾回收。① -Xmx, -Xms, -Xmn
-Xmx、-Xms 分别表示 JVM 堆的最大值，初始化大小。
-Xmx 等价于-XX:MaxHeapSize
-Xms 等价于-XX:InitialHeapSize。
-Xmn 表示新生代大小，等价于-XX:MaxNewSize、-XX:NewSize，这个参数的设置对 GC 性能影响较大，设置小了会影响 CMS GC 性能，设置大了会影响 Young GC 性能，建议取值范围在 1~3g，比如 32g 堆大小时可以设为 1g，64g 堆大小时可以设为 2g，通常性能会比较高。
② -Xss
表示线程栈的大小，等价于-XX:ThreadStackSize，默认 1M，一般使用不了这么多，建议值 256k。
③ -XX:SurvivorRatio
新生代中 Eden 区与 Survivor 区的比值，默认 8，这个参数设置过大会导致 CMS GC 耗时过长，建议调小，使得短寿对象在 Young 区可以被充分回收，减少晋升到 Old 区的对象数量，以此提升 CMS GC 性能。
④ -XX:+UseParNewGC, -XX:+UseConcMarkSweepGC
分别表示使用并行收集器 ParNew 对新生代进行垃圾回收，使用并发标记清除收集器 CMS 对老年代进行垃圾回收。
⑤ -XX:ParallelGCThreads, -XX:ParallelCMSThreads
分别表示 Young GC 与 CMS GC 工作时的并行线程数，建议根据处理器数量进行合理设置。
⑥ -XX:MaxTenuringThreshold
对象从新生代晋升到老年代的年龄阈值（每次 Young GC 留下来的对象年龄加一），默认值 15，表示对象要经过 15 次 GC 才能从新生代晋升到老年代。设置太小会严重影响 CMS GC 性能，建议默认值即可。
⑦ -XX:+UseCMSCompactAtFullCollection
由于 CMS GC 会产生内存碎片，且只在 Full GC 时才会进行内存碎片压缩（因此 使用 CMS 垃圾回收器避免不了 Full GC）。这个参数表示开启 Full GC 时的压缩功能，减少内存碎片。
⑧ -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction
-XX:CMSInitiatingOccupancyFraction 表示触发 CMS GC 的老年代使用阈值，一般设置为 70~80（百分比），设置太小会增加 CMS GC 发现的频率，设置太大可能会导致并发模式失败或晋升失败。默认为 -1，表示 CMS GC 会由 JVM 自动触发。
-XX:+UseCMSInitiatingOccupancyOnly 表示 CMS GC 只基于 CMSInitiatingOccupancyFraction 触发，如果未设置该参数则 JVM 只会根据 CMSInitiatingOccupancyFraction 触发第一次 CMS GC ，后续还是会自动触发。建议同时设置这两个参数。
⑨ -XX:+CMSClassUnloadingEnabled
表示开启 CMS 对永久代的垃圾回收（或元空间），避免由于永久代空间耗尽带来 Full GC。
6. 写在最后
hotspot 有这么多垃圾收集器，那么 Serial GC、Prallel GC、CMS GC 有什么不同呢？
如果想要最小化的使用内存和并行开销 就用 Serial GC
如果想要最大化的使用吞吐量 就用 Prallel GC
如果想要最小化的使用 GC 中断和停顿时间（低延迟） 就用 CMS GC
同时注意，在 Jdk9 中默认使用 G1 垃圾收集器,将 CMS 标记为废弃。在 Jdk14 中移除了 CMS 垃圾收集器。
还未添加个人签名 2021.07.24 加入
还未添加个人简介
评论