ThreadLocal 不能直接 new 使用，因其值与线程绑定且线程复用时不自动清理，易致数据错乱或内存泄漏；须 static final 声明、显式 remove()、避免存大对象，异步场景推荐 TransmittableThreadLocal。
ThreadLocal 为什么不能直接 new 一个就用
很多人一看到“线程本地变量”，下意识 new ThreadLocal() 然后 set() 就完事，结果在异步、线程池、Web 请求链路里数据乱窜或为 null。根本原因是：ThreadLocal 的生命周期和线程绑定，但线程复用（比如 ThreadPoolExecutor）不会自动清理上一次的 ThreadLocal 值。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 永远用
static final修饰ThreadLocal实例，避免重复创建和类加载器泄漏 - 在可能复用线程的场景（如 Spring MVC 拦截器、Dubbo Filter、定时任务），必须显式调用
remove()，不能只靠set(null) - 不要在
ThreadLocal里存大对象（如Map、Connection），它不自动释放，容易引发内存泄漏
Spring 中 @Async 或线程池里 ThreadLocal 值丢失怎么办
Spring 的 @Async 默认用 SimpleAsyncTaskExecutor（每次新建线程），看起来值还在；但换成 ThreadPoolTaskExecutor 后，新线程拿不到父线程的 ThreadLocal 值——因为 ThreadLocal 不继承，也不跨线程传递。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 用
TransmittableThreadLocal（阿里 TTL 库），它重写了InheritableThreadLocal的逻辑，支持在线程池中透传 - 如果不能引入第三方库，手动在提交任务前
get()当前线程值，构造新Runnable时闭包捕获并set()到新线程 - 注意：TTL 对
ForkJoinPool和某些异步框架（如 Netty EventLoop）支持有限，得看具体版本
ThreadLocal.get() 返回 null 的常见原因
不是所有没 set() 过的地方都会返回 null，但一旦出现，90% 是以下几种情况：
- 当前线程确实没调过
set()，且没设置initialValue()方法 - 之前调过
remove()，而get()在remove()后执行 - 用了子类继承的
ThreadLocal，但initialValue()被覆盖却没 return 实际值（比如忘了return new XXX();） - 在 Servlet 容器（如 Tomcat）中，请求结束时容器主动调了
remove()，后续 filter 或异步回调再get()就是null
查问题时，优先检查 get() 前是否一定有对应线程的 set()，而不是怀疑 ThreadLocal 本身坏了。
ThreadLocal 和 InheritableThreadLocal 的关键区别在哪
InheritableThreadLocal 看起来能解决“子线程继承父线程值”的问题，但它只在 new Thread() 时复制一次，对线程池完全无效——因为线程池里的线程不是“新创建”的，而是复用的。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 别指望
InheritableThreadLocal能在Executors.newFixedThreadPool()里工作 - 它的继承发生在
Thread.start()那一刻，之后父子线程再无关系 - 如果真要用继承语义，且环境可控（比如全是
new Thread(r).start()），才考虑它；否则一律上TransmittableThreadLocal或手动透传
真正难的不是怎么写 set() 和 get()，是怎么让值在复杂线程模型里“活下来”又“不串门”。漏掉一次 remove()，或者错估线程复用边界，就可能拖垮整个请求链路。
