不可错过的 Java CMS 学习笔记

引子

带着问题去学习一个东西，才会有目标感，我先把一直以来自己对CMS的一些疑惑罗列了下，希望这篇学习笔记能解决掉这些疑惑，希望也能对你有所帮助。

1. CMS出现的初衷、背景和目的？

2. CMS的适用场景？

3. CMS的trade-off是什么?优势、劣势和代价

4. CMS会回收哪个区域的对象？

5. CMS的GC Roots包括那些对象？

6. CMS的过程？

7. CMS和Full gc是不是一回事？

8. CMS何时触发？

9. CMS的日志如何分析？

10. CMS的调优如何做？

11. CMS扫描那些对象？

12. CMS和CMS collector的区别？

13. CMS的推荐参数设置？

14. 为什么ParNew可以和CMS配合使用，而Parallel Scanvenge不可以？

一、基础知识

1. CMS收集器：Mostly-Concurrent收集器，也称并发标记清除收集器（Concurrent Mark-Sweep GC，CMS收集器），它管理新生代的方式与Parallel收集器和Serial收集器相同，而在老年代则是尽可能得并发执行，每个垃圾收集器周期只有2次短停顿。

2. 我之前对CMS的理解，以为它是针对老年代的收集器。今天查阅了《Java性能优化权威指南》和《Java性能权威指南》两本书，确认之前的理解是错误的。

3. CMS的初衷和目的：为了消除Throught收集器和Serial收集器在Full GC周期中的长时间停顿。

4. CMS的适用场景：如果你的应用需要更快的响应，不希望有长时间的停顿，同时你的CPU资源也比较丰富，就适合适用CMS收集器。

二、CMS的过程

CMS的正常过程

这里我们首先看下CMS并发收集周期正常完成的几个状态。

1. （STW）初始标记：这个阶段是标记从GcRoots直接可达的老年代对象、新生代引用的老年代对象，就是下图中灰色的点。这个过程是单线程的。

2. 并发标记：由上一个阶段标记过的对象，开始tracing过程，标记所有可达的对象，这个阶段垃圾回收线程和应用线程同时运行，如上图中的黄色的点。在并发标记过程中，应用线程还在跑，因此会导致有些对象会从新生代晋升到老年代、有些老年代的对象引用会被改变、有些对象会直接分配到老年代，这些受到影响的老年代对象所在的card会被标记为dirty，用于重新标记阶段扫描。这个阶段过程中，老年代对象的card被标记为dirty的可能原因，就是下图中绿色的线：

3. 预清理：预清理，也是用于标记老年代存活的对象，目的是为了让重新标记阶段的STW尽可能短。这个阶段的目标是在并发标记阶段被应用线程影响到的老年代对象，包括：（1）老年代中card为dirty的对象；（2）幸存区(from和to)中引用的老年代对象。因此，这个阶段也需要扫描新生代+老年代。【PS：会不会扫描Eden区的对象，我看源代码猜测是没有，还需要继续求证】

4. 可中断的预清理：这个阶段的目标跟“预清理”阶段相同，也是为了减轻重新标记阶段的工作量。可中断预清理的价值：在进入重新标记阶段之前尽量等到一个Minor GC，尽量缩短重新标记阶段的停顿时间。另外可中断预清理会在Eden达到50%的时候开始，这时候离下一次minor gc还有半程的时间，这个还有另一个意义，即避免短时间内连着的两个停顿，如下图资料所示：在预清理步骤后，如果满足下面两个条件，就不会开启可中断的预清理，直接进入重新标记阶段：

   如果不满足上面两个条件，则进入可中断的预清理，可中断预清理可能会执行多次，那么退出这个阶段的出口有两个（源码参见下图）：

• 设置了CMSMaxAbortablePrecleanLoops，并且执行的次数超过了这个值，这个参数的默认值是0；

• CMSMaxAbortablePrecleanTime，执行可中断预清理的时间超过了这个值，这个参数的默认值是5000毫秒。 如果是因为这个原因退出，gc日志打印如下：

  有可能可中断预清理过程中一直没等到Minor gc，这时候进入重新标记阶段的话，新生代还有很多活着的对象，就回导致STW变长，因此CMS还提供了 CMSScavengeBeforeRemark 参数，可以在进入重新标记之前强制进行依次Minor gc。

• Eden的使用空间大于“CMSScheduleRemarkEdenSizeThreshold”，这个参数的默认值是2M；

• Eden的使用率大于等于“CMSScheduleRemarkEdenPenetration”，这个参数的默认值是50%。

CMS的异常情况

上面描述的是CMS的并发周期正常完成的情况，但是还有几种CMS并发周期失败的情况：

1. 并发模式失败（Concurrent mode failure）：CMS的目标就是在回收老年代对象的时候不要停止全部应用线程，在并发周期执行期间，用户的线程依然在运行，如果这时候如果应用线程向老年代请求分配的空间超过预留的空间（担保失败），就回触发concurrent mode failure，然后CMS的并发周期就会被一次Full GC代替——停止全部应用进行垃圾收集，并进行空间压缩。如果我们设置了 UseCMSInitiatingOccupancyOnly 和 CMSInitiatingOccupancyFraction 参数，其中 CMSInitiatingOccupancyFraction 的值是70，那预留空间就是老年代的30%。

2. 晋升失败：新生代做minor gc的时候，需要CMS的担保机制确认老年代是否有足够的空间容纳要晋升的对象，担保机制发现不够，则报concurrent mode failure，如果担保机制判断是够的，但是实际上由于碎片问题导致无法分配，就会报晋升失败。

