BiConsumer 是 Java 8 引入的函数式接口，声明为 void accept(T t, U u)，专用于接收两个参数并执行无返回值的副作用操作；适用于需将“处理两个对象的行为”作为参数传递的场景，如 Map 遍历、回调封装、DSL 配置等。
Java注释规范Skills
下载
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
BiConsumer 是什么，什么时候该用它
BiConsumer 是 Java 8 引入的函数式接口，定义为 void accept(T t, U u)，专门用于接收两个参数、不返回结果的操作。它不是用来替代普通方法的，而是当你需要把「对两个对象做某件事」这个行为作为参数传递时才真正有用——比如集合遍历中的双参数处理、异步回调的上下文绑定、或者 DSL 风格的配置组装。
常见误用是硬套在本该用普通方法或自定义函数接口的地方，结果让调用方被迫拆包、强转，反而增加复杂度。
适用场景包括：
- 遍历
Map.entrySet()时直接处理key和value - 在
Optional.ifPresentOrElse(...)的 else 分支里传入两个备用值做清理操作 - 封装第三方 SDK 回调，把业务逻辑和上下文对象（如日志 traceId、用户 session）一起注入
怎么写一个可复用的 BiConsumer 回调
关键不是“怎么声明”，而是“怎么让它的两个参数有意义”。别写 (a, b) -> {...} 这种无意义占位，参数名要体现语义，比如 (user, order) -> sendWelcomeEmail(user, order)。
实操建议：
- 优先用方法引用：已有静态方法
UserNotifier::sendOrderConfirmed比 lambda 更清晰 - 避免捕获过多外部变量；若需访问
this或实例字段，考虑改用普通内部类或提取为独立服务 - 如果第二个参数常为 null 或默认值，不要强行塞进
BiConsumer，改用Consumer<t></t>+ 显式传参更安全
Map<String, Integer> stats = new HashMap<>();
stats.put("success", 120);
stats.put("failed", 5);
// 好：参数名即意图
stats.forEach((status, count) -> log.info("Status {}: {}", status, count));
// 坏：意义模糊，且容易在后续扩展中出错
stats.forEach((k, v) -> process(k, v));
和 Consumer、BiFunction 混用时容易踩的坑
最典型的问题是把 BiConsumer 当成「能返回值」的工具。它返回 void，所以不能用于需要链式调用或条件分支的场景。比如想「处理完再判断是否重试」，就不能靠 BiConsumer 自身完成。
几个具体陷阱：
-
Stream.peek()接受Consumer，不是BiConsumer；想在流中处理 key-value 对，得先mapToObj或用forEach - Spring 的
@EventListener不支持直接注入BiConsumer类型 Bean；若要用，得包装成事件处理器，而非裸接口 - 和
BiFunction<t></t>混淆：后者必须返回值，适合做转换；前者只做副作用，适合发通知、存日志、改状态
性能与线程安全要注意什么
BiConsumer 本身无状态，但实现它的 lambda 或方法很可能有。比如：
BiConsumer<String, String> logger = (msg, level) -> {
MDC.put("level", level); // 修改了 ThreadLocal
log.info(msg);
};
这段代码在多线程下会污染 MDC。问题不在 BiConsumer，而在你写的逻辑里有没有共享可变状态。
所以重点检查：
- 是否无意中修改了静态字段、单例 Bean 的状态
- 是否用了非线程安全的集合（如
ArrayList）做缓存 - 是否在 lambda 中创建了新线程但没管理生命周期（比如忘记
shutdown()）
BiConsumer，而是搞清这两个参数之间是否存在隐含依赖、执行顺序是否敏感、以及谁负责清理资源。这些不会在编译期报错，但会在压测或上线后突然暴露。 
