Java函数式接口使用需规避四大陷阱：类型误用（如Runnable代Supplier）、Optional组合空指针、自定义接口缺@FunctionalInterface注解、并发下捕获可变状态引发竞态。

Java 中函数式接口本身不难，但用错地方、选错类型、忽略空值或线程安全，就容易埋下隐患。关键不是背接口名，而是理解“什么时候该用哪个”“什么情况会崩”。

别把 Runnable 当 Supplier 用

Runnable 没返回值，Supplier 必须有返回值。有人为了“省事”，把本该返回对象的逻辑塞进 Runnable，再靠外部变量“取结果”，这既破坏函数式语义，又引入共享状态和线程风险。

• 需要返回值 → 用 Supplier、Function、Callable
• 纯执行无返回 → 才用 Runnable 或 Consumer
• 错误示例：Runnable r = () -> new ArrayList(); // 返回值被丢弃，语义丢失
• 正确写法：Supplier> s = () -> new ArrayList();

小心 Optional 和函数式接口的组合陷阱

Optional.map、flatMap 看似天然适配 Function，但一旦传入 null 的 Function，运行时直接抛 NullPointerException —— 而 Optional 本意是帮你规避空指针的。

java-api-doc-generator

分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。

下载

• 不要直接传匿名内部类或未判空的 lambda 给 Optional 方法
• 建议封装一层校验：optional.map(Objects::requireNonNull).map(transformer)
• 更稳妥：用 Optional.ofNullable(transformer).map(f -> optional.map(f)).orElse(Optional.empty())

自定义函数式接口，必须加 @FunctionalInterface

不加注解，编译器不会检查是否真只有一个抽象方法。后期不小心加了个 default 方法或重载方法，可能让原本能用 Lambda 的地方突然报错，且错误信息不直观。

• 加了注解，编译期就能发现“多抽象方法”或“非函数式”问题
• 接口中可有多个 default/static 方法，但抽象方法只能有一个（Object 的 public 方法除外）
• 命名建议带用途，如 TriPredicate 比 Checker3 更易懂

并发场景下，别假设函数式接口线程安全

Lambda 表达式本身是线程安全的（无状态），但若它捕获了外部可变变量（比如 ArrayList、HashMap、普通字段），那就和普通代码一样存在竞态。

• 避免在 lambda 中修改外部集合、计数器、静态变量
• 必须共享状态？改用线程安全类型（ConcurrentHashMap、AtomicInteger）或加锁
• Stream.parallelStream() 中的 Consumer/Function，同样受此约束 —— 不是用了函数式就自动并发安全

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南