匿名类本身不直接导致内存泄漏，真正原因是其通过隐式强引用（this$0）持有外部类实例，当被长生命周期对象（如Handler、线程池）持有时，会阻碍Activity等短生命周期对象的回收。
匿名类本身不会直接导致内存泄漏，真正起作用的是它与外部类之间的隐式强引用关系，以及该引用被长生命周期对象“意外延长”后，阻碍了外部类实例（如Activity、Fragment）的及时回收。
匿名类为何天然持有外部类引用
Java编译器会为每个非静态内部类（含匿名类）自动生成一个隐藏字段 this$0，指向其定义时所在的外部类实例。这个引用是强引用，意味着只要匿名类对象还活着，外部类对象就无法被GC回收。
- 即使匿名类只用了一次，比如写了个
new Runnable() { ... }，它仍绑定了当前 Activity 实例 - 这个绑定发生在构造阶段，无需显式代码，开发者容易忽略
- 静态内部类没有 this$0 字段，因此不持外部类引用——这是关键区别
泄漏发生的典型触发场景
单有引用还不够，泄漏需要“引用链未断 + 外部类已失效”同时成立。常见组合包括：
- 延迟消息 + Handler：在 Activity 中 new Handler().postDelayed(runnable, 5000)，Activity 销毁后 runnable 仍持引用，且被 Looper 持有，直到延时结束
- 线程池任务：将匿名 Runnable 提交到全局单例线程池，任务未执行完前，Activity 无法释放
- 静态监听器/回调：把匿名 OnClickListener 赋给静态 View 或工具类，View 生命周期远超 Activity
- 异步网络回调：Retrofit 回调用匿名类，请求未返回前 Activity 已 finish
有效缓解方案不是“不用匿名类”，而是切断引用链
核心思路是让长生命周期对象不再强依赖短生命周期外部类。常用手段有：
立即学习“Java免费学习笔记（深入）”；
- 改用静态内部类 + WeakReference：静态类不持外部引用；WeakReference 可安全访问 Activity，且不阻止 GC
- 在销毁时主动清理：Activity.onDestroy() 中 removeCallbacks、removeMessages、cancel AsyncTask、取消网络请求
- 使用生命周期感知组件：如 Android 的 lifecycleScope.launchWhenStarted，协程自动随 Lifecycle 状态取消
- 避免跨作用域传递匿名类：不在 Application 或 Service 级别保存 Activity 内创建的匿名对象
Kotlin 的 Lambda 并不绝对安全
Kotlin 编译器对 Lambda 的处理比 Java 匿名类更谨慎：若 Lambda 不捕获外部变量，通常不持 this 引用；但一旦访问了 this、view、memberVar 等，就会生成类似 this$0 的捕获字段。所以 Kotlin 仍需配合 lifecycleScope 或 viewLifecycleOwner 使用，不能仅因语法简洁就放松警惕。
