垃圾回收期选择G1还是CMS，需结合场景需求，CMS并发标记与清理停顿时间短，适合老年代较小、对延迟敏感的场景，但存在内存碎片问题，可能触发Full GC；G1基于Region划分，可预测停顿，支持大堆内存，动态调整回收范围，兼顾吞吐量与低延迟，适合多核、大内存场景，若堆内存小（如8GB内）且碎片容忍度高可选CMS；堆内存大（如16GB以上）或需严格停顿控制，G1更优，现代JDK中G1逐渐取代CMS，成为默认选择。
垃圾回收器选G1还是CMS？从原理到场景全面解析
在Java应用的性能优化中,垃圾回收（GC）器的选择直接关系到系统的吞吐量、延迟稳定性与资源利用效率，作为服务端场景曾经的“双雄”，CMS（Concurrent Mark Sweep）与G1（Garbage-First）是开发者绕不开的经典对比，本文将从两者核心原理、优缺点、适用场景切入，帮你理清“垃圾回收器选G1还是CMS”的决策逻辑。
先认识：CMS与G1是什么？
CMS：低延迟的“并发先驱”
CMS（Concurrent Mark Sweep）是Java历史上首个真正意义上的**低延迟**老年代回收器，自JDK 4引入后，在JDK 8之前长期作为服务端应用的默认选择，它基于“标记-清除”（Mark-Sweep）算法，核心目标是**最大限度缩短Stop-The-World（STW）时间**——通过让GC线程与用户线程并发执行大部分标记和清除工作，减少应用停顿。
工作流程拆解：
- 初始标记（STW）：仅标记GC Roots直接关联的对象，速度快（通常耗时几毫秒）；
- 并发标记：与应用线程并行，遍历对象图标记所有存活对象，耗时较长（占比最大）；
- 重新标记（STW）：修正并发标记期间因用户线程运行导致的新对象生成或引用变化，耗时较短；
- 并发清除：与应用线程并行，清除未被标记的死亡对象，释放内存空间。
核心优势：
- **并发占比高**：标记与清除阶段均可与用户线程并发，STW时间短（通常几十到一百毫秒），尤其适合对延迟敏感的场景（如Web服务、在线交易系统）；
- **算法简单**：实现逻辑清晰，在早期硬件资源有限时，内存回收效率相对较高。
致命缺陷：
