ThreadLocal 提供线程隔离的变量副本机制，get() 返回 null 是因未初始化，需重写 initialValue() 或用 withInitial()；泄漏源于 ThreadLocalMap 中 value 的强引用未及时 remove；异步场景需手动透传。
ThreadLocal 不是“保证线程变量独立性”的工具，而是提供**线程隔离的变量副本机制**——每个线程访问的是自己独有的实例，底层靠 Thread 对象内部的 ThreadLocalMap 实现。
为什么直接 new ThreadLocal<String>() 之后 get() 返回 null？
这是最常见误用：以为 ThreadLocal 会自动初始化值。实际上 get() 只是查当前线程的 ThreadLocalMap，没存过就返回 null。
- 正确做法是重写
initialValue()方法，或使用withInitial(Supplier)静态工厂 - 避免在构造后立刻
get()而不设初值，尤其在 Spring 管理的 Bean 中容易因代理/延迟加载导致意外 null - 若用
set(null)再get()，仍会返回null，这不是“未初始化”，而是你显式存了null
ThreadLocal<String> localName = ThreadLocal.withInitial(() -> "default"); System.out.println(localName.get()); // 输出 "default"
ThreadLocal 泄漏的根本原因和规避方式
泄漏不是因为 ThreadLocal 本身，而是 ThreadLocalMap 的 Entry 使用弱引用指向 ThreadLocal，但 value 是强引用 —— 如果线程长期存活（如线程池中的线程），而用户忘记调用 remove()，value 就一直占内存，且无法被回收。
- 所有在
try-finally块末尾加local.remove()，尤其在线程复用场景（如 Servlet 容器、Dubbo 线程池） - 不要依赖
ThreadLocal的finalize()清理 —— 它不保证及时执行，且 JDK 9+ 已弃用 - 若 value 是大对象（如
StringBuilder、缓存 Map），泄漏代价更明显
在 Spring Web 应用中误用 ThreadLocal 导致请求间数据污染
Spring MVC 默认使用同一线程处理一个请求（从 DispatcherServlet 到 Controller），但如果用了异步（@Async、CompletableFuture）或手动启新线程，ThreadLocal 值不会自动传递。
立即学习“Java免费学习笔记（深入）”；
-
@Async方法默认使用SimpleAsyncTaskExecutor（每次新建线程），原线程的ThreadLocal完全不可见 - 若需透传，得用
ThreadPoolTaskExecutor配合自定义TaskDecorator，手动拷贝ThreadLocal值 - Spring Security 的
SecurityContextHolder默认就用ThreadLocal，所以异步方法里取不到认证信息是常态，不是 bug
public class ContextCopyingDecorator implements TaskDecorator {
@Override
public Runnable decorate(Runnable runnable) {
Map<ThreadLocal<?>, Object> context = new HashMap<>();
for (ThreadLocal<?> tl : CONTEXT_HOLDER_MAP.keySet()) {
context.put(tl, tl.get());
}
return () -> {
try {
context.forEach((tl, val) -> tl.set(val));
runnable.run();
} finally {
context.keySet().forEach(ThreadLocal::remove);
}
};
}
}
真正难处理的从来不是怎么设值，而是什么时候清、谁负责清、跨线程时怎么续。哪怕只在一个方法里临时用，只要线程可能被池化，remove() 就不能省。
