biconsumer适合封装mdc清洗行为，因其能自然表达“传入快照+执行清理”语义，接收不可变上下文副本并绑定runnable清理动作，避免跨线程污染，配合快照机制与线程池定制实现安全复用。
在异步高并发环境下，MDC（Mapped Diagnostic Context）容易因线程复用而污染或丢失，BiConsumer 本身不解决线程安全问题，但它可以作为**上下文传递与清理行为的统一封装载体**，配合 InheritableThreadLocal、自定义线程池和显式上下文快照，实现安全、可复用的 MDC 清洗逻辑。
为什么 BiConsumer 适合封装 MDC 清洗行为
BiConsumer
- 接收原始上下文（如 MDC.getCopyOfContextMap() 返回的不可变副本），避免在异步线程里误读/修改主线程上下文
- 绑定一个 Runnable 清理动作（如 MDC.clear() 或 MDC.reset()），确保在目标线程中执行时作用于正确的 ThreadLocal 实例
清洗前必须做快照：避免跨线程污染
MDC 内部基于 ThreadLocal，但普通 ThreadLocal 不会跨线程传递。即使使用 InheritableThreadLocal，线程池复用也会导致子线程继承到过期的 MDC —— 所以不能直接传 MDC 引用，而要传快照：
- 正确做法：在提交异步任务前，调用 MDC.getCopyOfContextMap() 获取只读副本（返回 Map
） - 错误做法：传 MDC.class 或直接传 () -> MDC.get("traceId")，这会在子线程里读取其自身的（空或脏）MDC
- 示例：Map
snapshot = MDC.getCopyOfContextMap();
用 BiConsumer 封装“快照 + 清理”组合逻辑
定义一个标准清洗行为，接受快照和清理动作，确保两者成对出现、语义清晰：
BiConsumer<map string>, Runnable> safeMdcCleaner = (snapshot, cleanup) -> {
// 在目标线程中先还原快照（可选：仅用于日志一致性）
if (snapshot != null) {
MDC.setContextMap(snapshot);
}
try {
cleanup.run();
} finally {
// 强制清空，防止残留
MDC.clear();
}
};</map>
这个 BiConsumer 可被复用于不同异步场景，比如 CompletableFuture 或线程池任务包装器中。
在不同异步场景中安全应用
真正起作用的是调用方式，BiConsumer 是行为契约，需配合执行环境保障线程隔离：
- CompletableFuture 场景：用 thenAcceptAsync 或 whenCompleteAsync 显式指定自定义线程池，并在池中预设 MDC 初始化逻辑；不要依赖 commonPool
- 线程池场景：继承 ThreadPoolExecutor，重写 beforeExecute 和 afterExecute，在 before 中设置快照，在 after 中触发 BiConsumer 清理
- 虚拟线程场景：虚拟线程生命周期短，更需在启动时立即 capture 快照并绑定清理；可结合 Thread.Builder 设置 uncaughtExceptionHandler 并触发同一套 BiConsumer
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
