ThreadLocal内存泄漏是必然结果，需在finally中调用remove()主动清理；避免static存储大对象；线程池场景应重写afterExecute或封装SafeRunnable统一清理；修复后须用jmap、MAT等工具验证效果。
ThreadLocal 内存泄漏不是偶发问题，而是机制设计与使用习惯共同作用的结果。关键不在“能不能用”，而在“怎么清理”。只要线程长期存活（比如线程池、Web容器中的工作线程），而 ThreadLocal 的值没被主动释放，泄漏就几乎必然发生。
必须在 finally 块中调用 remove()
这是最直接、最可靠的做法。不能依赖线程结束自动清理——线程可能复用几百次，而 ThreadLocalMap 中的 value 会一直强引用着对象，哪怕 key 已变成 null。
- 每次 set() 或 get() 后，只要业务逻辑走完，就要 remove()
- 务必放在 try-finally 里，否则异常一抛，清理逻辑就被跳过
- 示例：
try {
threadLocal.set(user);
// 处理业务
} finally {
threadLocal.remove(); // 这一行不能少
}
避免静态 ThreadLocal 存储大对象或集合
static 修饰本身不导致泄漏，但会让 ThreadLocal 实例长期存在；如果它存的是大 byte[]、List、Map 等，每个线程副本都会长期驻留堆内存。
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 不要把缓存、上下文对象、数据库连接等放进 static ThreadLocal
- 若必须用，确保每次 use 后 remove，并控制 value 对象生命周期
- 考虑用轻量级标识（如 userId 字符串）代替完整对象
在线程池场景下统一拦截清理
手动在每个任务里写 try-finally 容易遗漏。更稳妥的方式是让线程池替你做这件事。
立即学习“Java免费学习笔记（深入）”；
- 继承 ThreadPoolExecutor，重写 afterExecute(Runnable r, Throwable t)
- 在该方法里遍历所有已知 ThreadLocal 变量并调用 remove()
- 或者封装一个 SafeRunnable 包装器，在 run() 前后自动清理
用工具验证是否还有残留数据
修复后别只靠代码检查，要用真实手段确认效果。
- 触发一次 full GC 后用 jmap -histo 查看 ThreadLocalMap 实例数是否下降
- 用 MAT 打开 heap dump，搜索 java.lang.ThreadLocal$ThreadLocalMap，看其 value 字段是否仍有大量业务对象
- 监控应用运行时，观察老年代内存是否缓慢上涨，尤其在高并发请求后
