-xx:cmsfullgcsbeforecompaction仅作用于serial old收集器，表示每n次其full gc后触发一次内存压缩；它与cms并发回收及碎片整理无关，不控制cms自身行为。
-XX:CMSFullGCsBeforeCompaction 这个参数**并不控制 CMS 并发回收过程中的内存压缩行为**，它实际作用的对象是 Serial Old 收集器——即 CMS 发生 Concurrent Mode Failure 后退化使用的后备收集器。
参数真实作用范围
该参数仅在以下场景生效：
- CMS 回收失败（例如并发标记未完成，老年代就已满），触发 Full GC；
- 此时 JVM 自动启用 Serial Old（单线程、标记-整理算法）作为兜底收集器；
- 而 -XX:CMSFullGCsBeforeCompaction=n 表示：每执行 n 次由 Serial Old 完成的 Full GC 后，下一次 Serial Old Full GC 将额外执行一次内存压缩（Compact）。
注意：这个“压缩”不是 CMS 自身的并发操作，而是 Serial Old 在 STW 阶段强制进行的、耗时较长的整理动作。
与 CMS 本身压缩无关的常见误解
很多人误以为该参数能影响 CMS 的并发清理或碎片整理，但事实是：
- CMS 默认使用 标记-清除（Mark-Sweep） 算法，不移动对象，必然产生内存碎片；
- CMS 自身的碎片整理由 -XX:+UseCMSCompactAtFullCollection 控制，且只在 CMS 触发的 Full GC（非 Concurrent Mode Failure 场景）后执行一次压缩；
- -XX:CMSFullGCsBeforeCompaction 对 CMS 的并发阶段（初始标记、并发标记、重新标记、并发清除）完全无影响；
- 它也不作用于 -XX:+CMSParallelRemarkEnabled 或 -XX:+UseConcMarkSweepGC 等 CMS 核心开关。
如何真正监控和应对 CMS 内存碎片
判断碎片是否成为瓶颈，不能依赖该参数，而应关注 GC 日志中的关键指标：
- Concurrent Mode Failure 次数：频繁出现说明老年代碎片严重，CMS 来不及回收就填满；
- promotion failed / concurrent mode failure：日志中直接提示晋升失败或并发失败；
- 老年代使用率波动剧烈但回收量小：例如老年代从 65% → 95% → 70%，但 CMS GC 后仅释放 5%，说明大量空间因碎片无法分配大对象；
- Full GC 频率上升且耗时变长：往往是 Serial Old 被反复触发，伴随明显 STW 延迟。
应对建议：
- 调低 -XX:CMSInitiatingOccupancyFraction（如设为 60~65），让 CMS 更早启动，预留更多连续空间；
- 开启 -XX:+UseCMSCompactAtFullCollection 并配合 -XX:CMSFullGCsBeforeCompaction=1（仅在确需 Serial Old 整理时用）；
- 更根本的解法：升级到 G1 或 ZGC，它们原生支持压缩或无碎片设计。
总结一句话
-XX:CMSFullGCsBeforeCompaction 是 Serial Old 的计数开关，不是 CMS 的碎片调控机制；监控 CMS 碎片，要盯日志里的 Concurrent Mode Failure 和老年代回收效率，而不是这个参数的数值。
