必须显式封装traceId，因线程池复用导致MDC无法自动继承；需通过TraceableRunnable/Callable快照并还原上下文，或装饰线程池统一拦截所有提交入口。
在分布式系统中，为每个请求生成唯一 traceId 并贯穿整个调用链路（包括线程池内的异步任务），是实现可观测性的基础。但线程池会复用线程，导致 MDC（Mapped Diagnostic Context）等上下文无法自动传递。因此，不能依赖 ThreadLocal 的“自然继承”，而需在提交任务前显式封装 traceId。
为什么直接提交 Runnable/Callable 会丢失 traceId
Java 线程池中的线程是复用的，新任务执行时，其所属线程的 ThreadLocal（如 SLF4J 的 MDC）仍保留上一个任务留下的旧值，或为空。若未主动复制当前线程的 traceId 到新任务执行时的上下文中，日志将缺失或错乱。
常见误区：仅在入口处 put traceId 到 MDC，却未考虑异步分支；或误以为自定义 ThreadPoolExecutor 就能自动透传——其实仍需手动拦截任务包装。
封装自定义任务类：TraceableRunnable 和 TraceableCallable
核心思路：在提交任务前，捕获当前线程的 traceId（及完整 MDC 内容），并将其快照保存到任务对象内部；任务真正执行时，先还原该上下文，再运行业务逻辑，最后清理，避免污染后续任务。
示例实现：
public class TraceableRunnable implements Runnable {
private final Runnable delegate;
private final Map<String, String> contextMap;
public TraceableRunnable(Runnable delegate) {
this.delegate = delegate;
// 快照当前 MDC（含 traceId）
this.contextMap = MDC.getCopyOfContextMap();
}
@Override
public void run() {
// 执行前还原上下文
if (contextMap != null) {
MDC.setContextMap(contextMap);
} else {
MDC.clear();
}
try {
delegate.run();
} finally {
// 执行后清理，防止线程复用污染
MDC.clear();
}
}
}
// 同理可实现 TraceableCallable（用于 submit(Callable) 场景）
统一拦截提交动作：装饰线程池或重写 submit 方法
不建议每个 submit 都手动 new TraceableRunnable —— 易遗漏、难维护。更稳妥的方式是封装一层“带追踪能力”的线程池：
- 方式一：继承 ThreadPoolExecutor，重写 execute() 和 submit() 方法，自动包装任务
- 方式二：使用装饰器模式，提供静态工具方法如 TraceThreadPool.wrap(Runnable)
- 方式三（推荐）：基于 Spring 的 @Async 场景，配合 AsyncConfigurer 自定义 TaskExecutor，并在其中完成 trace 封装
关键点：必须覆盖所有提交入口（execute、submit(Runnable)、submit(Callable)、invokeAll 等），否则仍有漏网之鱼。
与主流链路框架协同（如 SkyWalking、Sleuth、Arthas）
若已集成 Sleuth 或 SkyWalking，它们通常已提供 TaskDecorator 或类似机制：
- Sleuth：配置 spring.sleuth.async.enabled=true，并注册 TaskDecorator Bean，自动包装线程池任务
- SkyWalking：通过插件 apache-commons-executors-plugin 支持，或手动调用 ContextManager.capture() / ContextManager.continued()
- 自研场景：确保 traceId 存储位置统一（如 MDC["traceId"]），避免与框架冲突
注意：不要同时混用多种 trace 上下文复制逻辑，否则可能重复 put 或覆盖失效。
