CMS（Concurrent Mark-Sweep）垃圾收集器是为了解决老年代垃圾回收问题而设计的一种低延迟的垃圾收集器。它的主要目标是在执行垃圾收集时尽量减少“Stop the World”事件的发生，从而降低应用的暂停时间。以下是CMS垃圾回收的基本流程：
CMS垃圾回收过程分为以下几个阶段：
- 初始标记（Initial Mark）：
- 这是一个短暂的“Stop the World”阶段，在此期间，CMS会标记直接从GC根（如栈上的局部变量、静态字段等）可访问的对象。
- 此阶段的目标是识别所有可能引用老年代对象的根集合，并对这些对象进行标记。
- 并发标记（Concurrent Mark）：
- 在这个阶段，CMS并行地遍历对象图，从初始标记阶段确定的所有存活对象开始，找到所有可达的对象。
- 由于这是并发执行的，所以应用程序可以继续运行，但可能会导致一些性能开销，因为需要同时执行应用线程和GC线程。
- 重新标记（Remark）：
- 又是一个短暂的“Stop the World”阶段。目的是完成标记工作，处理在并发标记阶段内由于程序活动而改变了的对象引用。
- 这个阶段确保所有存活的对象都被正确地标记，以便接下来的清理工作能够准确无误地进行。
- 并发清除（Concurrent Sweep）：
- 在这个阶段，CMS会移除那些不再使用的对象，释放它们占用的空间。
- 类似于并发标记，这也是一个与应用线程并发执行的过程，允许应用在此期间继续运行。
- 重置（Reset）：
- 清理完成后，CMS会对自身数据结构进行重置，准备下一次垃圾收集周期。
值得注意的是，尽管CMS旨在最小化“Stop the World”的影响，但在某些情况下，如堆内存几乎满载时，它仍可能发生完全的垃圾收集（Full GC），这会导致较长时间的应用暂停。
此外，CMS不进行任何压缩操作，这意味着它不会移动存活对象以消除内存碎片。因此，在长期运行的应用中，可能会遇到内存碎片化的问题，进而影响到应用性能。
为了缓解这些问题，JVM提供了多种参数来调整CMS的行为，例如通过-XX:CMSInitiatingOccupancyFraction来控制触发CMS收集的阈值，或使用-XX:+UseCMSCompactAtFullCollection在每次Full GC后进行一次压缩以减少内存碎片。
然而，随着Java的发展，G1收集器和其他现代垃圾收集器逐渐成为更受欢迎的选择，特别是在处理大堆内存的情况下。
THE END
