ThreadLocal不是线程私有变量的自动托管工具，而是以线程为维度的Map查找机制；真正隔离靠每个线程独立持有ThreadLocalMap实例，static final声明仅共享ThreadLocal对象本身，各线程操作的是各自Thread.threadLocals中的值。
ThreadLocal 不是“线程私有变量”的自动托管工具，它只是提供了一种以线程为维度的 Map 查找机制；真正隔离靠的是每个线程持有独立的 ThreadLocalMap 实例。
为什么直接 new ThreadLocal() 不能保证线程安全？
很多人误以为声明一个 static final ThreadLocal<String> holder = new ThreadLocal<>(); 就万事大吉——其实这只是共享了同一个 ThreadLocal 实例，而每个线程访问时，底层会从自己的 Thread.threadLocals（即 ThreadLocalMap）中 get/set 值。关键点在于：
-
ThreadLocal.set()写入的是当前线程对象内部的threadLocals字段，与其他线程完全无关 - 如果忘记调用
remove()，在线程复用场景（如线程池）下会导致内存泄漏：key 是弱引用，value 是强引用，GC 清不掉 value - 子线程不会自动继承父线程的
ThreadLocal值，除非显式使用InheritableThreadLocal
在线程池中使用 ThreadLocal 的正确姿势
线程池里线程被反复使用，ThreadLocal 的 value 若未清理，上一次请求留下的值可能污染下一次请求。典型错误是只在业务逻辑开头 set()，却没在结尾 remove()。
- 务必在 try-finally 中调用
remove()，例如：try { contextHolder.set(userContext); doWork(); } finally { contextHolder.remove(); // 必须！不能只用 set(null) } - 不要用
set(null)代替remove()：这只会把 value 设为 null，entry 仍存在，key 为 null 的 stale entry 积累后会触发ThreadLocalMap的探测式清理，但不可靠 - 若需初始化默认值，优先重写
initialValue()方法，而非在业务代码里判断 null 后 set —— 更简洁且天然线程安全
ThreadLocal 与 InheritableThreadLocal 的行为差异
普通 ThreadLocal 对子线程完全不可见；InheritableThreadLocal 则在子线程创建时，把父线程对应 key 的 value 复制一份（浅拷贝）到子线程的 ThreadLocalMap 中。
- 仅对 new Thread() 有效；
ExecutorService提交的Runnable不触发继承（因为不是新线程，而是复用） - 复制发生在
Thread.init()阶段，之后父线程修改不影响子线程，子线程修改也不影响父线程 - 若需跨异步任务传递上下文（如 WebFlux、CompletableFuture），得配合
TransmittableThreadLocal（阿里 TTL 库）或手动透传
性能和内存泄漏的隐性代价
每次 get() 或 set() 都要哈希查找当前线程的 ThreadLocalMap，虽然平均 O(1)，但比普通字段访问慢一个数量级。更严重的是泄漏风险：
- 只要线程还活着（比如线程池里的空闲线程），其
ThreadLocalMap中的 value 就一直被强引用，无法回收 - 常见泄漏路径：Filter/Interceptor 中 set 但没 remove → HTTP 请求结束，线程归还池中，value 却残留
- JDK 8 已在
get()/set()/remove()中加入探测式清理逻辑，但依赖哈希冲突触发，不能当作兜底手段
真正可靠的方案只有两个：严格配对 remove()，或改用短期生命周期的局部变量（如方法参数、栈上对象）替代 ThreadLocal。
