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></string>，需继承InheritableThreadLocal<string></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);
}
}
</string>
容易踩的坑：线程池场景下 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 就断了。
