非静态内部类默认持有外部类强引用，Java编译器在字节码中注入this$0字段，导致Activity等组件无法被GC回收，引发内存泄漏；Handler、匿名监听器及捕获实例方法的Lambda均属此类。
非静态内部类默认持有外部类强引用
Java编译器会在非静态内部类的构造器中自动注入一个隐式的 this$0 字段，指向外部类实例。这不是语法糖，而是字节码层面的真实字段——哪怕你没写任何访问外部类成员的代码，这个引用也存在。
常见错误现象：OutOfMemoryError 在频繁创建内部类对象（如匿名监听器、Handler）且外部类是 Activity 或 Fragment 时高频出现；MAT 分析显示大量内部类实例无法 GC，Retained Heap 高。
- 使用场景：Android 中
new Handler() { ... }、Swing 的addActionListener(new ActionListener() { ... }) - 参数差异：静态内部类（
static class）不带this$0；局部类/匿名类若定义在非静态方法里，同样持有该引用 - 性能影响：每个非静态内部类实例多占 4~8 字节（取决于 JVM），但真正致命的是阻止外部类被回收
Handler + 非静态内部类是经典泄漏组合
Handler 绑定到主线程 Looper 后，只要消息队列里还有未处理的 Message 或 Runnable（比如延时任务），就一直持有对目标 Handler 的强引用；而 Handler 若是非静态内部类，又拖住了整个 Activity。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 把 Handler 声明为
static，并通过WeakReference<activity></activity>持有外部上下文 - 在 Activity
onDestroy()里调用mHandler.removeCallbacksAndMessages(null) - 避免在 Handler 回调中直接调用
findViewById或更新 UI，先检查weakRef.get() != null && !weakRef.get().isFinishing()
示例关键片段：
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
static class SafeHandler extends Handler {
private final WeakReference<MainActivity> mActivity;
SafeHandler(MainActivity activity) {
mActivity = new WeakReference<>(activity);
}
@Override
public void handleMessage(Message msg) {
MainActivity activity = mActivity.get();
if (activity == null || activity.isFinishing()) return;
// 安全操作
}
}
Lambda 表达式是否也会泄漏？
会，但有条件。Lambda 在捕获外部类成员变量或调用实例方法时，会隐式持有外部类引用——本质和非静态内部类一样。
容易踩的坑：
- 写成
view.setOnClickListener(v -> doSomething())：如果doSomething()是 Activity 的实例方法，就泄漏 - 写成
view.setOnClickListener(v -> new SomeUtil().process())：不泄漏，因为没捕获外部实例 - Android Studio 的 Lint 会标出「Anonymous class referenced an enclosing method」警告，但不会标所有 lambda 泄漏场景
更安全的写法是提取为静态方法或使用弱引用包装器，而不是依赖“看起来简洁”。
如何验证内部类是否真持有外部引用
别猜，用工具看字节码或内存快照。javap 是最快验证手段：
- 编译后执行
javap -c OuterClass$InnerClass.class - 搜索
aload_0后紧跟getfield，字段名含this$0就确认存在引用 - 在 Android 上用 LeakCanary 捕获泄漏路径，它会明确打出「holds reference to OuterClass」
- 注意：Kotlin 的 inner class 同样生成
this$0，但普通 lambda 默认不持外层 this，除非显式访问成员
真正麻烦的从来不是“怎么写”，而是“什么时候该意识到引用链已经跨出了生命周期边界”。比如一个后台线程里的内部类，可能比 Activity 多活好几秒——这几秒就足以让 GC 把整个 Activity 堆积在老年代里。
