内部类隐式泄漏本质是编译机制与生命周期错配：非静态内部类通过this$0强引用外部类，若被线程池、回调或静态容器持有，则外部类无法被GC回收。
内部类在高并发回调中引发的隐式泄漏，本质不是“写错代码”，而是编译机制 + 生命周期错配共同作用的结果：非静态内部类（含匿名类、局部类）会由编译器自动插入一个 this$0 字段，强引用外部类实例；一旦这个内部类被提交到线程池、注册为异步回调或存入静态容器，它就变成一条“看不见的锁链”，把外部类牢牢绑在内存里——哪怕业务早已结束，GC 也无权回收。
为什么高并发场景特别危险
并发环境放大了引用持有时间与对象生命周期的不匹配：
- 线程池复用导致内部类实例长期存活，
this$0一直有效 - 批量提交任务时，大量内部类同时持有一批外部类（如多个 Activity、Service 或 Handler 所属对象）
- 延迟回调（如
postDelayed、ScheduledExecutorService.schedule）让引用链在后台静默维持数十秒甚至更久 - 错误地将回调对象缓存进静态集合（如
static Map<String, Runnable>），使整个外部类家族永久驻留
泄漏不是“没释放”，而是“无法释放”
关键要区分两个动作：
- 你在
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>包装，在调用前判空，避免强绑定 - 提交到线程池的任务，用
Future.cancel(true)主动中断；Handler 回调用removeCallbacksAndMessages(null) - 监听器类统一实现销毁接口，在退出时通知持有方移除自身（如
eventBus.unregister(this)）
