面试时我常问应聘者一个问题：你用过匿名内部类吗？十个里有九个说用过，写到new Thread(new Runnable(){...})的时候个个手速飞快。但等我追问一句：“这个匿名内部类的实例，在 JVM 里到底是一个什么东西？它凭什么能访问外面的变量？为什么那个变量必须是 final 或 effectively final？”，能答利索的人就很少了。这并不丢人，因为大多数教程只教你怎么敲这段代码，很少带你看它背后的完整链路。这篇内容，我就把 Java 匿名内部类这条链路从头到尾捋一遍：语法本质、字节码真相、变量捕获规则、项目中的落地姿势，以及容易踩翻车的几个角落。不管你是准备面试，还是日常写业务时想用得明白一点，都应该能从里面拿到实际有用的东西。
提示：本文定位是“全面解析”，默认读者有基本的 Java 语法基础。如果你还没写过匿名内部类，建议先敲一遍示例代码再往下读，效果会好很多。
1. 匿名内部类到底在干什么：一次“用后即弃”的类建模
1.1 先看一段高频出现的老代码
Swing 时代写过界面的人，对下面这段仪式一定不陌生——
button.addActionListener(new ActionListener() { @Override public void actionPerformed(ActionEvent e) { System.out.println("按钮被点击了"); } });这段代码干了一件看起来很“矛盾”的事：new了一个ActionListener，但ActionListener明明是个接口，接口不能被new。实际上你new出来的不是一个接口，而是一个没有名字的类的实例。这个“没有名字的类”，就是在new的大括号里被当场定义出来的，Java 管它叫匿名内部类（Anonymous inner class）。
很多人第一次看到这里会懵，因为语言习惯上“类”出现在class关键字后面，而这里整个语法里只有new、接口名、大括号，没有class，没有extends，没有implements。但编译器心里是有数的：它知道你需要一个“实现了ActionListener的类”，于是帮你在这个表达式位置临时造了一个。
1.2 拆解语法结构：真正的“语法糖”在哪里
标准写法长这样：
new 父类名或接口名(构造参数) { // 类体：覆写方法、定义字段、定义方法 };几个关键点需要说清楚：
- 如果
new后面跟的是父类，可以在括号里传构造参数，调用父类的某个构造器；如果跟的是接口，括号里什么都不用写。 - 大括号里可以覆写父类或接口的方法，也能定义自己的字段和方法，但不能定义静态成员（
static final的编译期常量除外）。 - 类的本质已经存在：编译器会为它分配一个内部类名，只是我们在源码层面看不到、也用不到。
所以匿名内部类不是“一个没有名字的对象”，而是“一个没有名字的类”。对象在这里只是一个顺带的结果。这样的设计解决了一个很朴素的需求：有些逻辑只在当前这个调用点用一次，不值得为它单独取一个类名、单独建一个.java文件。就好比公司缺一个临时的迎宾人员，与其正式发一个招聘公告招一个人再安排编制，不如从行政部随便拉一个人过来站一下午。逻辑上都是“有人来干活”，成本差很多。
1.3 它天然拥有的三项特权
我在带新人时总结过匿名内部类的三个“天然特权”，理解了这三条，大部分用法都能自己推导出来：
第一，它能直接访问外部类的实例成员，包括私有成员。原因后面讲字节码时会看到：编译器偷偷给匿名内部类对象塞进了一个外部类引用，靠这个引用访问。
第二，它能捕获外部方法中的局部变量，前提是这个变量满足 final 或 effectively final。这个限制挂在很多程序员嘴边，但真能说清楚原理的人不多，第三章重点展开。
第三，它能在不确定类型细节的情况下快速“适配”接口。比如Collections.sort需要一个Comparator，你现写一个匿名内部类塞进去，比单独定义一个类再new出来要省好几行代码，而且逻辑和调用点紧挨在一起，读代码的人不用跳来跳去。
1.4 它的代价：复用性为零，调试不太友好
好处说够了，也得说清楚代价。匿名内部类最大的问题是没有名字，意味着无法被复用——同一段逻辑不能在两处各自new，只能复制粘贴。其次，调试的时候你会在堆栈里看到com.example.OrderService$1这样的类名，一行行$1、$2很容易让人看晕。实际项目里，我见过不少新人把整段逻辑塞进匿名内部类、一写就是几十行的情况，那个可维护性真的是一场灾难。核心原则是：只有“一次性、就近、逻辑短小”这三个条件同时满足时，匿名内部类才是最佳解；任何一项不满足，就老老实实提取成命名类。
2. 编译后它变成了什么：从 Hello$1.class 看匿名内部类的运行真相
2.1 JVM 的字典里没有“匿名”这个词
很多 Java 开发者写了三年业务代码，从来没注意过编译输出目录里那种带$1的文件。比如你有一个类叫OrderService，文件编译后目录里除了OrderService.class，通常还会冒出一堆OrderService$1.class、OrderService$2.class。这些就是匿名内部类的“正式身份”。
在源码世界里，它是匿名的；但在 JVM 世界里，一切都必须有名字。Java 编译器的处理方式是：每遇到一个匿名内部类，就自动给它编号并取一个合法类名。规则是“外部类名 +$+ 出现顺序”，从 1 开始。于是第一个匿名内部类叫OrderService$1，第二个叫OrderService$2，以此类推。这个编号是编译期的、物理文件层面的，跟你代码里是否写过$1没有任何关系——你在源码里根本接触不到它。
2.2 类文件里藏着三个关键细节
看事实比背结论有用。写一段最简单的代码：
public class TestOuter { private int count = 10; public void start() { Runnable r = new Runnable() { @Override public void run() { System.out.println(count); } }; r.run(); } }用javac编译后，目录下会出现TestOuter.class和TestOuter$1.class。再执行javap -p TestOuter$1反编译，你会看到：
class TestOuter$1 implements java.lang.Runnable { final TestOuter this$0; TestOuter$1(TestOuter); public void run(); }三个关键信息都在这里：
this$0是一个final字段，类型是TestOuter。它就是编译器偷偷塞进来的“外部类引用”。匿名内部类里写的count，编译后实际上是this$0.count。这就是它能访问外部类私有字段的根本原因。- 构造方法
TestOuter$1(TestOuter)接收一个外部类实例，并在构造时把它赋值给this$0。你在源码里写的new Runnable(){...}，编译后等价于执行了一次new TestOuter$1(this)。 run()方法里对count的访问被改写成了对this$0字段的访问。
顺着这个思路，你还可以问一句：如果我在方法里定义了一个局部变量，然后让匿名内部类去读它，变量值是怎么传进去的？答案是：编译器把它变成了构造方法参数和匿名类内部字段。
public void start() { int taskId = 100; Runnable r = new Runnable() { @Override public void run() { System.out.println(taskId); } }; r.run(); }这时代码编译后，TestOuter$1里会多出一个final int val$taskId字段，构造方法的签名变成TestOuter$1(TestOuter, int)。也就是说，局部变量的值在创建匿名内部类对象的那一刻被“复制”进对象里，之后内部类读的是副本，不是原来的栈变量。
2.3 带你做一次 javap 实验：从反编译看透本质
如果你身边有命令行环境，建议现在就花三分钟做这个实验。
先创建TestOuter.java，把上面带count字段的代码粘进去。然后在同目录执行：
javac TestOuter.java ls -l *.class // 观察生成了几个 class 文件 javap -p -c 'TestOuter$1.class' // 反编译匿名内部类javap -c看run()方法的字节码时，你会看到一个典型的getfield TestOuter$1.this$0指令，随后跟着getfield TestOuter.count。这两步连在一起，就是“通过外部类引用读取外部类字段”的完整链条。
说实话，很多“为什么匿名内部类能访问外部类”的玄学解释，都不如自己跑一次javap -c来得直观。字节码是诚实的，它把源码里藏在背后的东西全都摊开给你看。
3. 变量捕获的“不可变”规矩：final 的过去与 effectively final 的现在
3.1 一条从 Java 8 开始变宽松的规则
写匿名内部类时，只要它访问了外部方法的局部变量，你经常会碰到一个编译错误：
Local variable defined in an enclosing scope must be final or effectively final
翻译成大白话：你方法里定义的局部变量，被匿名内部类捕获后，要么明确声明成final，要么保证初始化之后再也不重新赋值（这就是 effectively final，中文常叫“事实不可变”）。
在 Java 8 之前，规则更死：必须是显式的final。很多老项目里你能看到一长串final int声明，多半就是这个原因。Java 8 引入了 effectively final 的概念后，只要编译器确认变量没有在初始化后再被赋值，就不强制你写final关键字了。
public void demo() { int num = 10; // 没写 final，但之后一直没改 Runnable r = new Runnable() { @Override public void run() { System.out.println(num); } }; // num = 20; // 取消这行注释，编译立刻报错 }这段代码里，num声明后从未被重新赋值，所以即使不写final也能编译通过。可一旦你在后面加一行num = 20，编译器就会拒绝编译——因为匿名内部类捕获的变量必须保持不可变。
3.2 为什么不允许在匿名内部类里改外部局部变量
这个设计不是拍脑袋定的，背后是 Java 内存模型和编译器实现机制共同决定的。
局部变量活在虚拟机栈上，它的生命周期通常很短，方法一结束就跟着栈帧一起消失。但匿名内部类对象是活在堆上的实例，生命周期完全随引用——它可能被丢进某个集合、某个静态字段、某个线程池，比当前方法活得久得多。为了让方法结束之后内部类仍能访问这个局部变量，编译器采用了“值拷贝”策略：在创建匿名内部类对象时，把局部变量的值复制到匿名内部类的字段里。
问题来了：如果允许你改那个局部变量，会发生什么？
一种情况是你在匿名内部类里改了值，外部方法读到的还是原变量——两边的值分叉了；另一种情况是外部方法在内部类创建后又改了值，但内部类里读到的还是旧副本。这种“看起来在改同一个变量、实际改的却是两个值”的行为，极其容易产生隐蔽 bug。所以 Java 语言设计者干脆一不做二不休：被捕获的变量不得重新赋值，从源头上消灭分叉。
这里要补充一个细节：如果你捕获的是一个引用类型变量（比如一个List<String>对象），那么不能修改的是变量本身——即不能再让它指向另一个对象。但你可以修改这个对象内部的元素，比如list.add("x")。因为list这个引用变量没有被重新赋值，依然满足 effectively final；而对象内部状态的变化，两个地方看到的是同一个对象，天然一致。
3.3 老一辈程序员用过的数组黑科技
在 Java 8 之前，final 限制比现在严格得多。有些老代码里会用一种“绕过”写法：
public void demo() { final int[] holder = new int[1]; Runnable r = new Runnable() { @Override public void run() { holder[0] = 20; // 这是改了数组里的元素，不是改 holder 变量本身 } }; holder[0] = 10; // 外面也能改 r.run(); System.out.println(holder[0]); // 输出 20 }原理说白了就是用“引用变量不变、引用指向的对象变”来钻 effectively final 的空子。holder这个变量本身从头到尾没被重新赋值，所以编译器放行；但你改的是holder[0]这块内存里的值。
这个手法在并发场景下极其危险：如果不做同步，多个线程同时改一个共享数组元素，轻则可见性问题，重则逻辑混乱。而且读代码的人很难一眼看出原来作者想干嘛。今天再写新代码，我不推荐这种黑科技。真遇到需要在回调里累计状态的需求，优先考虑AtomicInteger这类线程安全的容器，或者干脆提取一个带可变字段的命名类，让意图更清楚。
3.4 顺带一提：Lambda 的捕获规则和它其实一致
Java 8 之后，很多匿名内部类被 Lambda 替代。比如new Runnable(){...}会变成() -> {...}。很多新手以为 Lambda 的捕获规则更宽松，其实不是。Lambda 表达式同样要求捕获的外部局部变量是 final 或 effectively final。规则完全一样，只是 Lambda 消除了“匿名内部类必须有一个类定义”的不少形式感。
真正不同的地方，在于编译方式。匿名内部类会生成独立的.class文件，而 Lambda 在 Java 8 及之后通过invokedynamic指令实现，不适合简单用$1、$2文件来追踪。这属于性能层面的差异，后面第四章讲到选型时会再展开。
4. 项目中最常见的几种打法：监听器、比较器与一次性策略
4.1 事件监听器：匿名内部类最经典的舞台
Java GUI 时代也好，Android 开发也好，事件监听是匿名内部类出现频率最高的场景。原因很直接：监听器通常只服务一个组件，逻辑就写在绑定事件的地方，用匿名内部类可以做到“所见即所绑”。
JButton submitButton = new JButton("提交"); submitButton.addActionListener(new ActionListener() { @Override public void actionPerformed(ActionEvent e) { // 处理提交逻辑 doSubmit(); } });个人建议：如果事件回调里的逻辑超过三五行，最好把核心代码抽成一个独立方法，匿名内部类里只做一行转发调用。这样既保留了匿名内部类就近绑定的优点，又不会让actionPerformed方法膨胀成一坨几十行的泥巴。
4.2 线程与异步回调：Runnable 的经典搭配
老 Java 代码里，new Thread(new Runnable(){...})是教科书里必出现的一行。Java 8 之后完全可以写成 Lambda，但理解匿名内部类版本的功力仍然需要保留——因为不是所有地方都能换成 Lambda。Runnable 接口只有一个抽象方法，所以能换；换完后代码从五行变成一行：
// 匿名内部类写法 new Thread(new Runnable() { @Override public void run() { System.out.println("线程执行"); } }).start(); // Lambda 写法 new Thread(() -> System.out.println("线程执行")).start();这里想强调一个很多人忽略的选择依据：Lambda 只能用在“函数式接口”上，也就是只有一个抽象方法的接口。如果你要创建一个继承了抽象类的匿名类、或一个拥有多个抽象方法的接口实现，Lambda 就完全派不上用场，这时必须回到匿名内部类。你在老项目里经常看到老代码不写 Lambda，空有 Java 8 版本却全是匿名内部类，多半是历史代码没重构，不代表作者不懂 Lambda。
4.3 集合排序：临时比较器的实用写法
匿名内部类在集合操作里最家常的用法，是给排序塞一个临时比较器。
List<String> names = Arrays.asList("Tom", "Alice", "Bob"); names.sort(new Comparator<String>() { @Override public int compare(String a, String b) { return b.compareTo(a); // 降序 } });写比较器时我踩过最典型的坑，是把compare的返回值方向搞反。compare(a, b)返回负数表示 a 在前，正数表示 a 在后，0 表示相等。想升序就a.compareTo(b)，降序就b.compareTo(a)。很多人写着写着就晕了，建议在匿名内部类里加一行注释标明排序方向，这条注释能帮你和后来者省下不少排查时间。
同样，如果同一套比较逻辑要在多个地方复用，我一般会抽成静态常量：
private static final Comparator<String> REVERSE_ORDER = new Comparator<String>() { @Override public int compare(String a, String b) { return b.compareTo(a); } };这样既保留了匿名内部类短小就近的特点，又不会在多个排序点反复复制粘贴同一段逻辑。
4.4 策略模式的一次性落地
真正让我觉得匿名内部类“永远不过时”的场景，是策略模式里的临时策略。
假设你有一个订单服务，结算时需要按不同的促销策略计算折扣。如果每种策略都建一个类，可能一个活动就多出十几个类文件。而有些策略只在这个促销周期用一次，过段时间再也不会被引用，这时完全可以在结算调用点直接注入一个一次性策略：
double realPrice = checkoutService.calculate( originalPrice, new DiscountStrategy() { @Override public double discount(double price) { return price * 0.8; // 全场八折，用完即弃 } } );这个写法的好处是策略定义和策略使用在同一个调用点，读代码时目光不用跳转，就能知道这次结算打的什么折扣。等促销结束，删除这段代码时也不会留下悬空的类文件。
4.5 什么时候该果断说“不”
前面说了不少匿名内部类的优点，但它在实际项目里被滥用的频率同样可观。我给自己定的判断标准大致是这样：
- 匿名内部类方法体超过 5 行，就要警惕；
- 同一份匿名内部类逻辑在一个类里出现两处以上，基本就该提取成命名内部类；
- 它不仅访问外部字段，还跟外部字段产生复杂的读写交互，提取成内部类或独立类会让结构更清晰；
- 需要序列化时，匿名内部类会有额外的坑，老序列化框架对莫名其妙的名字支持得并不好，能提就提。
说白了，匿名内部类是“临时工”的定位，适合顶一两天的班；但如果你发现自己反复需要“临时工”才运转得动，就该考虑是不是岗位编制本身有问题了。
5. 容易翻车的角落：this 指向、构造限制与内存泄漏
5.1 匿名内部类里的 this，不指向外部类
写匿名内部类时最容易忽略的一点是this的语义。
public class Outer { private String name = "outer"; public void test() { Runnable r = new Runnable() { private String name = "inner"; @Override public void run() { System.out.println(this.name); // inner System.out.println(Outer.this.name); // outer } }; } }匿名内部类也是一个类，所以它方法里的this指向的是当前匿名内部类实例，不是外部类实例。如果想从匿名内部类里访问外部类实例，必须用“外部类名.this”的语法：Outer.this.name。这跟普通内部类访问外部类的方式完全一样，只是很多人从来不知道匿名内部类里居然也能用这招。面试时被问到“匿名内部类能不能访问外部类对象”，答案不是什么高深魔法，就是Outer.this。
5.2 匿名内部类没有显式构造函数，但可以用初始化块补齐
匿名内部类的语法决定了它不能声明构造函数，因为构造函数需要类名，而匿名内部类没有名字。这就带来一个实际痛点：有些场景里，创建这个临时类实例时我们希望做点初始化工作。
对应的通用解法是实例初始化块，也就是裸写一对大括号放在类体里：
SomeAbstractClass obj = new SomeAbstractClass() { private int id; { // 这段代码会被编译器塞进构造方法里执行 id = 100; System.out.println("匿名内部类初始化"); } @Override public void doSomething() { System.out.println("id = " + id); } };实例初始化块在继承体系里相当于“构造方法中的一段公共初始化代码”。它的执行时机是在父类构造完成后、自身方法调用前。原理上编译器会把初始化块的内容合并到编译器生成的构造方法里，这正是前面讲过的TestOuter$1(TestOuter)这类构造器内部做的事情之一。
5.3 内存泄漏不是传说：它隐式持有外部类实例
这是匿名内部类最不应该被低估的问题。根据第二章的字节码分析，匿名内部类实例一定有一个this$0字段指向外部类实例。这个引用是编译器自动加上的，你不可见、也无从删除。
如果匿名内部类对象的生命周期很短，比如只是个局部变量，方法结束就随 GC 回收，那没问题。但一旦它被某个生命周期很长的容器或线程持有，问题就来了：
public class LeakDemo { // 静态全局任务列表 private static final List<Runnable> TASKS = new ArrayList<>(); public void registerTask() { TASKS.add(new Runnable() { @Override public void run() { System.out.println("task running"); } }); } }TASKS是静态字段，只要它被引用，里面的 Runnable 对象就不会被回收；而这个 Runnable 对象又持有创建它的LeakDemo实例。即使外部代码早就没有任何LeakDemo的引用了，它依然因为this$0字段被间接引用着，活活留在堆上。每调用一次registerTask，就泄漏一个LeakDemo实例。这在 Android 开发里是教科书级事故，java 服务端同样会碰到，只是多数人很难把“某个静态 List 越来越大”跟几行毫不起眼的匿名内部类联系起来。
处理办法大致分三路：第一，如果匿名内部类不需要访问外部类成员，就把new Runnable(){...}换成顶层类的静态字段或静态内部类实例，避免产生this$0字段；第二，使用没有隐式持有外部类的载体，比如写一个独立的静态内部类实现 Runnable；第三，如果业务允许，匿名内部类的引用不要放进比外部类生命周期更长的容器里。
补充一个容易混淆的点：如果匿名内部类出现在静态方法里，编译器不会给它生成this$0字段，因为静态方法没有当前实例可用，自然也不存在持有外部实例的问题。先判断你的匿名内部类到底在静态上下文还是实例上下文，再判断它到底会不会泄漏，结论往往更准确。
5.4 泛型上下文里的隐性问题
匿名内部类配合泛型使用，偶尔会碰到一些让人挠头的编译问题。最常见的场景是：在泛型方法里直接new一个带类型参数的匿名内部类，编译器的类型推断经常让人捉摸不透。
public static <T extends Comparable<T>> Comparator<T> createComparator() { return new Comparator<T>() { @Override public int compare(T a, T b) { return a.compareTo(b); } }; }这段代码在部分 JDK 版本和泛型嵌套较深的场景里，会报一个模棱两可的类型推断错误。原因在于匿名内部类的方法签名里带有泛型类型变量，而编译器需要确认这个类型变量与外层方法的类型变量是否严格一致。一旦中间隔着类型通配符、复杂的泛型继承，推断就容易出问题。
这不算匿名内部类本身的缺陷，更多是 Java 泛型擦除和类型推断的老毛病。但它在匿名内部类场景里确实更容易暴露，因为类没有名字、没法在声明时显式指定类型参数。遇到这类错误，我的实用建议是：先把类型“定死”，拿到外面去,比如定义一个带泛型参数的命名静态内部类，或者用局部变量先捕获类型信息再传给匿名内部类，尽量避免把所有类型推断压力都压到编译器头上。
5.5 一个越早知道越好的调试技巧
匿名内部类的 debug 体验比较差，因为断点打在匿名内部类的方法里，堆栈里看到的类名都是Outer$1、Outer$2。如果你的类里同时有几个匿名内部类，经常要挨个跑一遍才能确认$1到底是哪一个。
我的经验是：在匿名内部类类体里加一个只有诊断用途的静态不可变字段，比如：
Runnable r = new Runnable() { private static final String TAG = "LeakDemo$registerTask$runnable"; @Override public void run() { ... } };虽然匿名内部类不允许定义一般的静态成员，但编译期常量的static final是允许的。这个TAG字段不会参与业务逻辑，但当你导出堆栈或使用诊断工具时，它能快速帮你定位到“我到底是哪个匿名内部类”。强烈推荐在长生命周期的匿名内部类里保留这个习惯。
6. 面试怎么说：从“会用一行代码”到“讲透底层原理”
6.1 一段能直接背下来的结构化回答
被问到“说一下 Java 匿名内部类”时，不建议上来就只甩一段代码。我给你一个递进式的回答骨架：
先给定义：匿名内部类是没有类名的局部内部类，它在new表达式的位置被定义并实例化，通常用于实现接口或继承父类，在一次性场景里就地注入逻辑。
再说特点：它能直接访问外部类的实例成员和私有成员，能捕获满足 final 或 effectively final 的外部局部变量，且不能显式声明构造函数，不能用static修饰（编译期常量除外）。
然后说原理：编译器会为它生成独立的 class 文件，命名规则是“外部类名$编号”；匿名内部类对象隐式持有一个指向外部类实例的this$0字段，这就是它能访问外部类成员的机制；捕获的局部变量值通过构造函数参数复制进来。
再说适用场景：事件监听器、临时比较器、线程回调、一次性策略实现。
最后补一句你自己的判断：匿名内部类适合“一次性、就近、逻辑短小”的场景，不过度使用；Java 8 之后能被 Lambda 替代的函数式接口尽量用 Lambda。
这套回答从“是什么”到“为什么”再到“怎么用”，时间大概 40 秒到 1 分钟，能覆盖大多数面试官的初级追问。
6.2 面试官越过初级之后追着问什么
第一问：为什么匿名内部类访问的局部变量必须是 final 或 effectively final？
答：因为局部变量在栈上，生命周期短于可能长期存活的匿名内部类对象。编译器把局部变量值复制进匿名内部类字段，如果允许重新赋值，外部变量和内部副本会出现不一致，容易产生隐蔽 bug。所以 Java 直接从语法层面禁止被捕获变量重新赋值。
第二问：匿名内部类和 Lambda 有什么区别？
答：语法上 Lambda 更简洁；编译机制上，匿名内部类生成独立的 class 文件（外部类$编号），Lambda 在 Java 8 后使用 invokedynamic 指令实现，不是简单生成一个类文件；使用范围上，Lambda 只能用于函数式接口（只有一个抽象方法），匿名内部类还可以继承抽象类或实现多方法接口；语义上，匿名内部类里的this指向匿名类自身，Lambda 里的this指向外围类实例。这个对比基本能体现你有没有真正触碰过两者的底层差异。
第三问：匿名内部类会导致内存泄漏吗？
答：会。编译器会给非静态上下文中创建的匿名内部类实例添加this$0字段，指向外部类实例。如果匿名内部类对象生命周期超过外部类，比如被静态集合持有、被线程持有，外部类实例就无法被回收。解决办法是避免长生命周期容器持有匿名内部类对象，或改用静态内部类、静态包装类。
第四问：匿名内部类里this指的是谁？
答：指匿名内部类实例本身。想要外部类对象，用外部类名.this。
第五问：匿名内部类怎么实现“构造函数”的功能？
答：匿名内部类不能写显式构造函数，但可以用实例初始化块（裸大括号）完成初始化逻辑，编译器会把初始化块合并进生成的构造方法中。
这些问题串下来，基本能把“会用”和“理解原理”区分开。面试官如果继续往下挖，大概率会回到字节码层面——那就需要你对javap反编译结果真正熟悉了，顺着第二章的实验结论去答，会比硬背结论扎实很多。
6.3 一段写在最后的个人体会
带团队这几年，我越来越觉得“匿名内部类”是个特别好的试金石。它语法简单到新手十分钟就能上手，却也深到能牵出类加载、编译机制、内存模型一长串底层知识。有人觉得它被 Lambda 取代了，没必要再学，这是极其片面的——且不说大量老代码和框架源码还在用，单说“为什么捕获变量不可变”“为什么会内存泄漏”这两个问题，足以检验一个人是背过面试题，还是真正理解 Java 的运行方式。你去看 Spring、Netty 这些框架的源码，很多匿名内部类的出现位置都特别考究，不是为了省几行代码，而是为了在精确的上下文里注入一段不打算长期留存的逻辑。这才是匿名内部类的正确打开方式：不是炫技，不是偷懒，而是精确判断出“这里只需要一个临时实现”，然后干净利落地用一次，绝不拖泥带水。
