System.gc()无法用于发现内存泄漏，真正方法是通过jstat观察老年代持续增长与Full GC效果差、jmap -histo:live对比实例数异常增长、jmap生成堆转储后用MAT分析引用链。
System.gc() 本身不能用于发现内存泄漏，它既不提供诊断能力，也不影响泄漏判断逻辑。调用它只是向 JVM 发出一次“建议回收”的信号，JVM 完全可以忽略；即使触发了 GC，你也无法得知哪些对象没被回收、为什么没被回收。真正发现内存泄漏，靠的是观察 GC 后仍存活的对象是否异常增长，而不是催促 GC 发生。
用 jstat 观察 GC 行为与老年代趋势
内存泄漏的典型表现是老年代（Old Gen）使用率持续上升、Full GC 频次增加但回收效果差。System.gc() 的调用不会改变这一趋势，但它可能干扰判断——比如在测试中误以为“手动触发后内存没降下来就是泄漏”，其实只是掩盖了真实问题。
- 运行 jstat -gc <pid>，重点关注 OGC（Old Generation Capacity） 和 OU（Old Usage）：若 OU 持续攀升且每次 Full GC 后下降幅度很小，说明有对象长期驻留
- 配合 jstat -gcutil <pid> 3000 每 3 秒刷新一次，观察 FGC（Full GC 次数） 和 FGCT（Full GC 耗时） 是否随运行时间明显增长
- 注意：不要依赖 System.gc() 来“清空堆”后再看 jstat 输出——这会让数据失真，掩盖真实泄漏节奏
用 jmap 定位异常增长的活对象
真正要找的是“本不该长期存在却一直存活”的实例。System.gc() 对这类分析毫无帮助，反而可能让 jmap -histo:live 的结果看起来更“干净”，错过关键线索。
- 执行 jmap -histo:live <pid> 查看当前所有活跃对象的类统计，重点关注自定义业务类（如 User、Order、CacheItem）的 #instances 是否随请求/操作线性或指数增长
- 对比多次执行结果（间隔几分钟），如果某类实例数只增不减，且与业务逻辑不匹配（比如每处理一个请求就新增 10 个 Handler 实例），就是强泄漏信号
- 避免在调用 System.gc() 后立刻执行该命令——GC 建议未必生效，且人为干预会扰乱自然内存行为模式
用堆转储（Heap Dump）分析引用链
确认泄漏对象后，必须知道“谁在持有着它”。System.gc() 不产生任何引用信息，也不生成可分析的数据，只有堆快照才能揭示真实引用路径。
立即学习“Java免费学习笔记（深入）”；
- 用 jmap -dump:format=b,file=heap.hprof <pid> 生成堆转储文件（无需先调 System.gc()）
- 用 Eclipse MAT 或 VisualVM 打开，使用 “Leak Suspects Report” 或 “Dominator Tree”，定位大对象及其保留集
- 重点查看疑似泄漏对象的 “Paths to GC Roots”，确认是否存在静态集合、未注销监听器、ThreadLocal 未 remove 等典型持有链
别把 System.gc() 当监控手段
它不是监控工具，也不参与 JVM 监控体系。JConsole、JVisualVM、Prometheus + JMX 等真正监控方案，采集的是 GC 次数、内存池使用率、线程状态等客观指标，和是否调用 System.gc() 无关。
- 生产环境建议添加 -XX:+DisableExplicitGC 参数，禁用显式 GC 调用，避免干扰 GC 日志和监控曲线
- 某些压测脚本里用 System.gc() “重置堆状态”，仅适用于封闭可控场景，且需配套关闭显式 GC，否则会影响监控数据一致性
- JVM 监控的核心是“可观测性”：看内存怎么变、GC 怎么跑、对象怎么活——不是看代码里有没有写 System.gc()
