匿名内部类是Java中“定义即实例化”的语法糖，用于满足单次使用的接口/抽象类契约，适用于非函数式接口、需调用父类构造器、定义字段或方法等Lambda无法处理的场景。
OuterClass$1.class）。
它不是炫技工具，而是为了解决“这个逻辑只用一次，但又必须满足接口/抽象类契约”的现实问题——比如点一下按钮、跑一个线程、排一次序。写成独立类反而冗余，用 Lambda 又受限（比如需要访问非 final 局部变量，或需调用父类构造器），这时候匿名内部类就是最直接的解法。
什么时候必须用匿名内部类，而不能用 Lambda？
Lambda 表达式只能用于函数式接口（仅含一个抽象方法），且无法处理以下真实场景：
-
new Thread(Runnable)可以用 Lambda，但new TimerTask()（非函数式接口，有多个 public 方法）不行，只能用匿名内部类 - 需要显式调用父类有参构造器：
new AbstractList<string>() { ... }</string>必须传参初始化，Lambda 无法做到 - 需要在类体内定义字段或额外方法（哪怕只是临时 debug 打印）：
new Comparator<string>() { private int count = 0; @Override public int compare(...) { return ...; } }</string> - Java 8 之前项目，或某些遗留框架回调接口含多个方法（如
WindowListener），你只关心windowOpened，但必须实现全部 7 个方法——这时匿名内部类配合空实现更清晰（比 Lambda 强制全写强）
GUI 事件监听和线程创建：最常踩坑的两个地方
Swing/AWT 中写 button.addActionListener(new ActionListener() { ... }) 看似简单，但容易忽略三点：
- 隐式持有外部类引用 → 如果外部类是 Activity 或 Fragment（Android）或长生命周期组件，可能造成内存泄漏；解决办法：把监听逻辑抽到静态内部类，或用弱引用包装
- 局部变量访问限制：Java 8+ 允许“事实 final”，但一旦你在匿名类里尝试修改
int i = 0;，编译直接报错 —— 不是运行时异常，是语法拒绝 - 事件方法中调用
SwingUtilities.invokeLater(...)容易漏：Swing 是单线程模型，所有 UI 更新必须在 Event Dispatch Thread，否则界面卡死或不刷新
同理，new Thread(new Runnable() { ... }).start() 常见错误是忘记捕获异常：run() 方法内抛出未检查异常会静默终止线程，建议包裹 try-catch 或设置 Thread.setDefaultUncaughtExceptionHandler。
Comparator 和策略临时实现：排序与解耦的实际选择
当你要按多字段动态排序，又不想暴露完整策略类时，匿名内部类比 Lambda 更灵活：
立即学习“Java免费学习笔记（深入）”；
Collections.sort(employees, new Comparator<Employee>() {
@Override
public int compare(Employee a, Employee b) {
int nameCmp = a.getName().compareTo(b.getName());
if (nameCmp != 0) return nameCmp;
return Integer.compare(a.getAge(), b.getAge()); // 支持 null-safe 处理
}
});
- Lambda 写法简洁，但一旦需要加日志、断点调试、或处理
null（比如a.getName()可能为 null），就得拆成多行，可读性反而下降 - 如果该比较逻辑后续被复用（比如在另一个 service 里也要同样排序），就该立刻提取为命名类或静态方法，而不是复制粘贴匿名类
- 注意：泛型擦除下，
new Comparator<String>() {...}的类型信息在运行时已丢失，不要依赖它做反射判断
