非静态内部类隐式持有外部类强引用（this$0），易致内存泄漏；静态内部类无此引用，更安全高效。应优先使用静态内部类，需访问外部状态时显式传入WeakReference。
成员内部类隐式持有 this$0 引用，直接导致强引用链
每个非静态内部类实例在编译后都会被注入一个隐藏字段
，它是一个对外部类实例的强引用。这个字段不是你写的，是
java
c 自动加的，躲不掉。
常见错误现象：
已
，但后台线程还在执行内部类回调，
无法 GC；或者把内部类对象放进静态
或线程池，整个外部类实例就被钉在堆里。
哪怕内部类代码里一句
都没写，
依然存在
不能通过序列化单独保存非静态内部类实例（会抛
）
无法在
方法中直接
，编译报错：
静态内部类没有 this$0，内存更轻、GC 更干净
修饰的内部类在字节码层面完全不依赖外部类实例：JVM 不生成
字段，也不要求先有
实例才能创建
。
性能与兼容性影响：每个静态内部类实例省下 4–8 字节（64 位 JVM 引用大小），看似微小，但在高频创建场景（如网络响应 DTO、Builder 实例）下可累积可观收益；更重要的是，它不会拖住外部类生命周期。
立即学习
“
Java免费学习笔记（深入）
”；
Eclipse导入Android或其他的JAVA项目的正确方法 WORD版
本文档主要讲述的是Eclipse导入Android或其他的JAVA项目的正确方法；希望本文档会给有需要的朋友带来帮助；感兴趣的朋友可以过来看看
下载
创建方式直接：
，无需外部类对象
只能访问外部类的
成员，比如
可用，
直接编译失败
若真需要访问外部类状态，应显式传入
，而非依赖隐式引用
编译期就能发现访问权限问题，别等运行时泄漏才排查
静态内部类访问非静态成员时，错误发生在编译阶段——这是最友好的提示时机。而内存泄漏是运行时问题，往往要等 OOM 或 MAT 分析堆快照才发现。
容易踩的坑：
内部类里误写
，IDE 报红立刻修正；但反过来，非静态内部类被静态集合持有，编译完全通过，问题只在长时间运行后暴露。
不确定要不要
？先写成
，编译报错说“无法引用非静态变量”，再改——比修复线上内存泄漏成本低得多
匿名内部类（如
）默认是非静态的，只要出现在非静态方法里，就自动持有所在实例引用
Android 中
、
（已废弃但仍有存量）、自定义
是高危区，优先用
真正决定内存占用的不是“类本身”，而是引用链是否可控
静态内部类对象本身不比非静态的“更小”，关键差异在于它不制造意外的强引用链。一个
类里存着
，照样吃内存；但只要它不绑着
，
就能及时回收。
复杂点在于：有些场景看似必须用非静态内部类（比如要修改外部类私有字段），但其实可以通过回调接口、事件总线或显式弱引用来解耦。别让“方便访问”掩盖了生命周期失控的风险。
this$0Activityfinish()ActivityMapthisthis$0java.io.NotSerializableExceptionstaticnew Outer.Inner()no enclosing instancestaticthis$0OuterOuter.StaticInnernew Outer.StaticInner()staticpublic static final String TAGprivate int countWeakReferencestaticinstanceFieldstaticstaticnew Runnable() { ... }HandlerAsyncTaskCallbackstatic + WeakReferencestaticbyte[10MB]ActivityActivity