Java ThreadLocal 线程池环境下内存泄漏怎么排查？

Question

仓乃文 · Accepted Answer

ThreadLocal 为每个线程维护独立的变量副本，存在 Thread 对象的 ThreadLocalMap 中。线程池中线程是复用的，如果使用完 ThreadLocal 不调用 remove()，线程归还后 ThreadLocal 的值仍然驻留，导致内存泄漏甚至数据串号（下一个请求读到上一个请求的数据）。泄漏场景： ```java private static final ThreadLocal currentUser = new ThreadLocal<>(); public void handleRequest() { currentUser.set(getUserFromToken()); // 处理业务... // 忘记 remove()，线程归还线程池后 User 对象无法回收 // 下一个请求可能拿到上一个用户的 User } ``` 正确写法： ```java public void handleRequest() { try { currentUser.set(getUserFromToken()); // 处理业务... } finally { currentUser.remove(); // 必须在 finally 中清理 } } ``` 排查方法： ```bash # 1. jmap 导出堆转储 jmap -dump:live,format=b,file=heap.hprof # 2. MAT 分析，搜索 ThreadLocal # 查看 Thread -> ThreadLocalMap -> Entry[] 的引用链 # 找到泄漏的对象和对应的 ThreadLocal key # 3. 代码中全局搜索 ThreadLocal.set # 检查每个 set 是否有对应的 remove ``` 补充说明： - ThreadLocalMap 的 key 是弱引用，但 value 是强引用，key 被 GC 后 value 仍然存在 - Spring 框架的 RequestContextHolder 内部用 ThreadLocal，框架已处理 remove - 自定义 ThreadLocal 一定要在 finally 中 remove，这是铁律 - 线程池场景下数据串号比内存泄漏更危险——用户 A 看到用户 B 的数据