默认线程工厂无法传递业务上下文，因其创建的线程不继承父线程MDC（基于ThreadLocal），导致异步日志traceId丢失；需通过Runnable装饰器或自定义ThreadFactory配合MDC快照与清理来保障上下文准确传递。

直接在任务执行前捕获上下文、在线程创建时注入、并在执行后清理，是保障日志追踪维度不丢失的核心动作。单靠线程工厂只能解决“首次创建”时的上下文快照，无法应对线程复用带来的污染问题，必须配合 Runnable 装饰器或 MDC 手动管理策略。

为什么默认线程工厂做不到业务上下文传递

ExecutorService 默认使用的 Executors.defaultThreadFactory() 创建的线程是“干净”的：不继承父线程的 MDC（Mapped Diagnostic Context），也不携带任何业务 ID（如 traceId、tenantId、userId）。因为 MDC 底层依赖 ThreadLocal，而子线程不会自动复制父线程的 ThreadLocal 值——即使你在提交任务前调用了 MDC.put("traceId", "abc123")，池中线程执行时仍读不到它。结果就是异步日志里 traceId 为空，链路断裂，排查困难。

自定义 ThreadFactory 的正确写法（仅作基础快照）

它适合在新线程诞生瞬间做一次上下文“冻结”，但不能替代任务级隔离。关键点是深拷贝而非引用：

• 使用 MDC.getCopyOfContextMap() 获取当前上下文副本，避免后续父线程修改影响
• 在 newThread() 中新建线程后，立即通过 MDC.setContextMap(...) 绑定到该线程
• 为防止异常中断导致清理遗漏，建议在线程的 UncaughtExceptionHandler 中也补一次 set + clear

示例片段：

ThreadFactory factory = r -> {
  Thread t = new Thread(r);
  Map<String, String> parentMdc = MDC.getCopyOfContextMap();
  t.setUncaughtExceptionHandler((th, ex) -> {
    if (parentMdc != null) MDC.setContextMap(parentMdc);
    log.error("Uncaught in {}", th.getName(), ex);
    MDC.clear();
  });
  return t;
};

更可靠的做法：Runnable 装饰器（推荐主线）

线程复用是常态，一个线程执行完带 traceId 的任务 A，紧接着执行无上下文的任务 B，B 就可能误继承 A 的 MDC。装饰器能确保每次任务调度都独立封装上下文：

• 构造装饰器时捕获 MDC.getCopyOfContextMap()
• 在 run() 开头调用 MDC.setContextMap(context)
• 在 finally 块中执行 MDC.clear()，无论是否异常都清理干净
• 可统一包装 submit(Runnable)、submit(Callable)、invokeAll 等所有入口

这样每个任务的日志上下文完全自治，彻底规避线程污染风险。

虚拟线程场景需额外注意

Java 21+ 的虚拟线程（Virtual Threads）生命周期极短、数量极大，ThreadLocal 不再自动继承，MDC 更不会跨虚拟线程传递。此时仅靠 ThreadFactory 不够，必须在 submit 时显式恢复上下文：

• 提交前获取 MDC.getCopyOfContextMap()
• 在虚拟线程内部第一行执行 MDC.setContextMap(context)
• 执行完毕立即 MDC.clear()，否则可能被 JVM 复用的虚拟线程残留污染
• 建议搭配 Logback 1.5+ 或适配 Loom 的日志框架，它们已内置部分上下文传播支持