内部类或匿名内部类导致的“垃圾回收卡死”实为外部类因this$0强引用无法回收，引发堆内存增长、频繁Full GC及OOM；需用MAT分析GC Roots路径、javap反编译验证、修复后二次dump确认。
内部类或匿名内部类引发的“垃圾回收卡死”其实是个误解——GC本身不会被卡住，真正的问题是：外部类对象因被内部类强引用而长期无法回收，导致堆内存持续增长，最终触发频繁 Full GC，表现为应用卡顿、OOM 或响应迟缓。排查核心不是看“GC是否运行”，而是确认“本该回收的对象为何还活着”。
用 MAT 定位泄漏源头：从 GC Roots 追踪 this$0 引用链
非静态内部类（含匿名类）编译后会自动生成一个隐藏字段 this$0，类型为外部类，且是强引用。只要这个内部类实例还被 GC Roots 可达，外部类就永远不回收。
- 用
jmap -dump:format=b,file=heap.hprof <pid></pid>抓取堆快照（建议在疑似泄漏后、触发 System.gc() 前 dump） - 用 Eclipse MAT 打开，先看 Leak Suspects Report，重点关注 dominator tree 中异常存活的 Activity、Fragment 或业务大对象
- 右键该对象 → Path to GC Roots → exclude all weak/soft/phantom references，观察路径中是否出现类似
somepackage.OuterClass$1.this$0的节点 - 若路径终点是静态变量（如
MyManager.sHandler）、线程栈（如Thread-5.localVariable）或 JNI 全局引用，则确认是内部类→this$0→外部类的强引用链未断
验证是否真由隐式引用导致：反编译 + 实时观测
光看 MAT 不够，需交叉验证代码行为与运行时状态是否一致。
- 用
javap -c OuterClass\$1.class查看字节码，确认是否存在aload_0加载this$0的指令（非静态内部类必有；静态内部类无） - 在 MAT 的 Inspector 面板中展开内部类实例，直接查看其字段：若有
this$0: OuterClass = 0x12345678且值非 null，说明强引用真实存在 - 写最小复现 Demo：让 Activity 启动后立即 finish，同时提交一个匿名 Runnable 到静态线程池；几秒后 dump，若 MAT 中仍能看到该 Activity 实例，且 Path to GC Roots 经由 Runnable → this$0，则结论成立
区分“回收慢”和“根本收不掉”：看对象年龄与晋升行为
频繁 GC 卡顿未必是泄漏，也可能是大量短命对象误入老年代，或 GC 参数不合理。需结合 GC 日志判断本质：
- 开启
-XX:+PrintGCDetails -XX:+PrintGCTimeStamps，观察日志中是否出现Full GC (Ergonomics)或Allocation Failure后长时间停顿 - 若老年代使用率持续 >90% 且每次 Full GC 后仅下降极小（如 0.5%），说明有大量对象跨代晋升后无法释放——大概率就是被内部类链路钉住的老对象
- 对比修复前后：把非静态 Handler 改为 static + WeakReference，再跑同样操作，若老年代占用稳定回落、Full GC 消失，即可确认原因为隐式强引用
修复后必须验证的三个动作
改完代码不等于问题消失，得用工具确认引用链确实断开。
-
清空静态持有：比如静态 Handler 要调用
removeCallbacksAndMessages(null)，静态集合要 clear()，不能只改内部类为 static -
检查 WeakReference 是否被正确使用：WeakReference
必须在内部类中作为成员变量持有，并在每次访问前判空；若只是局部 new 一次就丢弃，毫无意义 - 二次 dump 确认：修复后重跑相同流程，在 MAT 中搜索原外部类名，应搜不到实例，或仅剩 1–2 个（来自当前活跃 Activity），且 Path to GC Roots 不再经过任何内部类