3. 永久代空间（或 Java 8的元空间）耗尽，默认情况下,CMS不会对永久代进行收集，一旦永久代空间耗尽，就回触发Full GC。

三、CMS的调优

1. 针对停顿时间过长的调优 首先需要判断是哪个阶段的停顿导致的，然后再针对具体的原因进行调优。使用CMS收集器的JVM可能引发停顿的情况有：（1）Minor gc的停顿；（2）并发周期里初始标记的停顿；（3）并发周期里重新标记的停顿；（4）Serial-Old收集老年代的停顿；（5）Full GC的停顿。其中并发模式失败会导致第（4）种情况，晋升失败和永久代空间耗尽会导致第（5）种情况。

2. 针对并发模式失败的调优

• 想办法增大老年代的空间，增加整个堆的大小，或者减少年轻代的大小

• 以更高的频率执行后台的回收线程，即提高CMS并发周期发生的频率。设置 UseCMSInitiatingOccupancyOnly 和 CMSInitiatingOccupancyFraction 参数，调低 CMSInitiatingOccupancyFraction 的值，但是也不能调得太低，太低了会导致过多的无效的并发周期，会导致消耗CPU时间和更多的无效的停顿。通常来讲，这个过程需要几个迭代，但是还是有一定的套路，参见《Java性能权威指南》中给出的建议，摘抄如下：

  对特定的应用程序，该标志的更优值可以根据 GC 日志中 CMS 周期首次启动失败时的值得到。具体方法是，在垃圾回收日志中寻找并发模式失效，找到后再反向查找 CMS 周期最近的启动记录，然后根据日志来计算这时候的老年代空间占用值，然后设置一个比该值更小的值。

• 增多回收线程的个数 CMS默认的垃圾收集线程数是 （CPU个数 + 3）/4 ，这个公式的含义是：当CPU个数大于4个的时候，垃圾回收后台线程至少占用25%的CPU资源。举个例子：如果CPU核数是1~4个，那么会有1个CPU用于垃圾收集，如果CPU核数是5~8个，那么久会有2个CPU用于垃圾收集。

四、CMS的trade-off是什么？

1. 优势

• 低延迟的收集器：几乎没有长时间的停顿，应用程序只在Minor gc以及后台线程扫描老年代的时候发生极其短暂的停顿。

• 更高的CPU使用：必须有足够的CPU资源用于运行后台的垃圾收集线程，在应用程序线程运行的同时扫描堆的使用情况。【PS：现在服务器的CPU资源基本不是问题，这个点可以忽略】

• CMS收集器对老年代收集的时候，不再进行任何压缩和整理的工作，意味着老年代随着应用的运行会变得 碎片化 ；碎片过多会影响大对象的分配，虽然老年代还有很大的剩余空间，但是没有连续的空间来分配大对象，这时候就会触发 Full GC 。CMS提供了两个参数来解决这个问题：（1） UseCMSCompactAtFullCollection ，在要进行Full GC的时候进行内存碎片整理；（2） CMSFullGCsBeforeCompaction ，每隔多少次不压缩的Full GC后，执行一次带压缩的Full GC。

• 会出现 浮动垃圾 ；在并发清理阶段，用户线程仍然在运行，必须预留出空间给用户线程使用，因此CMS比其他回收器需要更大的堆空间。

五、几个问题的解答

1. 为什么ParNew可以和CMS配合使用，而Parallel Scanvenge不可以？ 答：这个跟Hotspot VM的历史有关，Parallel Scanvenge是不在“分代框架”下开发的，而ParNew、CMS都是在分代框架下开发的。

2. CMS中minor gc和major gc是顺序发生的吗？ 答：不是的，可以交叉发生，即在并发周期执行过程中，是可以发生Minor gc的，这个找个gc日志就可以观察到。

3. CMS的并发收集周期合适触发？ 由下图可以看出，CMS 并发周期触发的条件有两个：

• 阈值检查机制：老年代的使用空间达到某个阈值，JVM的默认值是92%（jdk1.5之前是68%，jdk1.6之后是92%），或者可以通过CMSInitiatingOccupancyFraction和UseCMSInitiatingOccupancyOnly两个参数来设置；这个参数的设置需要看应用场景，设置得太小，会导致CMS频繁发生，设置得太大，会导致过多的并发模式失败。例如

• 动态检查机制：JVM会根据最近的回收历史，估算下一次老年代被耗尽的时间，快到这个时间的时候就启动一个并发周期。设置 UseCMSInitiatingOccupancyOnly 这个参数可以将这个特性关闭。

参考资料

1. 从实际案例聊聊Java应用的GC优化

2. 理解CMS垃圾回收日志

3. 图解CMS垃圾回收机制，你值得拥有

4. 为什么CMS虽然是老年代的gc，但仍要扫描新生代的?

5. R大对GC roots的概念的解释

6. Introduce to CMS Collector

7. 《深入理解Java虚拟机》

8. 《Java性能权威指南》

9. Oracle的GC调优手册

10. what-is-the-threshold-for-cms-old-gc-to-be-triggered

11. Frequently Asked Questions about Garbage Collection in the Hotspot Java VirtualMachine

12. Java SE HotSpot at a Glance

13. xxfox：PerfMa的参数调优神器

14. 详解CMS垃圾回收机制

15. ParNew和PSYoungGen和DefNew是一个东西么？

16. Java SE的内存管理白皮书