能，但仅适用于需调用父类构造器、实现多个接口或继承具体类等lambda无法覆盖的场景；其余情况应优先使用lambda，避免内存泄漏与可读性问题。
Java匿名内部类还能用吗？
能，但只在特定场景下值得用——比如Swing/AWT事件监听、单次使用的Runnable或Comparator。JDK 8之后，绝大多数情况该优先用lambda；匿名内部类现在主要用来绕过lambda的限制：访问非final但“事实有效final”的变量、需要调用父类构造器、或者必须继承具体类（而非实现接口）。
常见错误现象：Variable used in lambda expression should be final or effectively final，这时候有人强行改用匿名内部类“解围”，结果引入了更隐蔽的内存泄漏风险。
- Swing中
ActionListener写成lambda后无法调用getSource()以外的组件方法？先确认是不是真需要——多数时候不需要 - 需要在匿名内部类里修改外部变量？别硬扛，把变量包进
AtomicReference或数组（如String[] holder = new String[1]） - 继承
Thread并重写run()？直接用new Thread(() -> { ... }).start()更干净
匿名内部类访问外部变量的真实规则
不是“必须final”，而是“必须有效final”：编译期能确定该变量赋值后不再改变。匿名内部类会捕获变量的副本（primitive类型）或引用（对象），但不会同步后续修改。
典型坑：for (int i = 0; i System.out.println(i)).start(); } 输出全是10——换成匿名内部类也一样，因为循环变量i在所有线程启动前已递增完毕。
立即学习“Java免费学习笔记（深入）”；
- 正确做法：在循环体内声明新变量，如
final int idx = i;，再在lambda或匿名类中用idx - 如果必须修改外部状态，用
AtomicInteger而不是普通int - 匿名内部类持有外部类实例引用，非静态内部类方式容易导致Activity/Fragment内存泄漏（Android场景）
什么时候非得用匿名内部类，不能用lambda？
三个明确信号：
- 要调用父类构造器：lambda只能针对函数式接口，无法指定
super(...) - 需要实现多个接口（lambda只能匹配一个函数式接口）
- 必须继承具体类（如
new TimerTask() { public void run() { ... } }），而TimerTask不是接口
示例：Swing中需要同时响应点击和键盘事件，且逻辑强耦合——new MouseAdapter() { public void mouseClicked(MouseEvent e) { ... } public void keyPressed(KeyEvent e) { ... } }。这里不能用lambda，因为MouseAdapter是抽象类，且包含多个回调方法。
性能与字节码层面的代价
匿名内部类会生成独立的.class文件（如Outer$1.class），每次实例化都触发类加载和对象分配；lambda在JVM层面可能被优化为私有静态方法+invokedynamic，开销更低。
不过实际差异微乎其微，真正要注意的是可读性断层：当匿名内部类超过5行，或者嵌套两层以上，就该拆成命名类或重构逻辑了。
容易被忽略的一点：匿名内部类里的this指向的是它自己，不是外围类——想访问外围类的this，得写OuterClass.this.method()。这个点在线程调试时经常让人卡住几小时。
