ThreadLocal核心用途是线程级变量隔离，避免多线程共享导致的数据覆盖；内存泄漏主因是未调用remove()致value强引用无法回收；InheritableThreadLocal支持父子线程值传递，但异步框架需额外传播。
ThreadLocal 最核心的用途是实现线程级变量隔离——每个线程拥有自己独立的副本，互不干扰。它不是用来“共享”数据的，恰恰相反，是用来避免共享的。
为什么不能直接用普通静态变量存用户上下文
比如在 Web 应用中想存当前登录用户 ID，有人会写 static Long userId。这会导致多线程下互相覆盖：线程 A 设置了 1001，线程 B 紧接着设成 1002，A 后续读到的就变成 1002 了。
ThreadLocal 能让每个线程持有自己的 userId 副本：
private static final ThreadLocalCURRENT_USER_ID = ThreadLocal.withInitial(() -> null);
调用 CURRENT_USER_ID.set(1001) 只影响当前线程，其他线程读 CURRENT_USER_ID.get() 仍是各自原来的值（或初始值）。
立即学习“Java免费学习笔记（深入）”；
ThreadLocal 内存泄漏的真实原因和规避方式
常见误解是“ThreadLocal 本身导致内存泄漏”，其实根源在于：ThreadLocalMap 中的 key 是弱引用，但 value 是强引用；线程长期运行（如线程池中的线程），而用户忘记调用 remove()，就会造成 value 无法被回收。
- 使用
withInitial()创建时，value 默认不会泄漏，但后续手动set()的值仍需清理 - 在线程复用场景（如 Servlet 容器、自定义线程池）中，务必在逻辑结束时调用
CURRENT_USER_ID.remove() - 不要依赖
ThreadLocal的构造函数或initialValue()做资源分配（如开数据库连接），因为不保证只执行一次
与 InheritableThreadLocal 的关键区别
普通 ThreadLocal 的值不会传递给子线程；InheritableThreadLocal 会在子线程创建时，把父线程当时的值复制一份过去。
典型误用场景：
- 用
ThreadPoolExecutor提交任务，期望子线程能读到主线程的ThreadLocal值 → 实际读不到，除非显式用InheritableThreadLocal -
InheritableThreadLocal的继承只发生在new Thread()时，对ForkJoinPool或多数异步框架（如 CompletableFuture）无效 - Spring 的
RequestContextHolder底层用了InheritableThreadLocal，但 Spring MVC 会主动在异步线程中做上下文传播，不是靠继承自动完成的
真正难处理的从来不是怎么设值，而是什么时候清、在哪清、谁来清——尤其在线程被池化复用时，漏掉一次 remove() 就可能让整个请求链路的上下文错乱，且问题往往延迟暴露。
