system.gc()不能排查内存泄漏，它仅是gc建议且不可靠；真正方法是用jstat、jmap和mat等工具分析存活对象及引用链，结合编码习惯规避静态引用、未注销监听器等问题。
System.gc() 不能用来排查内存泄漏，它既不可靠，也无诊断能力。调用它只是建议 JVM 进行垃圾回收，JVM 完全可以忽略；即使触发了 GC，你也无法得知哪些对象没被回收、为什么没被回收。真正排查内存泄漏，得靠工具和分析，而不是手动触发 GC。
内存泄漏的本质是“本该被回收的对象仍被引用”
Java 的 GC 机制本身很成熟，只要对象不再被任何活动线程或静态引用可达，就会被回收。内存泄漏发生时，通常是因为无意中持有了长生命周期的引用（比如静态集合、缓存未清理、监听器未注销、ThreadLocal 未 remove），导致对象无法释放。
- 静态 Map 存储业务对象但忘了清理 → 对象长期驻留堆中
- 注册了事件监听器却未在销毁时反注册 → GUI 或框架组件持续持有引用
- 使用 ThreadLocal 时只 set 不 remove → 线程复用（如线程池）导致对象跨请求残留
真正有效的排查手段：用工具定位“活对象”和“引用链”
要发现泄漏，关键不是让 GC 发生，而是观察 GC 后仍存活的对象——尤其是那些数量异常增长、本不该长期存在的实例。
- 用 jstat -gc
观察老年代（Old Gen）使用量是否持续上升、Full GC 频次增加 - 用 jmap -histo:live
查看当前存活对象的类统计，重点关注自定义类实例数是否随时间递增 - 生成堆转储（jmap -dump:format=b,file=heap.hprof
），用 VisualVM、JProfiler 或 Eclipse MAT 分析：谁在引用这些疑似泄漏对象？引用路径是否合理？
写代码时主动规避泄漏风险
预防比排查更高效。几个简单但关键的习惯：
- 静态集合类（如 static Map/List）务必配套清理逻辑，或改用 WeakHashMap
- 所有注册型 API（如 addListener、registerCallback）必须有对应的 unregister/remove 调用，最好用 try-finally 或 try-with-resources 封装
- ThreadLocal 使用后显式调用 remove()，尤其在使用线程池的场景下
- 避免在 Lambda 或匿名内部类中隐式捕获外部大对象（如 Activity、Context、Service），必要时用 WeakReference 包装
System.gc() 的唯一合理用途：性能测试中的可控对比
仅在极少数场景下可谨慎使用，比如做内存占用基准测试时，确保每次测量前堆状态尽量一致。但这属于测试辅助，与问题诊断无关，且需配合 -XX:+DisableExplicitGC 关闭显式 GC（防止干扰生产环境）。
不复杂但容易忽略：排查内存泄漏，核心是“找不该活的对象”，而不是“催 GC”。工具 + 引用分析 + 编码习惯，才是正解。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
