-xx:+usecmscompactatfullcollection 会在full gc后串行执行老年代压缩，导致stw时间显著延长；它不预防gc触发、不缩短核心回收时间，仅事后增加高开销操作，得不偿失。
-XX:+UseCMSCompactAtFullCollection 这个参数的本意是：在每次 Full GC 后，强制对老年代执行一次内存碎片整理（compaction），以缓解 CMS 因“标记-清除”算法导致的空间碎片问题。但它的实际效果往往适得其反——不仅不能稳定降低停顿时间，反而显著延长 Full GC 的总耗时。
为什么开启后会拉长 Full GC 停顿？
CMS 本身不进行压缩，所以老年代内存会逐渐离散。该参数触发的 compaction 并非并发执行，而是在 Full GC 完成后的 STW 阶段串行进行，且必须遍历整个老年代存活对象、逐个移动并更新引用。这意味着：
- 它把原本已结束的 Full GC（如 CMS fallback 触发的 Serial Old 收集）又额外追加了一轮“全堆扫描 + 对象搬迁 + 引用修正”操作
- 移动对象数量越多（即老年代存活率越高），耗时越长；在大堆（如 >4GB）、高存活率场景下，compaction 阶段可能比 GC 本身还慢数倍
- 所有应用线程持续被挂起，无法响应任何请求，直接放大 STW 影响
它解决的问题和代价严重不匹配
CMS 碎片问题真正危险的是“晋升失败（promotion failed）”或“并发模式失败（concurrent mode failure）”，这些会直接触发 Full GC。而 compaction 并不能预防这些失败，它只在失败发生、Full GC 已经执行完之后才介入。换句话说：
- 它不减少 Full GC 触发次数
- 它不缩短单次 Full GC 的核心回收时间
- 它只在“事后”多干一件高开销的事，徒增停顿
更合理的替代方案
与其依赖这个低效的补救机制，不如从根源规避碎片风险：
- 调小 -XX:CMSInitiatingOccupancyFraction，让 CMS 更早启动并发收集，避免老年代填得太满
- 增大老年代空间（-Xmx 和 -XX:MaxTenuringThreshold 配合），降低对象过早晋升比例
- 监控 concurrent mode failure 和 promotion failed 日志频次，针对性调优，而非盲目加 compaction
- 若碎片已成为常态瓶颈，应考虑迁移到 G1 或 ZGC —— 它们原生支持区域化压缩，无需额外 STW 整理
这个参数在 JDK 7/8 时代曾被误用为“CMS 碎片救星”，但生产实践反复证明：它用确定的、可量化的停顿增长，去换取不确定的、边际递减的碎片改善，得不偿失。
