InheritableThreadLocal 默认浅拷贝无法满足TraceID透传需求，因其不支持可变对象隔离和SpanID派生逻辑；需重写childValue实现父ID派生子ID，但线程池中该方法不触发，须配合TaskDecorator或手动包装Runnable传递上下文。
为什么直接用 InheritableThreadLocal 传 TraceID 不够用
默认情况下，InheritableThreadLocal 只做浅拷贝：子线程构造时复制父线程的值引用。如果 TraceID 是可变对象（比如自定义的 TraceContext），子线程修改它会污染父线程；如果 TraceID 是字符串但需生成新 ID（如从父 ID 派生出子 SpanID），原机制无法自动处理派生逻辑。
这时候必须重写 childValue 方法——它在每次创建子线程时被调用，传入父线程当前值，返回子线程应持有的新值。
如何正确重写 childValue 实现 TraceID 派生
典型场景是 OpenTracing 或 SkyWalking 风格的链路透传：子 SpanID 应基于父 SpanID 生成（如追加后缀、哈希或递增），而非直接复用。关键点在于：childValue 必须是纯函数，不依赖外部状态，且返回不可变结果。
- 不要在
childValue中调用UUID.randomUUID()——这会切断父子关联，变成全新链路 - 推荐用父 TraceID + 分隔符 + 子序号生成新 ID，例如：
"parent-abc123-001" - 若使用
ThreadLocal<String>，需继承InheritableThreadLocal<String>并覆写childValue
public class TraceIdInheritableTL extends InheritableThreadLocal<String> {
@Override
protected String childValue(String parentValue) {
if (parentValue == null) return generateRootTraceId();
// 派生逻辑：保证可追溯、不可逆、无副作用
return parentValue + "-sub" + System.nanoTime() % 1000;
}
private String generateRootTraceId() {
return "root-" + UUID.randomUUID().toString().substring(0, 8);
}
}
容易踩的坑：线程池场景下 childValue 不触发
线程池复用线程，子线程不是“新建”而是从池中取出，InheritableThreadLocal 的继承只发生在 Thread 构造阶段。所以即使你重写了 childValue，在线程池提交任务时它根本不会被调用。
- 必须配合
ThreadPoolExecutor的beforeExecute或使用装饰型Runnable手动传递上下文 - 常见做法：提交任务前捕获当前 TraceID，包装 Runnable，在执行前 set 到子线程的
InheritableThreadLocal - Spring Boot 用户可借助
TaskDecorator，在decorate方法里显式调用traceIdTL.set(parentValue)
性能与兼容性注意点
childValue 在每次线程创建时执行，如果内部有复杂计算或锁操作，会拖慢线程启动。实际生产中应避免：
- 在
childValue中访问数据库、远程服务或同步日志 - 返回对象未冻结（如返回
new ArrayList<>()而非Collections.unmodifiableList） - 忽略空值处理：父线程未设值时
parentValue为null，需明确是否生成 root ID 还是透传 null - JDK 9+ 对
InheritableThreadLocal的继承行为未变，但某些容器（如 Tomcat）会清理线程局部变量，需确认其ThreadLocalLeakPreventionListener是否清除了你的TraceIdInheritableTL
真正难的不是写对 childValue，而是确保它在整个调用生命周期里——从 HTTP 入口、到线程池、再到异步回调——始终被正确触发和隔离。漏掉任意一环，TraceID 就断了。
