内部类与匿名内部类这道题的特别之处在于，它能把"看过资料"和"写过代码"区分开。前者的回答停在名词，后者的回答里有执行路径、有数据流向、有失败模式——面试官要的正是后者。
先把结论放在前面：非静态内部类（含成员内部类、匿名内部类、非静态局部类）都会隐式持有外部实例的引用，靠这个隐藏引用访问外部成员；静态内部类与 lambda（不捕获外部实例时）则不持有。这题要答好，光有结论不够，得能把"持有引用"这条线索一路推到泄漏与捕获语义上。
机制拆解
这篇把它掰开揉碎，从概念到坑点过一遍。
四类内部类分别是什么
成员内部类写在类的内部、方法外，它依附于外部实例而存在，创建时必须先有外部对象（outer.new Inner()）。局部内部类写在方法内，作用域被限制在方法里。匿名内部类是没有名字的局部内部类，常用于一次性实现接口或继承类（new Runnable(){...}）。静态内部类用 static 修饰，不持有外部引用，独立存在。
一个关键区分：匿名内部类与 lambda 在"捕获"上很像，但底层不同。匿名内部类是编译期生成的一个独立 .class 文件，它要访问外部局部变量，那些变量必须是 final 或 effectively final（因为匿名类持有的是变量的拷贝，而不是变量本身）。lambda 则更轻——不捕获外部实例时，它可以被 JVM 优化成单例或方法句柄，不会额外钉住外部对象，这正是它比匿名内部类更不容易泄漏的原因。
这些坑的正确绕法
最常见的坑是非静态 Handler 子类隐式持有 Activity，消息队列里还排着延迟消息时页面已被关闭，Activity 因被引用钉死而无法回收。标准解法是 Handler 声明为静态内部类并持有外部 Activity 的弱引用，或在 onDestroy 时 removeCallbacksAndMessages(null) 清空队列。
其次是以为匿名内部类"捕获"的是变量本体，在回调里修改捕获值期望外部可见，结果两边各改各的——因为传进匿名类的是值拷贝。需要共享可变状态，得显式用数组、AtomicReference 这类容器来包，或干脆改成显式传参。
还有一个更隐蔽的坑：静态内部类若想访问外部私有成员，编译器会偷偷生成一个 access$000 之类的包级静态方法，等于对外开了一道本不该开的口子；高频创建的内部类还会拖出一堆 .class 文件与类加载开销，这也是 Android 上对内部类用量敏感的原因。把"内部类是否持有外部引用""捕获的是拷贝还是本体"写在代码旁，是团队协作里最划算的一条约定。
代码里见真章
看一段能直接跑的代码，把上面的机制落到具体写法上：
class Outer {
int x = 1;
Runnable cb = new Runnable() {
// 匿名内部类：隐式持有 Outer.this
public void run() {
System.out.println(Outer.this.x); }
};
static class Worker {
void go() {
} } // 静态内部类：不持有外部引用
static Runnable fn = () -> {
}; // lambda 不捕获外部实例，不持有 Outer.this
}
// 泄漏根因：非静态内部类（含匿名类）隐式持有 Outer.this，生命周期被外部实例绑架
这段代码值得盯三处：第一处，匿名内部类 cb 通过 Outer.this.x 访问外部成员，证明它持有外部引用；第二处，静态内部类 Worker 没有任何外部引用，可独立存活；第三处，不捕获外部实例的 lambda fn 同样不持有 Outer.this。面试讲到这一层，基本就稳了。
这题在面试里怎么问、怎么答
"请简单介绍一下内部类与匿名内部类，它在 Android 开发中起什么作用？"答法：定位一句（非静态内部类持有外部引用）、场景一个（Handler、View 点击回调、Adapter 里的 ViewHolder 内联）、细节一处（生命周期与泄漏）。结尾补一句"泄漏根因是非静态内部类隐式持有 Outer.this"，立刻能拉开差距。
"内部类与匿名内部类的底层原理是什么？"别用一句话打发。机制层讲清：非静态内部类编译后第一个构造参数就是外部实例，所有外部成员访问都通过它转发；匿名类编译成 Outer$1.class 之类；lambda 不捕获时走 invokedynamic，由 JVM 在运行期才决定要不要生成类。讲到这顺手画个引用关系图，面试官会记住你。
"使用内部类与匿名内部类时遇到过什么问题？"这是行为题，用真实项目回答。比如曾用匿名 AsyncTask 内部类持有 Activity，屏幕旋转后旧 Activity 泄漏，后来改用静态内部类 + 弱引用并在 onDestroy 取消任务，再用 LeakCanary 验证。经历按场景、任务、行动、结果一条线讲，逻辑自然清晰。
"内部类与匿名内部类和替代方案相比有什么优劣？"维度照例是性能、接入成本、生态与团队熟悉度。比如要回调，lambda 比匿名类更轻、更不易泄漏；要复用结构，独立顶层类比内部类更解耦但样板更多。选型时把"匿名类捕获的是值拷贝、改了外部不可见""非静态内部类持有外部引用致泄漏"这类代价摆到台面上，再决定是否引入。
局部内部类是另一类常被忽略的形态：它写在方法内部、作用域被限制在方法里，常用于"这个方法需要一个小类、别处用不到"的场景。它同样隐式持有外部引用，所以别因为"没写成成员内部类"就放松对生命周期的警惕。Android 里一个经典误用就是在 Activity 的方法里随手 new 一个 Handler/Runnable 内部类，回调一延迟，Activity 就被钉住。
从构建产物看，每个匿名内部类都会编译成一个独立的 .class 文件（命名类似 Outer$1.class），大量使用会推高方法数与 dex 体积，对 64K 方法数上限敏感的老项目是个实打实的压力点；而 lambda 不捕获外部实例时，JVM 可以复用同一个实例甚至退化成方法句柄，没有这份开销。这也解释了为什么 Google 官方更推荐用 lambda 替代匿名内部类——除了更简洁，它也确实更轻、更不容易泄漏。
Kotlin 里对应的写法是 inner class（持有外部引用，等价于 Java 非静态内部类）与 object（匿名对象，捕获外部，但要注意它也可能持有引用）。迁移到 Kotlin 后，区分"到底要不要持有外部实例"依然是这道题的核心，语法换了，线索没变。
还有一个和序列化相关的坑：一个类若实现了 Serializable，它的非静态内部类也会被迫可序列化，连带把外部实例一起拖进序列化流，结果外部实例里那些本不该持久化的字段也被写出去——既膨胀又有数据外泄风险。需要序列化的场景，内部类要么同样 Serializable，要么干脆改成静态内部类切断与外部的牵连。Android Studio 的 Lint 也带有 InnerClass 这类检查，能把"非静态内部类持有外部引用"的隐患在静态分析阶段就标出来，纳入 CI 比靠人 review 更稳。
记住一句话：只要先问"这个类到底要不要持有外部实例"，这道题的八成考点就已经在你手里了。
给正在准备面试的你
内部类与匿名内部类读完别停，真实编码加复盘各来一次，知识才留得住。面试中关于这题，关键是从原理、应用、踩坑三个层面给出有深度的回答，而不是列定义。
再补一条工程经验：把关键回调从匿名内部类改成静态内部类或 lambda，并在 code review 模板里加一条"非静态内部类是否必要"检查，能提前拦掉一大类生命周期相关的泄漏。
复习时别孤立刷题：自定义异常与异常链、错误设计的相邻考点常成对出现，边界就是得分点。
如果这篇文章对你有帮助，欢迎点赞、在看、转发三连。你的支持就是这个系列持续更新的动力。
「Android软件开发面试·从入门到精通」连载系列
上一篇：抽象类与接口：到底该怎么选才不丢分
下一篇预告：枚举-enum：不止是常量集合
有任何问题欢迎在评论区留言交流。
