Java线程池不自动传递TraceId，需通过装饰器模式包装Runnable/Callable，在提交时捕获并执行时恢复上下文，同时注意ThreadLocal清理、Callable返回值透传及与Sleuth/SkyWalking等框架集成。
Java 中线程池本身不自动传递 TraceId，因为子线程会丢失父线程的上下文（如 ThreadLocal 中的 TraceId）。要实现跨线程池的链路追踪，不能靠线程池“自己支持”，而是通过装饰器模式包装 Runnable（或 Callable），在任务提交时捕获当前线程的上下文，并在执行时主动恢复。这本质是手动做上下文透传，而非依赖线程池能力。
用装饰器包装 Runnable 捕获并还原 TraceId
核心思路：在提交任务前，从当前线程的 ThreadLocal（如 SkyWalking、Sleuth 或自定义的 TraceContext）中读取 TraceId，封装进一个带上下文的装饰类；执行时先将该 TraceId 绑定到新线程的 ThreadLocal，再调用原任务逻辑。
- 定义装饰器类，构造时保存原始
Runnable和当前快照的上下文（如Map<String, Object>或序列化后的TraceContext） -
run()方法内先context.restoreToCurrentThread()，再delegate.run() - 注意：若使用
CompletableFuture或异步回调，还需对thenApply等方法做类似装饰
适配不同线程池提交方式（execute/submit/invokeAll）
不是所有提交入口都直接接受 Runnable：比如 submit(Runnable) 返回 Future，invokeAll(Collection<Callable>) 接受 Callable。因此装饰器需覆盖多种类型：
- 对
Runnable：用TraceRunnable包装 - 对
Callable<V>：用TraceCallable<V>包装，call()前 restore，结束后 clear（避免内存泄漏） - 对
ExecutorService：可写工具方法wrap(Runnable)/wrap(Callable)，统一处理
避免 ThreadLocal 泄漏与生命周期管理
ThreadLocal 不清理会导致内存泄漏（尤其在线程复用的线程池中）。装饰器不仅要“设”，更要“清”：
立即学习“Java免费学习笔记（深入）”；
- 在
run()或call()执行完成后，显式调用TraceContext.clear() - 若使用 InheritableThreadLocal，它只在
new Thread()时继承，对线程池无效，必须手动透传 - 推荐使用
TransmittableThreadLocal（阿里 TTL 库），它能穿透线程池，但需配合其TtlExecutors包装线程池 —— 这属于替代方案，非装饰器模式，但更省心
与主流链路框架集成要点
如果已在用 Sleuth 或 SkyWalking，不要重复造轮子：
- Sleuth 提供
LazyTraceExecutor和TraceableExecutorService，内部已做装饰，只需用Tracing.current().tracer()获取上下文 - SkyWalking 的
TraceCrossThread工具类可序列化/反序列化上下文，适合跨进程，线程内可用ContextManager配合装饰器 - 自研框架建议将上下文抽象为接口（如
TraceCarrier），让装饰器只依赖接口，不耦合具体实现
不复杂但容易忽略的是上下文清理和 Callable 的返回值透传 —— 如果任务有返回值且后续还要继续追踪，得把上下文也随 Future 一并传递下去，否则下游链路就断了。
