ThreadLocal.get()后不remove()会导致内存泄露，因其key为弱引用而value为强引用，当ThreadLocal被回收后value仍驻留ThreadLocalMap中，在线程池场景下长期累积引发OOM。
ThreadLocal.get()后不remove()为什么会导致内存泄露
因为 ThreadLocal 的底层是用当前线程的 ThreadLocalMap 存储值，而这个 map 的 key 是弱引用（WeakReference<threadlocal></threadlocal>），value 却是强引用。一旦 ThreadLocal 实例被回收（比如定义在局部作用域或被显式置为 null），key 就变成 null，但 value 仍被 map 持有——这块 value 对象无法被 GC，直到线程结束。
在线程池场景下尤其危险：线程长期存活，ThreadLocalMap 中不断堆积“脏 entry”（key == null，value != null），最终引发 OutOfMemoryError: Java heap space。
- 典型现象：
java.lang.OutOfMemoryError配合堆 dump 显示大量ThreadLocalMap$Entry持有业务对象 - 常见场景：Web 容器（Tomcat）、RPC 框架、自定义线程池中复用
ThreadLocal传递上下文（如 traceId、用户信息） - 注意：不是所有
ThreadLocal都会泄露，只有 value 是大对象（如ArrayList、缓存 Map、IO 缓冲区）时才容易暴露问题
什么时候必须调用 remove() —— 不只是“用完就删”
remove() 不是可选项，而是线程池环境下强制动作。它不只是清理当前 key 对应的 entry，还会触发 ThreadLocalMap 内部的探测式清理（expungeStaleEntries），顺手干掉其他已失效的 entry，防止雪球越滚越大。
- 必须 remove 的场景：
Runnable或Callable执行完毕前、Filter/Interceptor 返回前、Spring AOP 方法退出时 - 不能依赖 try-finally？错——必须用 try-finally，因为异常可能跳过后续逻辑；但更推荐用 try-with-resources 封装（需自定义
AutoCloseable包装器） - 不要在构造函数里调用
remove()：此时还没 set，map 可能都不存在
set(null) 和 remove() 的区别：别用错
set(null) 是往 map 里塞一个 key 是当前 ThreadLocal、value 是 null 的 entry，不仅没清掉旧值，还新增了一个“合法但无意义”的条目；而 remove() 是真正删除 key 对应的 entry，并触发清理逻辑。
立即学习“Java免费学习笔记（深入）”；
-
set(null)后再get()会返回null，但旧 value 依然留在 map 里 -
remove()后get()会触发初始化逻辑（如果设置了initialValue()），行为符合预期 - 某些老代码用
set(null)试图“重置”，结果反而加剧泄露
静态 ThreadLocal + 线程池 = 泄露高发组合
静态 ThreadLocal 实例生命周期与类加载器绑定，几乎永不回收；在线程池中，每个工作线程都会为其维护一份 value。若 value 持有 ClassLoader（比如通过反射加载的类、动态代理对象），还可能引发 classloader 泄露，连带整个 webapp 无法卸载。
- 避免 static ThreadLocal 存放大对象；如必须用，务必在每次任务结束时
remove() - 使用
InheritableThreadLocal更要小心：子线程继承的是父线程当时的 value 引用，若未清理，父子线程双份泄露 - JDK 9+ 提供了
Cleaner机制，但ThreadLocal并未默认集成，不能指望自动兜底
最麻烦的不是写错 remove，而是忘了它存在——尤其当 ThreadLocal 被封装在工具类或框架抽象层里时，调用方根本看不到 map 的存在。
