threadlocal 本身不导致内存泄漏，真正危险的是 threadlocalmap 中 value 的强引用在 key 被 gc 回收后仍长期存活，尤其在线程池复用场景下；key 为弱引用、value 为强引用，导致 key==null 的脏条目使 value 无法回收。
ThreadLocal 本身不会直接导致内存泄漏，真正危险的是 ThreadLocalMap 中 value 的强引用链在 key 被回收后仍长期存活——尤其在线程池复用场景下。
为什么 ThreadLocalMap 的弱引用 key 反而容易出事
Entry 的 key 是 WeakReference<threadlocal></threadlocal>，但 value 是强引用。当外部不再持有该 ThreadLocal 实例（比如 Spring Bean 销毁、Web 请求结束），GC 会回收 key，Entry 变成 key == null 的“脏条目”。此时若线程不退出（如线程池中的 Worker 线程），value 就卡在 Thread -> ThreadLocalMap -> Entry -> value 这条强引用链里，永远无法被回收。
常见错误现象：
- 应用运行数小时后老年代持续增长，Full GC 频繁但回收效果差
- 堆 dump 显示大量
ThreadLocalMap$Entry对象的value字段指向业务对象（如UserContext、Connection） -
ThreadLocal声明为局部变量或匿名内部类，生命周期短于线程
set/get/remove 必须配对调用，不能只 set 不 remove
ThreadLocal 的 get() 和 set() 方法内部确实会触发清理逻辑（扫描并删除 key == null 的 Entry），但这是「被动且不彻底」的：它只清理当前哈希槽附近部分脏条目，不保证全表扫描。只有显式调用 remove() 才能立即断开 value 引用。
使用场景中必须注意：
- 在 Web 应用中，务必在 Filter 或 Interceptor 的 finally 块中调用
yourThreadLocal.remove() - 在线程池任务中，如果用了
ThreadLocal，任务结尾必须remove()，不能依赖get()触发清理 - 避免在 lambda 表达式中直接
set()后无后续操作，例如：executor.submit(() -> { ctx.set(...); });—— 这里根本没remove()，风险极高
static ThreadLocal 是双刃剑：延长生命周期反而降低泄漏概率
把 ThreadLocal 声明为 static，能让它被类加载器长期持有着，key 不会被 GC 回收，Entry 始终可访问，从而避免“key 为 null 但 value 滞留”的典型泄漏路径。但这不等于绝对安全：
- value 本身若持有大对象（如缓存、IO 流、数据库连接），仍需主动清理
- 若 static
ThreadLocal在容器中被重复部署（如 Tomcat 多次 reload），可能因类加载器未释放导致 ClassLoader 泄漏 - Spring 管理的 Bean 中注入
ThreadLocal时，不要用@Autowired注入实例，而应通过static工具类封装，否则 Bean 销毁后ThreadLocal实例可能提前失联
线程池环境下必须手动清理，别信“线程会自动销毁”
线程池中的线程是复用的，Thread 对象长期存活，threadLocals 字段也一直存在。哪怕你每次任务都 set() 新值，旧 value 也不会自动替换或清除——因为 set() 是按 ThreadLocal 实例的 hash 查找位置，不是覆盖整个 map。
正确做法示例：
private static final ThreadLocal<user> userHolder = ThreadLocal.withInitial(() -> null);
public void handleRequest() {
try {
userHolder.set(extractUserFromRequest());
doBusinessLogic();
} finally {
userHolder.remove(); // 关键！必须放 finally
}
}
</user>
最容易被忽略的一点：即使你用了 withInitial()，只要 value 是非 null 对象（比如 new 出来的上下文），就必须 remove()；否则下次同一线程执行任务时，get() 返回的仍是上次遗留的对象，不仅可能引发数据污染，更会阻止其被回收。
