Java内部类内存泄漏的核心是：非静态内部类隐式持有外部类强引用（this$0），被长生命周期对象持有时导致外部类无法回收。定位需查字节码、持有方及GC Roots路径；预防应优先用静态内部类+接口回调、谨慎使用Lambda、必要时用WeakReference；运行期须及时解绑；重构时需审计引用、替换裸结构、强制资源契约。
Java 中内部类内存泄漏的核心在于：非静态内部类会隐式持有外部类实例的强引用（this$0字段），一旦该内部类被长生命周期对象（如线程池、静态容器、Handler）持有时，外部类就无法被回收——哪怕业务逻辑早已结束。
一、快速定位：三步确认是否真泄漏
不用等 OOM，日常就能自查：
-
查字节码：对疑似内部类执行
javap -c Outer$Inner，若看到final Outer this$0字段，说明强引用已生成； -
查持有方：看这个内部类是否被
ExecutorService、static List、Handler.postDelayed、TimerTask或 EventBus 订阅等长期存活对象接收； -
查 GC Roots 路径：用 VisualVM 或 MAT 打开 Heap Dump，搜索外部类实例，右键 “Merge Shortest Paths to GC Roots”，若路径中出现
Outer$Inner → this$0 → Outer，且中间穿插ThreadPoolExecutor$Worker或static field，即为实锤。
二、编码预防：从源头切断引用链
重构或新写代码时，优先采用以下安全模式：
-
静态内部类 + 接口回调：静态类不生成
this$0；需访问外部状态时，定义Callback接口，由外部类实现并传入，内部类只持接口引用； -
Lambda 要谨慎：仅捕获静态变量或局部
final变量时不持外部引用；但写成() -> doSomething(this.field)就等效于匿名内部类，仍绑定this$0； -
必须用非静态时，显式弱化：在内部类中声明
private final WeakReference<Outer> outerRef = new WeakReference<>(Outer.this)，后续所有调用前先判空：if (outerRef.get() != null) { ... }。
三、运行期兜底：及时解绑不可控持有
即使用了非静态内部类，只要注册/提交行为可控，就必须配套释放逻辑：
立即学习“Java免费学习笔记（深入）”；
-
线程池任务：提交后保留
Future，在外部类销毁前调用future.cancel(true)，并确保线程池执行shutdownNow()； -
延迟/周期任务：如
handler.postDelayed(runnable, delay)，务必在onDestroy()或finally块中调用handler.removeCallbacks(runnable)； -
监听器注册：凡有
addListener、subscribe、register，必须配对removeListener、dispose、unregister，并在生命周期终点（如 Activity.onDestroy、Bean.destroy）触发。
四、重构阶段专项防御
代码重构是拦截泄漏的最佳时机，应嵌入三项动作：
-
审计引用生命周期：扫描所有
static字段、ThreadLocal、监听器注册点，确认是否有未配对注销或无淘汰策略的缓存； -
替换裸引用结构：静态集合改用
Caffeine（带大小+过期策略）；ThreadLocal改为覆写initialValue()并在finally中remove()； -
强制资源契约：涉及流、连接、监听器的类，必须实现
AutoCloseable，close()中清空内部引用；单元测试需验证close()是否被调用、关键字段是否置空。
