应使用TransmittableThreadLocal（TTTL）或手动透传确保TraceID跨线程传递，每次业务结束前调用remove()清理，再通过MDC或日志框架集成实现自动打印。
在 Java 中，用 ThreadLocal 传递日志追踪 ID（如 TraceID）是常见做法，但容易出错——比如异步线程丢失上下文、线程池复用导致污染、或忘记清理引发内存泄漏。关键不是“存进去”，而是“存得稳、传得准、清得净”。
确保 TraceID 在线程切换时自动继承
主线程生成 TraceID 后，子线程（尤其是线程池中的任务）默认无法访问父线程的 ThreadLocal 值。必须显式透传：
- 使用
TransmittableThreadLocal（TTTL）替代原生ThreadLocal—— 它由 Alibaba 开源，能自动将值从父线程复制到子线程（包括Runnable、Callable、CompletableFuture等场景） - 若不能引入第三方库，需手动包装任务：在提交前读取当前 TraceID，构造新
Runnable并在执行前 set 进子线程的ThreadLocal - Spring 环境下，可结合
ThreadPoolTaskExecutor的setThreadFactory+ 自定义ThreadFactory实现初始化透传
避免 ThreadLocal 内存泄漏
ThreadLocal 的 key 是弱引用，value 是强引用。线程长期存活（如线程池线程）时，若不主动清理，value 会一直持有对象，造成内存泄漏：
- 每次业务逻辑结束前，务必调用
threadLocal.remove()—— 不要用set(null)，它只清 value，不触发 key 回收 - 推荐在
try-finally或Filter/Interceptor的afterCompletion中统一清理 - 若使用 TTTL，也需调用
TransmittableThreadLocal.reset()（或配合其提供的doInContext工具方法）
与日志框架集成，让 TraceID 自动打印
光存 ID 没用，要让它出现在每条日志里：
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
立即学习“Java免费学习笔记（深入）”；
- Logback：配置
%X{traceId}（对应 MDC）；但注意MDC本质也是ThreadLocal，需同样处理透传和清理 - 更稳妥的做法是自定义
ThreadLocal存 TraceID，再通过Logger的putMDC或日志 Layout 的自定义字段注入 - SLF4J + Logback 场景下，可在请求入口（如 Spring MVC
@ControllerAdvice）中MDC.put("traceId", traceId)，出口处MDC.clear()
统一入口生成 & 校验 TraceID
TraceID 应由最外层入口（如 HTTP 请求、MQ 消息）生成，避免多处重复生成导致混乱：
- HTTP 请求：从 Header（如
X-Trace-ID）读取，不存在则生成 UUID 或 Snowflake ID - RPC 调用（Dubbo/Feign）：通过隐式传参或 Filter 拦截，把当前 TraceID 注入下游请求头
- 消息队列（Kafka/RocketMQ）：发送前写入消息 Headers 或 Body 扩展字段，消费端从中提取并 set 到
ThreadLocal - 校验建议：对 TraceID 做简单格式校验（如非空、长度限制），避免无效值污染链路
不复杂但容易忽略细节。核心就三点：用对容器（TTTL 或手动透传）、清干净（remove）、接得上（MDC 或日志适配）。做好这三步，跨线程的日志追踪就能稳住。
