函数式接口性能取决于使用方式：延迟执行避免冗余计算（如supplier日志）、小数据集慎用stream、lambda提取为静态常量、优先选用intunaryoperator等基础类型专用接口以减少装箱和gc。
函数式接口本身几乎没有运行时开销，它的性能表现主要取决于使用方式和上下文，而不是接口定义本身。关键不在“接口快不快”，而在于你如何用它避免冗余计算、减少对象创建、控制执行时机。
避免无谓的参数预计算
典型问题出现在日志、条件判断等场景：传入一个已拼接好的字符串，但实际可能根本不输出。
- 错误写法：
showLog(2, "用户ID=" + userId + ",操作=" + action)—— 无论等级是否匹配，字符串都提前拼接好了 - 正确写法：把拼接逻辑封装进函数式接口（如
Supplier<string></string>），只在真正需要时才执行 - 示例：
public static void showLog(int level, Supplier<string> messageSupplier) { if (level == 1) { System.out.println(messageSupplier.get()); // 延迟执行 } } // 调用时只传逻辑，不传结果 showLog(2, () -> "用户ID=" + userId + ",操作=" + action); // 这行根本不会执行 get()</string>
慎用 Stream 链式调用处理小数据集
Stream 的惰性求值和内部迭代有优势，但也有启动成本。对几百条以内的集合，传统 for 循环往往更快。
- Stream 创建、包装、构建流水线本身有对象分配和方法调用开销
- 小数据量下 JIT 优化空间有限，而普通循环更易被内联
- 建议：集合大小
复用 Lambda 实例，减少重复生成
Lambda 表达式在首次调用时会通过 invokedynamic 动态生成类，之后可被 JIT 内联。但如果每次调用都新建 Lambda（比如在循环里写 list.forEach(x -> ...)），就会反复触发类加载或逃逸分析压力。
- 高频场景下，把 Lambda 提取为静态常量或成员变量更稳妥
- 例如：
private static final Predicate<string> NOT_EMPTY = s -> s != null && !s.trim().isEmpty();</string> - 避免在热点路径中写
stream.filter(s -> s.length() > 0).map(...)这类匿名表达式，尤其当该 stream 被反复构造时
优先选用基础类型专用接口
Java 标准库提供了 IntFunction、LongConsumer、DoublePredicate 等特化接口，它们绕过泛型擦除和自动装箱，能显著减少 GC 压力。
- 对比：
Function<integer integer></integer>每次调用都涉及int ⇄ Integer转换 - 优化后：
IntUnaryOperator直接操作原始 int，无对象创建 - 适用场景：数值计算、数组/流处理、高频数学变换等
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
