JVM调优篇-03

1.说说 CMS 收集器的特点?

CMS (Concurrent Mark Sweep):收集器是一种以获取最短回收停顿时间为目标的收集器。目前很大一部分的 Java 应用集中在互联网网站或者基于浏览器的 B/S 系统的服务端上，这类应用通常都会较为关注服务的响应速度，希望系统停顿时间尽可能短，以给用户带来良好的交互体验。 CMS 收集器就非常符合这类应用的需求。

从名字(包含“Mark Sweep”)上就可以看出 CMS 收集器是基于标记-清除算法实现的，它的运作过程相对于前面几种收集器来说要更复杂一些，整个过程分为四个步骤，包括：

1. 初始标记(CMS initial mark)
2. 并发标记(CMS concurrent mark)
3. 重新标记(CMS remark)
4. 并发清除(CMS concurrent sweep)

其中初始标记、重新标记这两个步骤仍然需要“Stop The World”。初始标记仅仅只是标记一下 GC Roots 能直接关联到的对象，速度很快；并发标记阶段就是从 GC Roots 的直接关联对象开始遍历整个对象图的过程，这个过程耗时较长但是不需要停顿用户线程，可以与垃圾收集线程一起并发运行；而重新标记阶段则是为了修正并发标记期间，因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间通常会比初始标记阶段稍长一些，但也远比并发标记阶段的时间短；最后是并发清除阶段，清理删除掉标记阶段判断的已经死亡的对象，由于不需要移动存活对象，所以这个阶段也是可以与用户线程同时并发的。标记清除算法.

2.CMS 收集器的缺点?

CMS 是一款优秀的收集器，它最主要的优点在名字上已经体现出来:并发收集、低停顿，一些官方公开文档里面也称之为“并发低停顿收集器”(Concurrent Low Pause Collector)。 CMS 收集器是 HotSpot 虚拟机追求低停顿的第一次成功尝试，但是它还远达不到完美的程度，至少有以下三个明显的缺点：

首先， CMS收集器对处理器资源非常敏感。事实上，面向并发设计的程序都对处理器资源比较敏感。在并发阶段，它虽然不会导致用户线程停顿，但却会因为占用了一部分线程(或者说处理器的计算能力)而导致应用程序变慢，降低总吞吐量。 CMS 默认启动的回收线程数是(处理器核心数量+3)/4，也就是说，如果处理器核心数在四个或以上，并发回收时垃圾收集线程只占用不超过 25%的处理器运算资源，并且会随着处理器核心数量的增加而下降。但是当处理器核心数量不足四个时， CMS 对用户程序的影响就可能变得很大。如果应用本来的处理器负载就很高，还要分出一半的运算能力去执行收集器线程，就可能导致用户程序的执行速度忽然大幅降低。为了缓解这种情况，虚拟机提供了一种称为“增量式并发收集器”(Incremental Concurrent Mark Sweep/i-CMS)的 CMS 收集器变种，所做的事情和以前单核处理器年代 PC 机操作系统靠抢占式多任务来模拟多核并行多任务的思想一样，是在并发标记、清理的时候让收集器线程、用户线程交替运行，尽量减少垃圾收集线程的独占资源的时间，这样整个垃圾收集的过程会更长，但对用户程序的影响就会显得较少一些，直观感受是速度变慢的时间更多了，但速度下降幅度就没有那么明显。实践证明增量式的 CMS 收集器效果很一般，从 JDK 7 开始，i-CMS 模式已经被声明为“deprecated”，即已过时不再提倡用户使用，到 JDK 9 发布后 i-CMS 模式被完全废弃。

