threadlocal 不会自动引发内存泄漏，问题在于线程池中线程复用导致 value 强引用残留；key 为弱引用被回收后，value 成“僵尸条目”无法 gc；必须在业务结束时调用 remove() 彻底清除 entry，推荐 try-finally 或 filter/切面统一清理。
ThreadLocal 本身不会自动引发内存泄漏，问题出在它的使用方式和线程生命周期不匹配——尤其是在线程池场景下。核心矛盾在于：Entry 的 Key 是弱引用（ThreadLocal 实例），Value 却是强引用（你存的数据）。当 ThreadLocal 对象被回收后，Key 变成 null，但 Value 仍牢牢挂在 ThreadLocalMap 里，线程又长期存活，数据就“卡”在内存中出不去。
内存泄漏的真实发生路径
不是 ThreadLocal 没释放，而是它存的值没被清理：
- 线程池中的线程复用：一个线程执行完 A 任务后，ThreadLocal 里还存着 A 的用户上下文；接着执行 B 任务，如果不清理，A 的数据还在，B 的数据又追加进去
- Key 被 GC 回收了（因为是弱引用），但 Entry.value 仍是强引用，指向一个本该丢弃的对象
- 这个 Entry 变成 “key=null, value=有效对象” 的“僵尸条目”，GC 找不到根路径回收 value，内存就悄悄涨起来了
- 反复复用几十上百次，ThreadLocalMap 越来越臃肿，最终可能 OOM
remove() 不是可选项，是必做动作
调用 threadLocal.remove() 的本质，是主动断开 value 的强引用链，让 value 和 Entry 都变成 GC Roots 不可达的对象。它比 set(null) 或赋值为 null 更彻底——后者只是覆盖 value，Entry 还在；remove() 是直接从 table 数组中移除整个 Entry。
- 必须在业务逻辑结束时立即调用，不能依赖“线程结束自动清理”，因为线程池里的线程根本不会结束
- 推荐写在 try-finally 块的 finally 中，确保无论是否异常都会执行
- 如果 ThreadLocal 是静态变量（常见于工具类），remove() 就更关键——它不随方法调用栈销毁，全靠你手动清
Web 应用里怎么统一清理
每个 Controller 方法都手写 try-finally 太容易漏。更可靠的方式是借助请求生命周期钩子：
- Spring 环境下，用 @AfterReturning 或 @AfterThrowing 切面，在接口返回或异常后统一 remove 当前线程绑定的 ThreadLocal
- Servlet 容器中，写一个 Filter，在 doFilter 链末尾调用 remove()，确保每次 HTTP 请求结束即清理
- 避免在拦截器 preHandle 里 set、在 afterCompletion 里 remove 的错位设计——如果 preHandle 抛异常，afterCompletion 可能不执行
别把 remove() 当万能解药
它能解决 value 残留，但治不了设计层面的问题：
- 如果存的是大对象（如 byte[]、Map、DTO），即使 remove() 了，之前已分配的内存也得等 GC；高频小对象+不清理，才是泄漏温床
- remove() 对已泄露的“null key” Entry 有间接帮助：ThreadLocalMap 的 get/set/remove 内部会触发探测式清理（expungeStaleEntries），顺带扫掉一批僵尸条目
- 真正健壮的做法是：remove() + 静态 ThreadLocal（避免实例被意外置 null）+ 必要时用 TransmittableThreadLocal 解决父子线程传递后的残留问题
