非静态内部类会隐式持有外部类强引用，导致内存泄漏；编译器自动添加this$0字段形成不可切断的引用链，常见于handler、asynctask、线程池等异步场景，引发oom。
非静态内部类会自动持有外部类的强引用，一旦这个内部类对象被长期持有（比如注册到监听器、放入线程池或静态容器），外部类实例就无法被垃圾回收——哪怕它的业务生命周期早已结束。
编译器悄悄加了一条“锁链”
Java 编译器在生成非静态内部类字节码时，会强制添加一个名为 this$0 的私有 final 字段，类型就是外部类。构造内部类实例时，必须传入外部类对象并赋值给 this$0。这意味着：内部类和外部类之间存在一条不可切断的强引用链。
- 即使内部类本身只做简单计算，它也“拖住”了整个外部类实例
- 如果外部类是 Activity、Service 或大对象（如含缓存、连接池的处理器），内存占用会明显升高
- 这种引用不依赖代码显式书写，开发者容易忽略其存在
泄漏常发生在“异步+长生命周期”组合场景
当内部类脱离外部类生命周期独立运行时，问题立刻暴露：
- Handler 或 Runnable 写成非静态内部类，消息队列未清空前，Activity 无法销毁
- AsyncTask 的内部回调类持有 Activity 引用，后台任务未完成，界面已退出
- 线程池 submit 一个匿名内部类 Runnable，执行延迟几秒，此时 Fragment 已 detach
- 全局事件总线注册了非静态内部类作为订阅者，却忘了在 onDestroy 里反注册
GC 看得见，但收不走
垃圾回收器判断对象是否可回收，依据的是可达性分析：只要从 GC Roots（如线程栈、静态变量）出发，能通过任意强引用链到达该对象，它就被视为“活跃”，不会被回收。非静态内部类正是这条链上的关键一环。
- GC Roots → 静态线程池 → Runnable 实例 → this$0 → Activity 实例
- Activity 本该在 onPause/onDestroy 后释放，却因这条隐式链持续驻留堆中
- 反复触发页面重建，就会积累多个 Activity 实例，最终触发 OOM
验证与确认的关键动作
不能只看源码有没有写 static，要落到运行时证据上：
- 用 javap -c Outer$Inner 查看字节码，确认是否存在 this$0 字段
- 用 MAT（Memory Analyzer Tool）打开 heap dump，搜索 Activity，检查其被哪些对象强引用
- 在 Android Studio Profiler 中反复打开关闭同一页面，观察 Activity 实例数是否稳定
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