然后，由于CMS收集器无法处理“浮动垃圾”(Floating Garbage)，有可能出现“Concurrent Mode Failure”失败进而导致另一次完全“Stop The World”的 Full GC 的产生。在 CMS 的并发标记和并发清理阶段，用户线程是还在继续运行的，程序在运行自然就还会伴随有新的垃圾对象不断产生，但这一部分垃圾对象是出现在标记过程结束以后，CMS 无法在当次收集中处理掉它们，只好留待下一次垃圾收集时再清理掉。这一部分垃圾就称为“浮动垃圾”。同样也是由于在垃圾收集阶段用户线程还需要持续运行，那就还需要预留足够内存空间提供给用户线程使用，因此 CMS 收集器不能像其他收集器那样等待到老年代几乎完全被填满了再进行收集，必须预留一部分空间供并发收集时的程序运作使用。在 JDK 5 的默认设置下， CMS 收集器当老年代使用了 68%的空间后就会被激活，这是一个偏保守的设置，如果在实际应用中老年代增长并不是太快，可以适当调高参数-XX： CMSInitiatingOccu-pancyFraction 的值来提高 CMS 的触发百分比，降低内存回收频率，获取更好的性能。到了 JDK 6 时， CMS 收集器的启动阈值就已经默认提升至 92%。但这又会更容易面临另一种风险:要是 CMS 运行期间预留的内存无法满足程序分配新对象的需要，就会出现一次“并发失败”(Concurrent Mode Failure)，这时候虚拟机将不得不启动后备预案：冻结用户线程的执行，临时启用 Serial Old 收集器来重新进行老年代的垃圾收集，但这样停顿时间就很长了。所以参数-XX：CMSInitiatingOccupancyFraction 设置得太高将会很容易导致大量的并发失败产生，性能反而降低，用户应在生产环境中根据实际应用情况来权衡设置。

还有最后一个缺点， CMS是一款基于“标记-清除”算法实现的收集器，如果对前面对垃圾回收器算法讲解还有印象的话，就可能想到这意味着收集结束时会有大量空间碎片产生。空间碎片过多时，将会给大对象分配带来很大麻烦，往往会出现老年代还有很多剩余空间，但就是无法找到足够大的连续空间来分配当前对象，而不得不提前触发一次 Full GC 的情况。为了解决这个问题， CMS 收集器提供了一个-XX：+UseCMS-CompactAtFullCollection 开关参数(默认是开启的，此参数从 JDK 9 开始废弃)，用于在 CMS 收集器不得不进行 Full GC 时开启内存碎片的合并整理过程，由于这个内存整理必须移动存活对象，是无法并发的。这样空间碎片问题是解决了，但停顿时间又会变长，因此虚拟机设计者们还提供了另外一个参数-XX： CMSFullGCsBeforeCompaction(此参数从 JDK 9 开始废弃)，这个参数的作用是要求 CMS 收集器在执行过若干次(数量由参数值决定)不整理空间的 Full GC 之后，下一次进入 Full GC 前会先进行碎片整理(默认值为 0，表示每次进入 Full GC 时都进行碎片整理)。只能预防，不能根治。

3.CMS GC 失败后的预案

如果 CMS 运行期间预留的内存无法满足程序需要，那么就会出现一次“Concurrent Mode Failure”失败，此时 JVM 将启动后备预案：
使用 Serial Old 收集器重新对老年代进行 gc，这样一来，停顿时间就会很长。

4.CMS GC 的两种模式

在 Java 的 CMS（Concurrent Mark-Sweep）垃圾回收器中，存在两种不同的模式：后台模式（Background Mode）和前台模式（Foreground Mode），用于不同阶段的垃圾回收操作。

后台模式（Background Mode）:

• 后台模式是 CMS 垃圾回收器的默认模式，也称为并发模式（Concurrent Mode）。
• 在后台模式下，垃圾回收器会尽量减少对应用程序线程的影响，通过在大部分 GC 过程中与应用程序并发执行，以减少停顿时间。
• 后台模式中的垃圾回收包括：初始标记、并发标记、重新标记和并发清理等阶段。其中，初始标记和重新标记需要暂停应用程序线程，但停顿时间较短；而并发标记和并发清理阶段会与应用程序线程并发执行，不会暂停应用程序的执行。

前台模式（Foreground Mode）:

• 前台模式也称为 STW（Stop-The-World）模式，是 CMS 垃圾回收器的一部分，用于在并发标记阶段完成之后进一步完成 GC 过程。
• 前台模式会在执行并发标记后，暂停所有应用程序线程，进行重新标记和并发清理的最后阶段，以确保回收所有被标记为垃圾的对象。
• 前台模式的停顿时间通常比后台模式中的并发标记和并发清理阶段的停顿时间更长，因为在前台模式下，应用程序线程必须等待垃圾回收完成。