JavaLambda表达式与函数式编程的概念

Lambda表达式本质是函数式接口的实例化快捷写法，依赖接口仅含一个未实现抽象方法的契约；必须为函数式接口才能使用，否则编译报错。

Java 中的 Lambda 表达式不是函数式编程的全部，而是它在 JVM 上落地的关键语法糖；没有 @FunctionalInterface 约束和明确的单抽象方法契约，-> 写得再像函数也没用。

为什么必须是函数式接口才能用 Lambda

Lambda 表达式本质是函数式接口的实例化快捷写法，编译器靠接口里「只有一个未实现的抽象方法」来推断语义。一旦接口多了一个抽象方法，或者用了 default / static 方法但没处理好继承关系，就会报 Incompatible functional interface 错误。

• @FunctionalInterface 是可选注解，但强烈建议显式添加——它让 IDE 和编译器提前校验，而不是等你写完 Lambda 才报错
• 像 Runnable、Comparator、Function 这些 JDK 自带接口，都符合函数式接口定义；自己定义时别漏掉 public abstract 修饰符（即使不写，编译后也默认存在）



• 注意：如果父接口有抽象方法，子接口又没重写，那子接口可能意外变成非函数式接口

Lambda 和匿名内部类最实际的区别在哪

表面上看只是写法更短，但核心差异在作用域和变量捕获行为上。

• 匿名内部类能访问所有外部类成员（包括 this），而 Lambda 只能访问 final 或“事实上 final”的局部变量——这不是语法限制，而是为了支持闭包在多线程下的安全共享
• Lambda 不会创建新类文件（javap -c 反编译可见它被编译为私有静态方法 + invokedynamic 调用），而匿名内部类每次都会生成 Outer$1.class 这类文件
• Lambda 无法直接使用 super 或 this 引用外部类实例，想调用外部类方法得显式写成 OuterClass.this.method()

常见误用：把 Lambda 当成万能函数对象

很多人一上来就用 Function、Supplier 套来套去，结果代码越来越难读，甚至出现类型爆炸。

• 优先用语义明确的自定义函数式接口，比如 RetryPolicy 比 BiFunction 更易懂
• 避免深层嵌套 Lambda：像 list.stream().map(x -> x.stream().filter(...).collect(...)) 这种，可读性差且容易引发 NullPointerException
• 不要为了用 Lambda 而忽略传统循环——当逻辑含多个条件分支、状态更新或异常处理时，for 循环反而更清晰

interface Calculator {
    int compute(int a, int b);
}
// 正确：单抽象方法，可用 Lambda
Calculator add = (a, b) -> a + b;

// 错误示例（编译不过）：
interface BadCalculator {
    int compute(int a, int b);
    void log(String msg); // 多了一个抽象方法 → 不是函数式接口
}

真正卡住人的往往不是语法，而是搞不清「这个 Lambda 到底绑定到哪个接口」「它捕获的变量生命周期是否可控」「下游接收方是不是真需要函数对象而非具体值」——这些地方不画个执行时序图或打个断点，光看代码很容易绕晕。