17370845950

函数式接口是且仅有一个抽象方法的接口，Lambda通过参数和返回值匹配该方法；可含任意default、static及Object方法；@FunctionalInterface仅为校验注解。

函数式接口就是 Java 里「能用 Lambda 写实现」的接口，前提是它**有且仅有一个抽象方法**——不是“看起来像函数”，而是编译器能靠这个约束把 (x) -> x + 1 这种写法准确绑定到唯一方法上。

为什么必须只有一个抽象方法？

因为 Lambda 表达式不写方法名，只靠参数类型和返回值来匹配。如果接口有两个抽象方法（比如 doA() 和 doB()），JVM 就没法知道你写的 () -> System.out.println("hi") 到底想实现哪个。

• 编译器靠这个规则做类型推导，不是靠注解；@FunctionalInterface 只是“提醒+校验”，不加它也照样是函数式接口（只要满足 SAM）
• 可以有任意个 default 方法、static 方法，甚至重写 Object 的方法（如 toString()），都不影响它是函数式接口
• 常见误判：把 Runnable 当成“无参无返回”专用接口就对了，但别以为 Comparator 不是函数式接口——它只有 int compare(T o1, T o2) 一个抽象方法，所以也是

Java 内置四大核心接口怎么选？

别背名字，看方法签名和使用意图：

• Supplier：无参 → 有返回，典型场景是“懒加载”或“造数据”，比如 LocalDate::now、() -> new Random().nextInt()
• Consumer：有参 → 无返回，适合“做了就完事”，比如 System.out::println、s -> log.info("received: {}", s)
• Predicate：有参 → boolean，专干判断，比如 s -> s != null && !s.isBlank()，自带 and()/or() 链式组合
• Function：有参 → 有返回（类型可变），专注“转换”，比如 String::length、s -> s.trim().toLowerCase()，支持 andThen() 和 compose() 组合

注意：基本类型有特化版（IntSupplier、LongConsumer 等），避免装箱开销；两个参数用 BiFunction、BiPredicate；三个及以上参数就得自定义，标准库没提供。

自定义函数式接口时最容易踩的坑

不是语法错，而是语义和复用性问题：

• 别为了“看起来高级”硬套 @FunctionalInterface——如果接口未来大概率要加第二个抽象方法（比如从“校验”扩展出“修复”），那就别标，否则改接口会直接 break 所有调用处
• 参数命名和泛型别太随意：MyProcessor 不如 Transformer 直观；方法名别叫 handle()，优先用 apply() / test() / get() 这类通用动词，方便开发者直觉理解
• 默认方法别写副作用逻辑：比如在 andThen() 里偷偷打印日志，会让使用者困惑——函数式接口强调“纯行为”，副作用该由 Consumer 显式承担

@FunctionalInterface
public interface TriFunction {
    R apply(T t, U u, V v);
}

// 使用示例
TriFunction formatter = (name, age, isStudent) ->
    name + "(" + age + ")" + (isStudent ? "[S]" : "");
String result = formatter.apply("Alice", 22, true); // "Alice(22)[S]"

真正难的不是写出一个函数式接口，而是判断某个需求该不该用它——比如“回调通知”用 Consumer 没问题，但“需要返回状态码+错误信息”的场景，就该老老实实写普通接口，别硬塞进 Function 里。