threadlocal内存泄漏在线程池中几乎必然发生，因线程复用导致threadlocalmap长期存活，key为null后value仍被强引用链持有；必须显式调用remove()并在finally块中保障执行。
ThreadLocal 内存泄漏不是“会不会发生”的问题，而是“什么时候暴露”的问题——尤其在线程池中，它几乎必然发生，除非你主动干预。
为什么线程池是内存泄漏的高发场景
线程池复用线程，线程生命周期与应用一致。而 ThreadLocalMap 是 Thread 的成员变量，只要线程活着，ThreadLocalMap 就不会被回收。每次任务执行时调用 set() 或 get()，都会向该线程的 ThreadLocalMap 中写入一个 Entry。一旦 ThreadLocal 实例失去外部强引用（比如局部变量作用域结束、或静态引用被置为 null），其作为 key 的弱引用就会在下次 GC 时被清除，Entry 变成 key=null, value=强引用对象 的状态。
此时 value 仍通过如下强引用链存活：
- Thread → threadLocals（ThreadLocalMap）→ table[] → Entry → value
由于线程不退出，这条链一直存在，value 永远无法被 GC 回收。
静态 ThreadLocal 常见但危险的用法
很多人把 ThreadLocal 声明为 private static，认为这样更安全。但它只解决了 key 不被提前回收的问题，并未解决 value 泄漏：
- static 声明让 ThreadLocal 实例长期存活，key 不会变 null，Entry 不会“失效”
- 但若忘记调用 remove()，value 依然永远留在当前线程的 ThreadLocalMap 中
- 尤其在 Spring AOP、Filter、Interceptor 等拦截链中，一次请求可能多次 set，却只在开头 get，结尾不 remove
如何定位泄漏的 ThreadLocal 值
排查关键不是找 ThreadLocal 实例，而是找它持有的 value 对象：
- 用 jmap -histo:live pid 查看堆中高频小对象（如 String、Integer、DTO、Connection 等）是否异常增长
- 用 jstack pid 获取线程栈，确认活跃线程数是否稳定；若线程数不变但老年代持续增长，怀疑 ThreadLocalMap 积累
- 用 MAT（Memory Analyzer）打开 heap dump，按 “ThreadLocalMap” 或 “java.lang.ThreadLocal$ThreadLocalMap” 聚类，查看其 table 数组中大量 Entry 的 value 类型和大小
- 重点关注 value 引用链末端的对象：是否是本该随请求结束就释放的上下文、用户凭证、数据库连接等
真正有效的防御措施
不能依赖 ThreadLocalMap 自带的“探测式清理”（get/set 时顺手清理 key=null 的 Entry），因为那只是被动兜底，且不覆盖所有路径：
- 务必在业务逻辑结束处显式调用 threadLocal.remove()
- 最稳妥方式是放在 finally 块 中，确保异常路径下也执行
- 避免在 ThreadLocal 中存放大对象（如 byte[]、大 Map、流、IO 资源），哪怕短期使用
- 对框架层（如 WebFilter、AOP 切面）统一封装 ThreadLocal 工具类，在 entry 和 exit 处配对 set/remove
- 必要时可重写 ThreadLocal 的 finalize()（不推荐）或借助 ThreadLocal 的 cleanUp() 钩子（JDK 21+ 实验性支持），但生产环境仍以 remove 为准
