一文读懂 fgc之cms-实战篇
1. 前言
线上应用运行过程中可能会出现内存使用率较高，甚至达到95+仍然不触发fgc的情况，存在内存打满风险，持续触发fgc回收；或者内存占用率较低时触发了fgc，导致某些接口tp99，tp999上升，触发下游系统以及自身系统频繁告警。
2. java8场景下为什么要使用cms
在Java 8场景下，使用CMS（Concurrent Mark Sweep）收集器的原因主要基于以下几点：
2.1 CMS收集器的设计特性
并发垃圾收集：CMS收集器使用并发线程跟踪可达对象，以减少Major GC（即老年代垃圾收集）带来的暂停时间。它允许应用程序线程和垃圾收集线程在Major GC期间并发运行，从而降低了应用程序的停顿时间。
分代收集：CMS收集器也是基于“代”的收集器，支持Minor GC和Major GC。Minor GC可以与正在进行的Major GC交叉进行，提高了垃圾收集的效率。
两次主要停顿：CMS收集器在GC过程中会有两次短暂的停顿：初始化标记（initial mark pause）和再标记（remark pause）。初始化标记停顿较短，用于标记从GC root能直接访问到的对象；再标记停顿稍长，用于处理并发跟踪阶段中程序线程引用发生变化的对象。
浮动垃圾：由于并发GC期间对象状态可能发生变化，因此会产生浮动垃圾（Floating Garbage）。浮动垃圾的数量取决于并发收集周期的持续时间和应用程序引用更新的频率。可以通过增大老年代空间来缓解浮动垃圾带来的问题。
2.2 CMS收集器的适用场景
需要短暂停顿时间的应用：CMS收集器非常适合那些需要低停顿时间的应用程序，如大型数据应用和多处理器环境下的应用。在这些环境中，CMS收集器能够充分利用多处理器的优势，通过并发执行垃圾收集来降低应用程序的停顿时间。
偏好更短GC暂停时间的应用：对于那些能够忍受GC分享处理器资源，但希望有更短GC暂停时间的应用来说，CMS收集器是一个很好的选择。
2.3 注意事项
并发模式失败：如果CMS收集器无法在老年代满之前完成垃圾收集，或者老年代的可用空间无法满足某次分配操作，那么会发生并发模式失败（Concurrent Mode Failure），导致应用程序线程暂停并完成GC。
此时，可以通过调整CMS收集器的参数来避免并发模式失败。
3. cms触发的时机
这里我们仅介绍配置CMSInitiatingOccupancyFraction参数的场景（一般都会改这个参数的默认值）：如果大于阈值（默认92%，阈值参数为CMSInitiatingOccupancyFraction），则进行CMS GC。
那么这里说的阈值是什么呢？指的是老年代被使用的内存空间的阈值。
一定注意，这里说的是老年代被使用的内存空间，我们通过jvm监控一般看到的都是整个堆内存的占比，所以通过这个监控看到的fgc数据可能与CMSInitiatingOccupancyFraction设定不一致。这里我们可以结合精细化的监控来分析。
举个例子，在8C16G的机器上，假设堆内存为10000M，新生代为5000M，元空间为500M（元空间使用本地内存（即操作系统的内存），而不是堆内存，因此它的大小不再受限于JVM的堆内存设置。元空间主要用于存放类的元数据信息，包括类的名称、成员变量、方法等信息）。那么老年代大概就是5000M，如果设置了-XX:CMSInitiatingOccupancyFraction=75。结合上文，触发fgc的一种场景就是老年代占用达到3750M左右。
4. 如何根据运行情况调整fgc触发的时机
这里我们仅介绍CMSInitiatingOccupancyFraction作用的场景。如果我们设定了-XX:CMSInitiatingOccupancyFraction=75，可以观察一段时间线上应用的jvm监控。执行fgc时，如果堆内存整体使用率较低，这时我们可以适当增大CMSInitiatingOccupancyFraction延迟fgc触发的时机再观察调整，比如先增加到80；如果堆内存整体使用率较高，或使用率较高时仍不触发fgc，那么就需要考虑减小CMSInitiatingOccupancyFraction以加快fgc触发的时机，比如先调到70。
5. 一切的理论都要基于实践进行验证
大部分开发者可能在部署时很少关注jvm参数，或者关注的较少，大都其他地复制直接使用。但是线上运行场景繁杂，统一的参数并不能满足所有的场景。这时我们就需要结合实际的监控 + 理论来不断的调整，直到应用达到最佳运行状态。比如调整增大堆内存以延缓gc，增大新生代以减少ygc从而提高tp999，调整CMSInitiatingOccupancyFraction适配。
我负责有个toC的大流量应用，在过年期间出现流量升高，tp999上升，部分扩容后只是短暂缓解了问题，考虑随意扩容可能造成机器过度浪费，于是先降低限流值保障稳定的同时寻求其他方案。观察tp999上升的机器，可以发现jvm监控数据都出现了多次的ygc，于是考虑用一个分组来实验，调整新生代大小来降低ygc的频率。实验运行一段时后果然tp999稳定了很多，于是逐步灰度到全量的机器，保障了线上接口的稳定性。
