17370845950

Java函数式接口是编译器强制约束的单抽象方法（SAM）接口，@FunctionalInterface为可选但推荐的显式标注；Lambda类型由目标接口上下文推导，须严格匹配参数与返回值签名。

Java 中的函数式接口不是语法糖，而是编译器强制约束的接口类型：必须有且仅有一个抽象方法（@FunctionalInterface 可显式声明并校验）。

如何识别一个接口是否为函数式接口

关键看它是否满足「单抽象方法」（SAM）规则，和是否被 @FunctionalInterface 标注 —— 后者不是必需，但强烈建议加，否则编译器不会报错，直到你尝试用 Lambda 赋值时才暴露问题。

• Runnable、Comparator、Predicate、Function 都是 JDK 自带的函数式接口
• 含多个抽象方法的接口（如自定义接口里写了两个 void doA() 和 int doB()），即使没加 @FunctionalInterface，也不能用于 Lambda 表达式
• 默认方法（default）和静态方法不破坏函数式接口性质；Object 的公共方法（如 toString()）也不算抽象方法

Lambda 表达式与函数式接口的绑定规则

Lambda 本身没有类型，它的类型由上下文中的目标函数式接口决定。编译器靠参数数量、类型、返回值反推匹配哪个接口。

• 写 () -> System.out.println("hi")，只有在赋值给 Runnable 或其他无参无返回接口时才合法
• s -> s.length() > 0 可匹配 Predicate，但不能赋给 Function（虽然语义相似，但接口签名不同）
• 参数类型可省略（类型推导），但一旦省略，所有参数都得省；不能只写 (String s, t) -> ... —— t 类型缺失会编译失败

常见误用：把非函数式接口强行当 Lambda 使用

最典型的错误是忽略继承关系或重载导致的歧义。例如：

interface BadExample {
    void run();
    void stop(); // 第二个抽象方法 → 不是函数式接口
}

此时写 BadExample e = () -> {}; 会编译报错：BadExample is not a functional interface。更隐蔽的是：

• 某个类实现了多个函数式接口（如同时实现 Runnable 和 Supplier），传入 Lambda 时可能因重载解析失败而报错
• 泛型擦除后签名冲突：比如 Consumer 和 Consumer 在字节码中都是 Consumer，若方法重载仅靠泛型区分，Lambda 传参会编译失败
• 用 new Thread(() -> {...}) 没问题，但换成 new Thread((Runnable)() -> {...}) 就多余 —— 编译器已能推导，强转反而可能掩盖类型不匹配

何时该自己定义函数式接口

当标准库的 Function、BiFunction、UnaryOperator 等无法准确表达业务语义时，定义带名称的接口比裸 Lambda 更利于维护。

• 命名即契约：比如 OrderValidator 比 Predicate 更明确意图
• 便于添加 JavaDoc 和默认行为（如空检查、日志埋点）
• 避免过度泛型：不要为了“通用”而定义 TriFunction，JDK 8 没提供不代表你一定要补全；先用 BiFunction> 或封装对象，比自造轮子更稳妥

真正容易被忽略的是：Lambda 表达式捕获变量时，引用的对象必须是「实际上的 final」（effectively final）。哪怕只是漏改一个 ++i，编译器就拒绝绑定 —— 这和函数式接口无关，但常和它一起出问题。