cms在jdk 14+中已被彻底移除，强制使用会报“unrecognized vm option 'useconcmarksweepgc'”；升级至jdk 17/21/25必须替换为g1等替代方案，g1推荐以-xx:maxgcpausemillis为核心调优参数。
CMS 已彻底不可用，必须换，不是“要不要换”，而是“不换就起不来”。JDK 14 起 CMS 就被完全移除，哪怕你硬加 -XX:+UseConcMarkSweepGC，JVM 启动会直接报错：Unrecognized VM option 'UseConcMarkSweepGC'。如果你的旧项目还在 JDK 8 或 JDK 11 上跑 CMS，现在升级 JDK（比如到 17/21/25），第一步就是面对这个现实——CMS 没了，得选替代方案。
确认当前 JDK 版本和 CMS 是否真在运行
别凭印象判断。很多团队以为“用了 JDK 11 就默认 G1”，结果一查发现还是 Serial 或 Parallel——CMS 同样可能只是配置残留、未生效，或被其他参数覆盖。
- 查进程真实参数：
ps -ef | grep java，看有没有-XX:+UseConcMarkSweepGC；没有 ≠ 没用，可能写在脚本里但没生效 - 查 JVM 实际启用的 GC：
java -XX:+PrintCommandLineFlags -version，输出里会明确写UseConcMarkSweepGC或UseG1GC - 启动时加日志验证：
-XX:+PrintGCDetails -XX:+PrintGCDateStamps，日志首行会显示Using CMS或类似字样；如果看到Using G1或Using Parallel，说明 CMS 根本没启用
G1 是最稳妥的 CMS 替代选项，但不能直接照搬参数
G1 和 CMS 都主打低延迟，但机制完全不同：CMS 是标记-清除（不整理，靠并发避免 STW），G1 是标记-复制+区域化（必须整理，靠预测停顿控制 STW）。直接把 CMS 的 -XX:CMSInitiatingOccupancyFraction 换成 G1 的 -XX:InitiatingHeapOccupancyPercent，效果往往更差。
- G1 不需要调
-Xmn固定新生代大小——它动态决定回收哪些 Region，设了反而干扰自适应逻辑 - 目标停顿是 G1 的核心入口：
-XX:MaxGCPauseMillis=200（单位毫秒），建议从 200 开始试，再按实际 GC 日志微调 - CMS 常用的
-XX:ParallelCMSThreads在 G1 里对应的是-XX:ConcGCThreads，但 G1 默认会根据 CPU 核数算，一般不用手动设 - 如果老年代晋升频繁，优先检查对象生命周期（比如缓存没清理、Stream.toList() 生成大集合），而不是加
-XX:G1OldCSetRegionThresholdPercent
ZGC 或 Shenandoah 只在特定场景值得上，别为“新”而上
ZGC 和 Shenandoah 确实能压到
- ZGC 必须配
-XX:+UnlockExperimentalVMOptions（JDK 17–20），JDK 21+ 才默认解锁；Shenandoah 在 JDK 17 中仍需该参数，JDK 21 起才稳定 - ZGC 对堆大小敏感：低于 16GB 时，G1 往往更稳；ZGC 的优势在 32GB+ 堆且延迟 SLA 卡死在 10ms 内的场景
- 如果应用大量使用 JNI、Finalizer 或 JVMTI agent（比如某些老监控 SDK），ZGC/ Shenandoah 可能触发意外 Full GC 或崩溃，务必在预发全链路压测
- 迁移路径建议：CMS → G1（验证功能+稳定性）→ ZGC（仅当 G1 无法满足延迟指标且堆 ≥32GB）
真正容易被忽略的点是：CMS 时代很多“调优技巧”其实是掩盖问题的权宜之计，比如靠 -XX:CMSInitiatingOccupancyFraction=70 提前触发并发收集来躲 Full GC，本质是老年代对象堆积太多。迁移到 G1 后，如果还频繁 Mixed GC 或退化为 Full GC，别急着调 G1 参数，先用 jstat -gc 或 GC 日志看 G1 Evacuation Pause 和 G1 Humongous Allocation 是否异常——90% 的“G1 不如 CMS”问题，根源在代码层的对象分配模式，不在 GC 本身。
