-XX:CMSFullGCsBeforeCompaction 参数自 JDK 8u40 起被彻底移除，曾试图在 CMS 失败后触发压缩式 Full GC，但无法预防碎片、效果不可控，且与 CMS 并发设计冲突；真正治理需优化触发阈值、预留空间、避免大对象误入，并建议迁移到 G1 或 ZGC。
-XX:CMSFullGCsBeforeCompaction 这个参数在 CMS 垃圾收集器中**早已被废弃，且自 JDK 8u40 起彻底移除，JDK 9+ 中完全不可用**。它曾用于控制“执行多少次 Full GC 后触发一次压缩”，但实际效果不稳定、语义模糊，且与 CMS 的并发设计存在根本冲突——CMS 本身不进行内存压缩，依赖后续的 Serial Old 或 Parallel Old 来兜底，而该参数试图让 CMS “主动压缩”，逻辑上不可靠。
为什么这个参数不能解决 CMS 碎片问题
CMS 是基于“标记-清除”算法的收集器，不移动对象，因此必然产生内存碎片。当老年代剩余空间虽总量足够，却无法容纳一个大对象时，就会触发 Concurrent Mode Failure，进而退化为 Serial Old 的 Stop-the-World 全堆压缩式 Full GC——这才是真正造成长停顿的根源。
而 -XX:CMSFullGCsBeforeCompaction 并不会在 CMS 并发周期中执行压缩；它仅在 CMS 失败后、由后备收集器（如 Serial Old）执行 Full GC 时，按计数尝试触发一次带压缩的 Full GC。但这种“事后补救”既无法预防碎片，也无法保证时机，反而可能引入更多不可控停顿。
真正有效的 CMS 碎片治理方式
-
启用定期压缩式 Full GC：使用
-XX:+UseCMSCompactAtFullCollection（JDK 7/8 有效），配合-XX:CMSFullGCsBeforeCompaction=n（仅在启用前者时才有意义，且 n=1 表示每次 Full GC 都压缩）。但注意：这仍属兜底策略，不能替代容量与触发阈值优化。 -
主动降低 CMS 触发时机：调小
-XX:CMSInitiatingOccupancyFraction（例如设为 65~75），让 CMS 更早启动并发回收，避免老年代填得太满才行动，从源头减少碎片积累机会。 -
增大老年代预留空间：通过扩大堆总大小（
-Xmx）或调整新生代比例（-Xmn），确保老年代有足够连续空间容纳晋升对象，尤其防止大对象直接分配失败。 -
避免大对象频繁进入老年代：检查应用是否存在生命周期长的大数组、缓存结构或未及时释放的中间对象；必要时用
-XX:PretenureSizeThreshold控制大对象直接进老年代的阈值，使其更可控。
更务实的升级建议
CMS 在 JDK 9 中已被标记为废弃，JDK 14 正式移除。当前生产环境若仍在用 CMS 并受碎片困扰，**最直接有效的“优化”是迁移到 G1 或 ZGC**：
- G1 通过分区（Region）和可预测的混合回收，天然缓解碎片问题，支持
-XX:G1HeapRegionSize和-XX:MaxGCPauseMillis精细调控； - ZGC 在超大堆场景下保持毫秒级停顿，完全消除碎片导致的 Full GC 风险。
继续围绕 CMS 做参数修补，如同给一辆已停产的发动机换滤芯——能延缓故障，但无法改变技术路径的终点。
