无法通过禁用 system.gc() 完全防止手动触发全局 full gc，但使用 -xx:+disableexplicitgc 可彻底忽略其调用；需配合代码清理、日志验证及监控闭环。
无法通过禁用 System.gc() 完全防止手动触发全局 Full GC，但可以显著降低其被意外调用的风险。Java 规范明确指出：System.gc() 是一个提示（hint），JVM 可以忽略它；不过在默认配置下，HotSpot JVM 通常会响应并发起一次 Full GC（尤其在 Serial、Parallel 收集器下）。真正“禁用”的方式不是删除调用，而是从 JVM 启动参数层面抑制其效果。
使用 -XX:+DisableExplicitGC 彻底忽略 System.gc()
这是最直接有效的方法。添加该参数后，HotSpot JVM 会静默忽略所有 System.gc() 和 Runtime.getRuntime().gc() 调用，不执行任何 GC 动作（包括 CMS 的 foreground GC 或 G1 的 explicit GC pause）。
- 适用于所有基于 HotSpot 的 JDK（8/11/17/21 等）
- 对
System.gc()的调用不会抛异常，也不会打日志（除非开启-XX:+PrintGCDetails，此时可能看到 “GC disabled” 类似提示） - 注意：ZGC 和 Shenandoah 在较新版本中也支持该参数，但需确认具体 JDK 版本文档
配合代码层治理：定位并移除显式 GC 调用
参数只是兜底，根本解法是清理代码中不必要的 System.gc()。这类调用常见于过时的性能优化习惯、资源释放误用或第三方库遗留逻辑中。
- 用 IDE 全局搜索
System.gc、Runtime.getRuntime().gc，逐个评估是否真有必要 - 特别检查单元测试、Demo 类、旧版工具类（如某些图像处理、大数组缓存清理逻辑）
- 若为兼容老 JVM 的“强制释放内存”意图，应改用更可靠方式：显式置 null + 减少引用 + 依赖正常对象生命周期
验证是否生效：运行时确认与监控
加了参数不等于一定起作用，需实测验证。
- 启动时加上
-XX:+PrintGCDetails -XX:+PrintGCTimeStamps，然后在代码中主动调用System.gc()，观察日志中是否出现 GC 日志行（如Full GC或Pause Full） - 使用 JMX 或
jstat -gc <pid></pid>监控FGC（Full GC 次数）列，在触发System.gc()前后确认数值未增加 - 注意：部分 GC 日志格式中，“Full GC (System)” 表示由显式调用触发；若该字样消失，说明已生效
替代方案：用 -XX:+ExplicitGCInvokesConcurrent 控制行为（仅限 CMS/G1）
如果因历史原因必须保留 System.gc() 调用（如无法修改的闭源依赖），又不想引发 Stop-The-World 的 Full GC，可考虑此参数：
- 对 CMS：使
System.gc()触发的是并发 GC（concurrent mode failure 除外） - 对 G1：触发的是 Mixed GC（非 Full GC），但仍有一定 STW
- ⚠️ 不推荐作为长期方案——它没禁用 GC，只是改变了类型；且在 JDK 14+ 中 CMS 已移除，G1 下该参数行为受限
不复杂但容易忽略：参数必须写在 JVM 启动命令中，不能运行时动态设置；同时确保没有其他脚本或容器配置覆盖该选项。真正稳定的 GC 行为，靠的是参数约束 + 代码洁癖 + 监控闭环。
