该用匿名内部类仅当「一次性、轻量、紧耦合」：如Swing监听、临时Comparator；需复用、含状态或资源管理时应避免，优先选lambda（函数式接口且不访问实例成员）或静态内部类+弱引用防泄漏。
什么时候该用匿名内部类而不是单独写个类
匿名内部类真正省事的地方，只在「一次性、轻量、紧耦合」的场景里。比如 Swing 的按钮点击、线程启动、Comparator 临时排序逻辑——这些地方你写个完整类反而显得笨重，而且类名难起、文件变多、调用栈还深一层。
常见错误现象：new ActionListener() { ... } 写完发现要复用两次，结果硬生生复制粘贴了一段逻辑；或者把数据库连接、HTTP 客户端这些有状态、需复用、要管理生命周期的对象塞进匿名类里，后面 debug 时发现 Connection 被关了两次或根本没关。
- 适合：单次回调、无状态逻辑、参数简单（如
Runnable、Comparator、ActionListener） - 不适合：需要被多个地方引用、含复杂初始化、涉及资源释放（
close()）、要单元测试覆盖 - 替代方案更清晰时就别硬用：Java 8+ 优先考虑 lambda（
() -> System.out.println("ok")），它本质是函数式接口的语法糖，比匿名类更轻、可序列化更安全
访问外部变量时为什么必须是 final 或 effectively final
匿名内部类实例会持有对外部局部变量的“快照”，JVM 要求这些变量不能中途被改，否则语义就乱了——你改了外面的 count，但匿名类里用的还是构造时那个值，容易误以为同步更新了。
常见错误现象：编译报错 local variables referenced from an inner class must be final or effectively final，然后有人加个 final int count = 0;，接着在匿名类里想自增——不行，final 变量不能赋值第二次。
- 正确做法：用数组包装，比如
int[] counter = {0};，然后在匿名类里写counter[0]++ - 或者改用成员变量（
this.count），但要注意线程安全和生命周期 - Java 8 开始支持 effectively final：只要没显式重新赋值，哪怕没写
final关键字也行，但一旦你在后续代码中给它重新赋值，整个匿名类定义就会编译失败
为什么匿名内部类会导致内存泄漏（尤其 Android 和 GUI 场景）
匿名内部类默认持有所在类的隐式引用（this）。如果这个匿名类被长期持有（比如注册成事件监听器、提交到线程池、传给异步框架），而所在类又比较大（Activity、Fragment、大型 Service），那 GC 就没法回收它——这就是典型的隐式强引用泄漏。
常见错误现象：Android 中 Activity 退出后，Logcat 还能看到它的 onClickListener 在响应点击；或者 Swing 应用关闭主窗口后进程不退出，jstack 看到一堆 SwingWorker 持有 MyFrame 实例。
- 检查是否在非静态上下文中创建了匿名类并传给了长生命周期对象（如
Executors.newCachedThreadPool().submit(new Runnable() {...})） - 修复方式：提取为静态内部类 + 显式弱引用（
WeakReference），或直接用 lambda（lambda 不捕获this，除非你显式写了this::method） - 特别注意：匿名类实现
Runnable或Callable时，如果里面调用了外部类方法，等于间接持有了this
Lambda 和匿名内部类到底怎么选
能用 lambda 就别用匿名类，不是为了时髦，是它更安全、更可控。lambda 是编译器生成的合成方法，不会生成额外的 .class 文件，也不会隐式持有外部类引用（除非你用 this::xxx）。
常见错误现象：把 new Thread(new Runnable() { public void run() { doWork(); } }); 写成习惯，却没意识到 doWork() 是当前对象的方法，于是泄漏了；换成 new Thread(() -> doWork()) 后，问题还在——因为 lambda 里调用实例方法，依然隐式捕获了 this。
- 纯函数式接口（
Runnable、Supplier、Consumer）且不访问实例成员 → 用 lambda，最干净 - 需要访问实例字段或方法 → 先问自己：是不是真需要？能不能抽成静态工具方法？
- 接口有多个抽象方法（非函数式接口）→ lambda 不能用，只能匿名类或普通类
- 需要调试时看清调用栈 → lambda 的栈帧名是
EnclosingClass$$Lambda$1/0x000000080006a840，不如匿名类的EnclosingClass$1直观
匿名内部类不是过时，而是适用边界很窄：当你需要继承某个类（比如 new TimerTask() { ... }），或者接口太老没加 @FunctionalInterface 注解，又或者必须显式控制构造过程时，才值得拿出来用。
