先说结论：ThreadLocal 导致的内存泄漏并非偶发问题，而是机制设计与使用习惯共同作用的结果。关键不在于“能不能用”，而在于“怎么清理”。只要线程长期存活（比如线程池、Web 容器中的工作线程），而 ThreadLocal 的值没有被主动释放，泄漏就几乎必然发生。修复手段很明确：在 finally 中调用 remove()、避免用 static 存储大对象、线程池场景统一清理，最后用 jmap/MAT 验证效果。
这段话其实已经把问题说透了。但很多人还是会追问：为什么 ThreadLocal 的内存泄漏不是“可能发生”，而是“必然结果”？原因在于，ThreadLocalMap 的 key 是弱引用，而 value 是强引用。线程一旦复用，key 被回收后 value 依然存在，除非你主动调用 remove()。下面逐条拆解修复方案。
必须在 finally 块中调用 remove()
这是最直接、最可靠的做法。不能依赖线程结束自动清理——线程可能复用几百次，而 ThreadLocalMap 中的 value 会一直强引用着对象，哪怕 key 已变成 null。
- 每次 set() 或 get() 后，只要业务逻辑走完，就要执行 remove()
- 务必放在 try-finally 里，否则异常一抛，清理逻辑就会被跳过
- 示例：
try {
threadLocal.set(user);
// 处理业务
} finally {
threadLocal.remove(); // 这一行不能少
}
避免用静态 ThreadLocal 存储大对象或集合
static 修饰本身不直接导致泄漏，但会让 ThreadLocal 实例长期存在；如果它存的是大 byte[]、List、Map 等，每个线程副本都会长期驻留堆内存。
- 不要把缓存、上下文对象、数据库连接等放进 static ThreadLocal
- 若必须使用，确保每次 use 后 remove，并控制 value 对象的生命周期
- 考虑用轻量级标识（如 userId 字符串）代替完整对象
在线程池场景下统一拦截清理
手动在每个任务里写 try-finally 容易遗漏。更稳妥的方式是让线程池替你完成这件事。
- 继承 ThreadPoolExecutor，重写 afterExecute(Runnable r, Throwable t)
- 在该方法里遍历所有已知 ThreadLocal 变量并调用 remove()
- 或者封装一个 SafeRunnable 包装器，在 run() 前后自动清理
用工具验证是否还有残留数据
修复后别只靠代码检查，要用真实手段确认效果。
- 触发一次 Full GC 后用 jmap -histo 查看 ThreadLocalMap 实例数是否下降
- 用 MAT 打开 heap dump，搜索 java.lang.ThreadLocal$ThreadLocalMap，看其 value 字段是否仍有大量业务对象
- 监控应用运行时，观察老年代内存是否缓慢上涨，尤其在高并发请求后
