静态内部类不会导致外部类泄漏，因其不持有对外部类实例的隐式引用，编译后生成独立class文件，与外部类生命周期解耦；而非静态内部类通过this$0强引用外部类，易引发内存泄漏。
静态内部类为什么不会导致外部类泄漏
因为 StaticInnerClass 不持有对外部类实例的隐式引用，它本质上就是个“普通类”，只是语法上写在了外部类里。编译后生成独立的 Outer$StaticInnerClass.class 文件，和外部类对象生命周期完全解耦。
常见错误现象：把 Handler、Runnable 或线程任务写成非静态内部类，结果 Activity 销毁后还被线程强引用着，内存一直占着不放。
- 只要内部类没用到
this、outerField或调用outerMethod()，就该声明为static - Android 中尤其注意：自定义
Handler子类、AsyncTask内部实现、RxJava 的Disposable持有者，都容易踩坑 - 静态内部类无法直接访问外部类的非静态成员——这不是限制，是安全设计；需要时显式传参（比如
WeakReference<context></context>）
非静态内部类泄漏的典型场景和触发条件
非静态内部类（如 NonStaticInnerClass）编译时会被注入一个隐藏字段 this$0，指向创建它的外部类实例。只要这个内部类对象还活着，外部类就被强引用锁住。
使用场景：UI 回调、延时任务、异步加载完成监听器——这些地方生命周期往往比 Activity/Fragment 长，最容易暴露问题。
立即学习“Java免费学习笔记（深入）”；
- 启动一个
new Thread(() -> { ... }).start()，里面用了非静态内部类的run()方法 → 外部 Activity 被持有着 - 给
View.postDelayed()传了个非静态匿名内部类的Runnable→ 延迟期间 Activity 已 finish，但还在内存里 - OkHttp 的
Callback实现写成非静态内部类，网络请求慢或失败重试时，Activity 可能早已 destroy
怎么快速判断一个内部类是否安全
看它是否「被动依赖」外部类实例。不是看有没有 static 关键字，而是看编译后会不会生成 this$0 字段。
实操建议：用 javap -c Outer\$Inner.class 反编译检查构造方法，如果第一行是 aload_0 + invokespecial 调用父类且参数含 Lcom/example/Outer;，那就危险了。
- IDEA 里按 Ctrl+Click 进入内部类定义，如果顶部显示 “Anonymous class extends Object” 就安全；显示 “Anonymous class extends Outer$Xxx” 就大概率不安全
- Android Studio 的 Profiler → Memory → Dump Java Heap 后搜索
Outer类名，再看它的 GC root 是否包含某个Inner实例 - 用
WeakReference包一层不是万能解法——它只解决“持有但不阻止回收”，不能掩盖设计缺陷；优先消灭隐式引用
静态内部类配合 WeakReference 的正确姿势
静态内部类本身不泄漏，但它如果要操作外部类资源（比如更新 UI），就得安全地“临时获取”引用，而不是长期持有。
错误写法：static class MyHandler extends Handler { private final Context ctx; ... } —— Context 是强引用，照样泄漏。
- 正确模式：静态内部类 +
WeakReference<t></t>，且每次使用前判空，例如if (ref.get() != null) { ref.get().updateUi(); } - 不要在静态内部类里缓存
View、Adapter、Context等组件引用；要用就现场找（activity.findViewById()）或通过回调传入 - 注意
WeakReference不是银弹：它可能随时返回null，业务逻辑得容错；而过度防御性判空会让代码变啰嗦——所以更推荐从源头避免需要引用
真正麻烦的从来不是写 static 这两个字母，而是想清楚“这个类到底需不需要知道外面是谁”。一旦开始手动管理引用强度，说明设计已经绕远路了。
