非静态内部类会隐式持有外部类强引用（this$0），导致外部类无法及时回收；应优先用静态内部类+WeakReference、及时解绑、避免持有Context等对象。
因为非静态内部类（含成员内部类、局部内部类、匿名内部类）在编译时会自动生成一个隐式的强引用字段（如 this$0），指向创建它的外部类实例。只要内部类对象还存活，外部类实例就无法被垃圾回收器回收——哪怕业务逻辑上它早已“用完”。
关键机制：编译器悄悄加了引用
Java语言规范要求非静态内部类必须能访问外部类的私有成员，因此编译器会在字节码中自动插入一个 final OuterClass this$0 字段，并在构造时传入并赋值。这个引用是强引用，不随作用域结束而消失。
- 例如：定义一个
Runnable匿名内部类作为定时任务，它持有 Activity 或 Fragment 实例，而该任务被 Handler 或线程池长期持有 → Activity 就一直无法释放 - 再如：内部类被注册为监听器、回调、或提交到异步线程，但未在外部类销毁时及时解绑 → 引用链持续存在
泄露发生的典型前提
内存泄漏不是“用了内部类就一定发生”，而是当内部类生命周期 > 外部类生命周期时才触发：
- 外部类（如 Activity、Service、Context）已进入销毁流程，但内部类实例仍被静态变量、线程、Handler、缓存、单例等长期持有
- 外部类持有一些大对象（如 Bitmap、大数组、数据库连接），因被内部类间接持有，导致整块内存无法回收
- 静态内部类不会出现此问题——它没有
this$0字段，也不持有外部类引用
如何避免
核心思路是切断不必要的强引用链：
- 优先使用静态内部类 + WeakReference：静态内部类不持外部类引用；若需访问外部类成员，用
WeakReference<Outer>持有，并判空调用 - 及时清理：在外部类销毁时（如 Activity#onDestroy、Fragment#onDestroyView），主动移除内部类注册的监听器、取消 Handler 的 callback、停止线程任务
- 避免在内部类中直接持有 Context、View、Activity 等易泄露对象；改用 Application Context（无 UI 生命周期）
- 工具辅助：用 MAT 分析堆转储（Heap Dump），查找
OuterClass$InnerClass实例的 GC 路径，确认是否通过静态字段或线程栈被意外保留
本质上这不是内部类的“bug”，而是 Java 封装便利性与对象生命周期管理之间的权衡。理解编译器做了什么，比记住“别用内部类”更重要。
