system.gc() 不会降低 jvm 内存占用，仅是回收建议；真实内存分析应依赖 gc 日志、jmx memory mbean、jstat 或 visualgc 等可观测指标，并禁用显式调用以暴露真实引用与泄漏问题。
System.gc() 不会直接降低 JVM 运行时内存占用，它只是向 JVM 发出一次回收建议，实际是否回收、回收多少、在哪一代回收，完全取决于当前堆状态和所用垃圾收集器。盲目依赖它做内存分析，反而会干扰真实行为、掩盖问题根源。
它不改变真实内存压力，只可能扰动观测结果
调用 System.gc() 后，你看到的“内存下降”未必代表对象被真正释放：
- Runtime.getRuntime().freeMemory() 和 totalMemory() 的差值受 JVM 堆伸缩策略影响，totalMemory() 可能收缩或维持不变，无法反映真实对象存活量
- Minor GC 后对象晋升到老年代，堆总使用量可能不降反升
- DirectByteBuffer 分配的堆外内存完全不受影响，但堆内曲线下降容易让人误判“内存已清”
- GC 日志中若出现 Full GC (System)，说明这次停顿由代码主动触发——这是人为引入的 STW 干扰项，不是系统自然节奏
真正可信的内存占用观测方式
要准确分析运行时内存占用，应绕过 System.gc()，转向底层可观测指标：
- 启用 GC 日志（如 -Xlog:gc*:gc.log:time,tags,level），关注每次 GC 类型、各代前后大小、回收量，而非是否调用了 gc()
- 通过 JMX 获取 java.lang:type=Memory MBean 的 HeapMemoryUsage.used 值，该值与 GC 日志一致，排除了 totalMemory() 动态伸缩的干扰
- 用 jstat -gc
实时查看 YGC/FGC 次数、各代容量与使用量，比反复调 gc() 更稳定可控 - 配合 VisualVM 的 VisualGC 插件，观察 Young Gen/Old Gen 曲线拐点，并同步核对 GC 日志时间戳，确认回收是否真实发生
它暴露的是引用关系，不是内存瓶颈
System.gc() 的价值不在“清内存”，而在“验证引用是否真正断开”：
- 在作用域内创建大对象（如 byte[50MB]），块结束即栈帧引用消失，再调 gc()，若 Old Gen 曲线明显下降，说明该对象未被静态缓存或 ThreadLocal 持有
- 若调用后 Eden 区没变化，但 Old Gen 占用持续增长，提示大量短生命周期对象正在晋升——应检查 SurvivorRatio 或对象年龄阈值
- 频繁调用后老年代仍不下降，大概率存在内存泄漏：static Map 缓存未清理、未 close 的流、ThreadLocal 泄漏等
禁用比依赖更接近真相
生产环境中，System.gc() 往往是性能问题的“遮羞布”。更有效的做法是：
- 启动参数加 -XX:+DisableExplicitGC，屏蔽所有显式调用，让 GC 回归自动节奏
- 用 jmap -histo
查看存活对象分布，定位长期驻留的大对象或异常类实例 - 结合堆 dump 分析工具（如 Eclipse MAT）识别支配树（Dominator Tree），找出不可达但未释放的根本原因
- 对 DirectByteBuffer，确保调用 buffer.cleaner().clean() 或使用 try-with-resources 封装，而非指望 System.gc() 加速 Cleaner 处理
