内部类隐式泄漏本质是编译机制与生命周期错配：非静态内部类通过this$0强引用外部类，若被线程池、回调或静态容器持有，则外部类无法被gc回收。

内部类在高并发回调中引发的隐式泄漏，本质不是“写错代码”，而是编译机制 + 生命周期错配共同作用的结果：非静态内部类（含匿名类、局部类）会由编译器自动插入一个 this$0 字段，强引用外部类实例；一旦这个内部类被提交到线程池、注册为异步回调或存入静态容器，它就变成一条“看不见的锁链”，把外部类牢牢绑在内存里——哪怕业务早已结束，GC 也无权回收。

为什么高并发场景特别危险

并发环境放大了引用持有时间与对象生命周期的不匹配：

• 线程池复用导致内部类实例长期存活，this$0 一直有效
• 批量提交任务时，大量内部类同时持有一批外部类（如多个 Activity、Service 或 Handler 所属对象）
• 延迟回调（如 postDelayed、ScheduledExecutorService.schedule）让引用链在后台静默维持数十秒甚至更久
• 错误地将回调对象缓存进静态集合（如 static Map<string runnable></string>），使整个外部类家族永久驻留

泄漏不是“没释放”，而是“无法释放”

关键要区分两个动作：

• 你在 onDestroy() 或 finally 里把内部类变量设为 null → 只断开了你这一侧的引用
• 但线程池里的 Future、Handler 的 MessageQueue、EventBus 的订阅列表，仍在强持有那个内部类 → this$0 依然指向外部类，GC 根路径未断

也就是说，外部类是否可回收，不由它自己决定，而取决于谁还攥着那个内部类。

怎么验证是不是它在作怪

用 MAT（Memory Analyzer Tool）或 Android Profiler 抓堆快照，筛选出你的内部类（如 MyActivity$1、MyFragment$CallbackRunnable），再看它的 this$0 字段指向哪个外部类实例。如果该外部类（如已 finish 的 Activity）本该被回收却仍被这些内部类拖住，就是典型隐式泄漏。

真正有效的切断方式

不能只靠“等 GC”，得主动拆掉引用链：

• 用 static 内部类替代非静态类，彻底消除 this$0
• 必须访问外部类时，用 WeakReference<outer></outer> 包装，在调用前判空，避免强绑定
• 提交到线程池的任务，用 Future.cancel(true) 主动中断；Handler 回调用 removeCallbacksAndMessages(null)
• 监听器类统一实现销毁接口，在退出时通知持有方移除自身（如 eventBus.unregister(this)）