System.gc() 仅是建议JVM执行GC的信号，无法强制触发或清理堆外内存；配合VisualVM可观察其对堆内存的影响，但不影响Direct Memory。
System.gc() 不是内存释放的快捷键，而是一个容易被误用的“建议信号”。它既不能强制触发垃圾回收，更无法清理堆外内存。配合 VisualVM 使用时，关键不是靠它来“解决问题”，而是借它作为观察 GC 行为的一个可控扰动点——帮助你识别哪些内存真能被回收、哪些根本不受影响。
System.gc() 的真实作用与局限
调用 System.gc() 仅向 JVM 发出“建议执行 GC”的请求，JVM 可以忽略、延迟或合并执行。尤其在使用 G1、ZGC 等现代收集器时，该调用几乎不改变 GC 节奏。更重要的是：
- 它只影响堆内对象的可达性判定，对 DirectByteBuffer 分配的堆外内存完全无效
- 频繁调用反而可能干扰 GC 正常节奏，导致 Minor GC 提前触发或 Full GC 被意外诱发
- 日志中若出现 Full GC (System)，说明这次停顿正是由代码中显式调用引发，属于人为可控但需谨慎的事件
用 VisualVM 验证 System.gc() 是否生效
启动应用后，在 VisualVM 中连接目标进程，安装并打开 VisualGC 插件。操作步骤如下：
- 在应用中插入一行 System.gc()，例如在某个 HTTP 接口末尾添加
- 切换到 VisualGC 标签页，观察 “Young Gen” 和 “Old Gen” 曲线是否出现明显下降拐点
- 同步查看 “GC” 标签页中的 GC 日志时间戳，确认是否有新增的 GC 记录，类型是否为 Full GC (System)
- 对比堆外内存（Direct Memory）曲线——即使堆内存下降，Direct Memory 占用应保持不变，这能直观验证其不可回收性
替代 System.gc() 的合理做法
真正需要主动干预内存时，应转向更精准、更安全的方式：
- 对 DirectByteBuffer：显式调用 buffer.clear() + buffer = null，并确保 Cleaner 已注册；生产环境推荐使用 try-with-resources 封装的 Cleaner 或 PhantomReference 自定义回收逻辑
- 触发堆内存回收：优化对象生命周期，减少长引用链；必要时通过 -XX:+ExplicitGCInvokesConcurrent 让 System.gc() 触发并发 GC（仅限 CMS/G1），降低 STW 影响
- 监控驱动调优：依赖 VisualVM 的 VisualGC 实时曲线 + GC 日志分析，定位 Eden 区过小、Survivor 区过窄、老年代泄漏等根因，而非依赖手动 GC
实战中容易忽略的关键细节
很多问题其实藏在工具使用习惯里：
- VisualVM 默认不显示 Direct Memory，需在“监视”页勾选 “Native Memory Tracking” 并启用 JVM 参数 -XX:NativeMemoryTracking=summary
- 远程监控 Java 进程时，必须添加 JVM 启动参数：-Dcom.sun.management.jmxremote，否则 VisualGC 插件无法获取完整内存分代数据
- 堆 dump 与 GC 行为要结合看：一次 Full GC 后堆内存未明显下降，再做 heap dump，大概率能抓到无法被 GC Roots 到达的“悬挂对象”——比如静态 Map 缓存、未注销的监听器、线程局部变量残留
