非静态内部类因隐含this$0强引用外部类导致内存泄漏，需通过静态内部类、weakreference及主动清理持有者来断链。
内部类持有外部类引用引发内存泄漏，本质是生命周期错配导致的强引用滞留——只要内部类还活着，外部类就无法被回收，哪怕它早就该结束了。
非静态内部类自带“隐形绳索”
Java 编译器会为每个非静态内部类（包括成员类、匿名类、局部类）自动生成一个 this$0 字段，类型就是外部类，并在构造时强引用传入。这个引用不是你写的，但真实存在、不可绕过。
- 即使内部类没访问任何外部类字段或方法，this$0 依然存在
- Lambda 表达式捕获实例变量或
this时，行为等同于匿名内部类 - 静态内部类没有 this$0，天然不持外部类实例引用
泄漏只在“内部类活得比外部类久”时爆发
内存泄漏不是用了内部类就发生，而是当内部类被长期持有，而外部类已该销毁却无法释放时才触发：
- Runnable 被提交到全局线程池，Activity 已 finish，但任务还在队列中
- 内部类作为监听器注册到 EventBus 或 View，Fragment 已 detach，但未 unregister
- Handler 的 callback 是非静态内部类，消息还没处理完，Activity 就被销毁了
- 内部类实例被赋值给 static 变量或单例中的集合
关键不是“能不能用”，而是“怎么断链”
问题不在内部类本身，而在引用链是否可控。安全做法聚焦三点：
- 优先用 静态内部类 + 构造参数传值：只传需要的 ID、String、int 等具体数据，不传整个外部对象
- 必须调用外部类实例方法时，用 WeakReference
包裹，并在每次使用前判空： if (outerRef.get() != null) - 在外部类销毁时机（如 Activity.onDestroy、Thread.stop 前），主动清理持有方：移除 callback、cancel Future、unregister 监听器
别信“设 null 就安全”这种直觉
把内部类变量自己设为 null 没用——真正卡住 GC 的，是线程池、Handler、静态容器这些“外部持有者”。它们手里还攥着那个带 this$0 的对象，外部类就被钉在堆里动不了。
真正要操作的，是这些持有者的 API：比如 handler.removeCallbacksAndMessages(null)、executor.shutdownNow()、eventBus.unregister(this)。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
