内部类为什么容易引发内存泄漏
Java中的非静态内部类（包括匿名内部类）有一个容易被忽视的特性：每个内部类实例都会隐式持有一个指向外部类对象的引用，这个引用在编译后体现为构造方法传入的this$0字段。这个特性本身是为了让内部类能够访问外部类的成员变量和方法，但一旦外部类的生命周期很长，问题就来了。
举个例子，一个Activity或者一个Spring单例Bean中定义了一个匿名内部类，用于监听器或者异步任务。如果这个内部类对象被注册到某个全局性的地方，比如静态集合、长生命周期的线程池、系统监听器列表，那么即使外部类本该被销毁了，垃圾回收器也无法回收它。因为从GC Roots出发，总能通过引用链找到内部类，再通过内部类隐式引用找到外部类。
更隐蔽的情况是，泄漏的往往不只是外部类本身。外部类可能还持有大量成员变量，比如大集合、位图、连接对象等，这些全部会被连带钉在内存里。一次泄漏看起来只泄漏了一个小对象，实际泄漏的可能是几兆甚至几十兆。
垃圾回收的可达性原理与泄漏判定
要理解泄漏分析，得先回到垃圾回收的基本判定逻辑。主流虚拟机使用的是可达性分析：从GC Roots（虚拟机栈中的引用、静态变量、JNI引用、活跃线程等）出发遍历对象图，能到达的对象视为存活，到达不了的对象才会被回收。也就是说，一个对象是否被回收，不取决于代码逻辑上是否还需要它，而取决于引用链上是否还有强引用。
由此可以得出内部类泄漏的判定方法：如果你确认某个外部类对象在业务上已经不需要了，但通过工具仍然能在内存中找到它，并且引用链的路径中出现了它自己的内部类，那基本可以断定是内部类引用导致的泄漏。典型的引用链长这样：GC Root（如线程池工作线程）指向Runnable匿名类实例，匿名类实例的this$0字段指向外部类，外部类再指向它持有的大对象。
下面构造一个典型的泄漏场景，方便后面用工具实测：
public class LongLivedManager {
private static final List<Object> TASKS = new ArrayList<>();
private byte[] bigData = new byte[1024 * 1024 * 5]; // 5MB大对象
public void submitTask() {
// 匿名内部类隐式持有LongLivedManager.this引用
TASKS.add(new Runnable() {
@Override
public void run() {
System.out.println("task running");
}
});
}
}这段代码中，静态集合TASKS是GC Root可达的，每个加入集合的Runnable都通过this$0引用住外部的LongLivedManager实例，进而引用住5MB的bigData。只要TASKS不清理，这些Manager实例就永远无法回收。
用堆转储和MAT工具定位泄漏引用链
理论清楚了，实际分析要靠工具。第一步是获取堆转储。可以用jmap -dump:live,format=b,file=heap.hprof 进程号命令，也可以在发生OutOfMemoryError时通过-XX:+HeapDumpOnOutOfMemoryError参数自动生成。对于Android开发，则可以使用Android Studio的Memory Profiler或adb的am dump命令。
拿到hprof文件后，用Eclipse MAT打开。分析思路分三步走：先在Histogram视图按对象数量和Retained Size排序，找到数量异常多的可疑类；然后用Dominator Tree视图查看哪些对象实际占住了大部分内存；最后对可疑对象执行Path to GC Roots，排除弱引用和软引用，查看强引用链。
以上面的例子来说，你会在引用链中看到类似这样的路径：TASKS静态字段指向ArrayList，ArrayList的elementData数组指向Runnable实例，展开Runnable实例的属性列表，能看到一个名为this$0的字段，其类型正是LongLivedManager。看到this$0出现在引用链上，就是内部类泄漏最直接的铁证。MAT还会在Leak Suspects报告中自动标注这类由外部类引用导致的大内存持有者。
// 通过反射验证隐式引用的存在
Field outerField = obj.getClass().getDeclaredField("this$0");
outerField.setAccessible(true);
Object outer = outerField.get(obj);
System.out.println(outer.getClass().getName()); // 输出外部类名防泄漏改造方案与最佳实践
定位之后就是改造。最通用的方案是把内部类改成静态内部类。静态内部类不会持有外部类引用，如果确实需要访问外部类成员，可以通过弱引用把外部对象包起来：
public class LongLivedManager {
private byte[] bigData = new byte[1024 * 1024 * 5];
// 静态内部类 + 弱引用，不再隐式持有外部类
static class SafeTask implements Runnable {
private final WeakReference<LongLivedManager> outerRef;
SafeTask(LongLivedManager outer) {
this.outerRef = new WeakReference<>(outer);
}
@Override
public void run() {
LongLivedManager outer = outerRef.get();
if (outer != null) {
System.out.println("task running, data len: " + outer.bigData.length);
}
}
}
}除了改成静态内部类，还要养成几个习惯。第一，注册了监听器就要在生命周期结束时反注册，比如在Activity的onDestroy中移除Listener，在线程池关闭前处理完任务。第二，避免让匿名内部类对象进入静态集合、单例对象或长生命周期缓存，必要时改用WeakHashMap或者显式的清理逻辑。第三，在Android场景下，Handler延时消息、Thread、AsyncTask这类场景尤其高发，因为工作线程存活时间长，Runnable又引用着外部类。
总结一下，内部类泄漏的分析核心就两点：理解非静态内部类隐式引用外部类的编译机制，以及掌握可达性分析的引用链排查方法。用MAT沿着this$0这条线索追踪，大部分这类泄漏都能快速定位，再配合静态内部类和弱引用改造，就能从根源上杜绝此类问题。