ThreadLocal适合存线程私有上下文，因为它为每个线程提供独立副本、完全隔离，天然支持请求级上下文透传；其价值在于本线程内随时读写清理且不干扰其他线程，但需注意初始化、remove清理及线程池场景下的内存泄漏风险。
ThreadLocal 为什么适合存线程私有上下文
因为 ThreadLocal 本质是每个线程持有一份独立副本，不同线程间完全隔离，天然适配「请求级上下文」这类需要透传但又不能全局共享的场景。它不解决跨线程传递问题，也不替代依赖注入；它的价值就在「本线程内可随时取、写、清理，且不干扰别人」。
常见误用是把它当全局缓存或试图在线程池里长期复用——这会导致内存泄漏或上下文污染。
初始化和 set/get 的基本姿势
别直接 new ThreadLocal 后裸用，务必配合 initialValue() 或构造时提供默认值，否则第一次 get() 会返回 null，容易引发 NPE。
- 推荐写法：
private static final ThreadLocal<String> traceId = ThreadLocal.withInitial(() -> UUID.randomUUID().toString());
- 手动 set 时注意：如果后续逻辑可能多次覆盖（比如 filter → service → dao 多层嵌套），要明确谁负责 set、谁只 get —— 通常入口处 set，出口处 remove
- 避免在 lambda 表达式或异步回调里直接用外部
ThreadLocal变量，除非你确认执行在线程池同一线程中（多数情况不成立）
线程池场景下必须调用 remove() 否则内存泄漏
线程池复用线程，ThreadLocal 的 value 如果没显式 remove()，就会一直挂在 Thread 对象的 threadLocals map 里，value 引用的对象无法被回收。尤其 value 是大对象或含 ClassLoader 时，容易触发 OOM。
- 正确模式：在请求结束（如 Spring 拦截器
afterCompletion()、ServletFilter的doFilter()finally 块）中调用traceId.remove() - 不要依赖
ThreadLocal的 finalize 或弱引用机制——JDK 不保证及时回收，且 value 的强引用链常绕过弱引用设计 - 若使用
CompletableFuture异步，需手动copy上下文：String id = traceId.get(); CompletableFuture.runAsync(() -> { traceId.set(id); try { /* biz */ } finally { traceId.remove(); } });
Spring 中如何安全集成 ThreadLocal 上下文
Spring 自身不管理 ThreadLocal 生命周期，但提供了 RequestContextHolder 这类封装，底层其实也是 ThreadLocal。自己维护时要注意与 Spring 的 request scope 兼容性。
- 避免在 @Async 方法里直接读取原始
ThreadLocal，应通过TaskDecorator显式传递：new ThreadPoolTaskExecutor() {{ setTaskDecorator(r -> () -> { traceId.set(originalId); r.run(); traceId.remove(); }); }} - 若用 MDC（logback 的
MDC.put("traceId", ...)），它内部就是ThreadLocal<map></map>，行为一致，同样要 remove - 测试时容易漏掉：单元测试用
@SpringBootTest时，Web 环境未启动，RequestContextHolder可能为空，需手动RequestContextHolder.setRequestAttributes(...)
最麻烦的不是怎么设，而是什么时候清——漏一次 remove()，就可能在线程池里悄悄活好几天。
