函数式接口是且仅有一个抽象方法的接口,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;三个及以上参数就得自定义,标准库没提供。
立即学习“Java免费学习笔记(深入)”;
自定义函数式接口时最容易踩的坑
不是语法错,而是语义和复用性问题:
- 别为了“看起来高级”硬套
@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 里。










