cms垃圾回收器旨在减少停顿时间，通过并发标记清除实现低延迟，但会占用更多cpu、产生内存碎片，并可能因浮动垃圾或内存泄漏导致oom，适用于对响应时间敏感的应用。
CMS 垃圾回收器主要目标是减少停顿时间，它尝试在应用程序运行的同时进行垃圾回收，但并非完全无停顿。简单来说，它是一种并发的、以牺牲吞吐量为代价来换取更短停顿时间的垃圾回收器。
CMS（Concurrent Mark Sweep）垃圾回收器，一款追求低停顿的垃圾回收器。它的核心在于尽可能地减少垃圾回收过程中的应用停顿时间，让用户感觉不到明显的卡顿。
CMS 工作原理详解
CMS 的工作流程主要分为以下几个阶段：
初始标记 (Initial Mark): 这个阶段会暂停所有应用程序线程（Stop-the-World, STW），但停顿时间很短，主要标记 GC Roots 能直接关联到的对象。速度很快，因为只处理直接关联的对象。
并发标记 (Concurrent Mark): 此阶段与应用程序线程并发执行，从初始标记阶段找到的对象开始，追踪所有可达对象。由于是并发执行，所以应用程序不会停顿。但这个阶段会消耗 CPU 资源，并且由于应用程序也在运行，可能会产生新的垃圾。
并发预清理 (Concurrent Preclean): 这个阶段也是并发执行的，用于处理在并发标记阶段新产生的垃圾（这些垃圾被称为“浮动垃圾”）。 它的目的是减少重新标记阶段的工作量。
重新标记 (Remark): 这个阶段会再次暂停所有应用程序线程（STW），用于修正并发标记期间因应用程序运行而导致标记发生变动的那一部分对象的标记记录。这个阶段的停顿时间比初始标记稍长，但通常比完全的垃圾回收要短。
并发清理 (Concurrent Sweep): 这个阶段与应用程序线程并发执行，清理所有被标记为垃圾的对象。这个阶段不会移动存活对象，因此会产生内存碎片。
并发重置 (Concurrent Reset): 这个阶段也是并发执行的，重置 CMS 内部状态，为下次垃圾回收做准备。
CMS 垃圾回收器的优缺点
- 优点： 停顿时间短，用户体验好，尤其是在对响应时间有要求的应用中。
-
缺点：
- CPU 占用高： 由于并发执行，CMS 会占用一部分 CPU 资源，导致应用程序吞吐量下降。
- 产生内存碎片： CMS 使用标记-清除算法，不会整理内存空间，因此会产生大量的内存碎片。当碎片过多时，可能会导致无法分配大块连续内存，从而提前触发 Full GC。
- 浮动垃圾： 并发标记阶段产生的垃圾，只能在下次 GC 时回收，这就是浮动垃圾。如果应用程序产生的垃圾速度过快，可能导致浮动垃圾过多，从而导致 Full GC。
何时应该选择 CMS 垃圾回收器？
CMS 适合对停顿时间有较高要求的应用，例如 Web 应用、交互式应用等。如果你的应用对 CPU 资源不敏感，并且能够容忍一定的内存碎片，那么 CMS 是一个不错的选择。
如何优化 CMS 垃圾回收器？
- 调整堆大小： 合理的堆大小可以减少 GC 的频率。
-
调整 CMS 触发阈值： 可以通过
-XX:CMSInitiatingOccupancyFraction
参数来调整 CMS 垃圾回收的触发阈值，即老年代空间使用率达到多少时触发 CMS GC。 - 使用更大的 Survivor 区： 更大的 Survivor 区可以减少对象进入老年代的概率，从而减少 CMS GC 的频率。
- 监控 GC 日志： 通过 GC 日志可以了解 GC 的情况，从而进行针对性的优化。
CMS 垃圾回收器与 G1 垃圾回收器有什么区别？
G1 (Garbage First) 是另一种垃圾回收器，它的目标也是减少停顿时间，但与 CMS 相比，G1 具有更好的性能和可预测性。
- 内存管理方式： CMS 使用传统的分代回收策略，而 G1 将堆划分为多个大小相等的区域（Region），每个 Region 可以是 Eden、Survivor 或 Old 区。
- 垃圾回收算法： CMS 使用标记-清除算法，会产生内存碎片，而 G1 使用复制算法，可以整理内存空间，减少碎片。
- 停顿时间： G1 可以更精确地控制停顿时间，并且在大多数情况下，G1 的停顿时间比 CMS 更短。
总的来说，G1 是 CMS 的替代者，在 Java 9 及更高版本中，G1 是默认的垃圾回收器。
CMS 垃圾回收器的参数有哪些？
CMS 垃圾回收器有很多参数可以调整，以下是一些常用的参数：
-XX:+UseConcMarkSweepGC
: 启用 CMS 垃圾回收器。-XX:CMSInitiatingOccupancyFraction=<percent>
: 设置老年代使用率达到多少时触发 CMS GC。默认值是 92%。-XX:+UseCMSCompactAtFullCollection
: 在 Full GC 时进行内存整理，减少内存碎片。-XX:CMSFullGCsBeforeCompaction=<n>
: 在进行多少次 Full GC 后进行一次内存整理。-XX:+CMSParallelRemarkEnabled
: 启用并行重新标记，可以减少重新标记阶段的停顿时间。-XX:ConcGCThreads=<n>
: 设置并发 GC 的线程数。
CMS 垃圾回收器的未来发展趋势是什么？
随着 G1 和 ZGC 等新型垃圾回收器的出现，CMS 的使用越来越少。在 Java 9 及更高版本中，G1 是默认的垃圾回收器。未来，CMS 可能会逐渐被淘汰。但是，了解 CMS 的工作原理对于理解垃圾回收机制仍然很有帮助。
CMS 垃圾回收器发生 OOM (OutOfMemoryError) 的原因有哪些？
OOM 并不一定意味着 CMS 本身有问题，而更多是程序运行过程中内存使用超出了 JVM 堆的限制。以下是一些常见原因：
- 内存泄漏： 程序中存在不再使用的对象，但仍然被引用，导致垃圾回收器无法回收。
- 堆大小不足： 应用程序需要的内存超过了 JVM 堆的大小。
- 大量对象存活时间过长： 大量对象在老年代存活，导致老年代空间不足。
- 浮动垃圾过多： 并发标记阶段产生的垃圾过多，导致老年代空间不足。
解决 OOM 问题需要综合分析 GC 日志、堆转储文件 (Heap Dump) 等信息，找出内存泄漏的根源，并进行相应的优化。
