Java匿名内部类必须用new和{}定义，本质是编译生成的独立类文件，仅能继承一个类或实现一个接口，可访问外部final变量，但易致内存泄漏，Lambda仅适用于函数式接口。
Java匿名内部类写法必须带new和{}，缺一不可
匿名内部类不是语法糖，它本质是编译器生成的独立类文件（如 OuterClass$1.class），所以必须显式用 new 调用构造、用 {} 定义类体。常见错误是漏掉大括号，比如写成 new Runnable() —— 这会直接编译失败，报错 error: <identifier> expected</identifier>。
- 只能继承一个类或实现一个接口，不能同时做两件事
- 构造时无法传参给父类（除非父类有无参构造），但可以访问外部方法的
final或“事实 final”变量 - 在 Java 8+ 中，多数场景建议优先用 lambda，但 lambda 仅适用于函数式接口（且仅有一个抽象方法）
Swing/AWT 事件监听器用匿名内部类仍很常见
虽然 addActionListener(e -> {...}) 更简洁，但当你需要复用监听逻辑、或需调用 e.getSource() + 类型强转、或要提前 return 中断执行时，匿名内部类反而更可控。比如处理多个按钮共用一套判断逻辑：
button1.addActionListener(new ActionListener() {
@Override
public void actionPerformed(ActionEvent e) {
JButton btn = (JButton) e.getSource();
if ("save".equals(btn.getActionCommand())) {
saveData();
} else if ("cancel".equals(btn.getActionCommand())) {
clearForm();
}
}
});
- 注意：
ActionEvent的getActionCommand()比getText()更可靠，避免按钮文本变更导致逻辑断裂 - 不要在匿名内部类里直接修改局部变量（非 final），否则编译报错；改用数组包装或转为成员变量
- Android 已弃用此写法（推荐
View.setOnClickListener+ lambda），但 Java SE 桌面程序中仍大量存在
匿名内部类引用外部对象可能引发内存泄漏
匿名内部类隐式持有外部类实例的引用。如果它被长期持有（比如注册到静态监听器、线程池任务、或单例管理器中），会导致外部 Activity/Fragment/Frame 等无法回收。
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 典型泄漏场景：
SwingWorker子类里用匿名内部类更新 UI，而该 Worker 被缓存复用 - 修复方式：改用静态内部类 +
WeakReference持有外部对象，或确保监听器生命周期与宿主一致（如在dispose()时显式removeActionListener） - IDE（如 IntelliJ）会警告 “Anonymous inner class may cause memory leak”，别忽略它
Java 8 后 Lambda 不等于万能替代
lambda 表达式只适用于函数式接口，而很多老 API 接口不是函数式接口——比如 WindowAdapter（继承自 WindowAdapter，有 7 个空方法）。你不能对它写 lambda，必须用匿名内部类或子类。
立即学习“Java免费学习笔记（深入）”；
- 错误写法：
frame.addWindowListener(() -> {})→ 编译失败，因为WindowListener有 7 个抽象方法 - 正确做法：用匿名内部类只重写关心的方法，比如
new WindowAdapter() { public void windowClosing(WindowEvent e) { ... } } - 也可以用
javax.swing.WindowConstants.DO_NOTHING_ON_CLOSE配合手动退出，绕过监听器
真正容易被忽略的是：匿名内部类的类型推导发生在编译期，它绑定的是声明时的接口/类，而不是运行时实际对象。一旦接口签名变化（比如新增 default 方法），旧匿名类不会自动适配——这点比 lambda 更“稳定”，但也更僵硬。
