内部类导致内存泄漏的本质是其隐式持有外部类的强引用，应通过MAT分析Path to GC Roots确认this$0引用链，并用静态内部类+WeakReference或及时清空引用修复。
内部类本身不会“被垃圾回收”来解决内存泄漏——真正的问题是：**内部类持有外部类的强引用，导致外部类无法被回收**。所以分析重点不是“内部类怎么被回收”，而是**如何判断、验证和切断这个不该存在的强引用链**。
看引用链是否构成 GC Roots 路径
Java 垃圾回收基于可达性分析：从 GC Roots（如线程栈、静态变量、JNI 引用等）出发，能到达的对象不被回收。如果一个非静态内部类实例被长期持有（比如注册为监听器、提交到线程池、存进静态集合），它就成为 GC Roots 的延伸路径，进而让其隐式持有的外部类实例也“可达”。
- 用 jmap -dump:format=b,file=heap.hprof
获取堆快照 - 用 Eclipse MAT 打开，查看 Leak Suspects Report，重点关注“dominator tree”中排在前列的外部类实例
- 右键该外部类实例 → Path to GC Roots → exclude weak/soft references，观察路径中是否包含某个匿名/非静态内部类 → 若有，即确认泄漏源头
区分静态 vs 非静态内部类的引用行为
非静态内部类（含匿名内部类）在编译时会自动生成一个隐藏字段 this$0，指向外部类实例；静态内部类没有该字段，不持引用。
- 反编译 class 文件（如 javap -c OuterClass\$1.class）可看到 aload_0 加载 this$0 的字节码
- 在 MAT 中查看内部类实例的属性，若存在 this$0: OuterClass 且值非 null，说明它正在强引用外部类
- 若该内部类本该短命（如一次点击回调），却出现在长时间存活的线程或静态容器中，就是典型泄漏场景
模拟与验证泄漏是否存在
写一个最小可复现案例，触发后强制 GC 并检查对象是否残留：
- 定义一个 Activity（或普通类）+ 匿名 Handler/Runnable/Callback
- 将该内部类提交给静态线程池或赋值给 static 变量
- 让外部类实例“理应结束”（如 Activity finish、局部对象方法返回）
- 调用 System.gc()（仅建议测试用），再用 MAT 检查外部类是否仍被持有
- 对比改用 static + WeakReference
后，外部类能否正常回收
修复后验证回收效果
修复不是加了 static 就完事，要确认引用链真正断开：
- 使用静态内部类 + 显式传参替代隐式 this$0
- 若需访问外部状态，改用 WeakReference
并在使用前判空 - 在内部类生命周期结束处（如 onDetachedFromWindow、onDestroy）主动清空对外部类的缓存引用
- 再次 dump 堆，确认原外部类实例不再出现在 “Path to GC Roots” 中，且数量随操作稳定不增长
本质上，这不是内部类的回收问题，而是你是否意识到并管理好了它对外部类的隐式绑定。切断这条绑定，外部类才能自然退出生命周期。
