ThreadLocal内存泄漏的根本原因是ThreadLocalMap中Entry的key为弱引用而value为强引用，导致key被回收后value仍驻留；必须显式调用remove()清理，尤其在线程池场景下。
ThreadLocal为什么会内存泄漏
根本原因不是 ThreadLocal 本身，而是它的静态内部类 ThreadLocalMap 中的 Entry 继承自 WeakReference——key 是弱引用，value 却是强引用。当外部对 ThreadLocal 的引用消失（比如局部变量出作用域、Bean 被销毁），key 被 GC 回收，但 value 还挂在 ThreadLocalMap 的数组里，无法被访问也无法自动清理。
常见现象：用线程池（如 ThreadPoolExecutor）反复复用线程时，ThreadLocal 的 value 累积不释放，最终 OOM；堆 dump 里能看到大量残留的 value 对象，对应的 key 为 null。
- 只在主线程短生命周期使用？风险低，但不等于没风险
- Web 应用中配合 Filter 或 Interceptor 使用？必须配
remove() - Spring 的
@Transactional或RequestContextHolder底层也依赖ThreadLocal，它自己做了 cleanup，但自定义的不会
为什么不能只靠 get/set 自动清理
ThreadLocal.get() 和 set() 确实会在探测到 key == null 的 stale entry 时顺手清理一两个，但这是「被动 + 随机 + 不彻底」的：只清理当前哈希桶附近连续的 null key 条目，不扫描全表，也不保证每次调用都触发。
典型误判场景：线程执行完任务后不再调用任何 ThreadLocal 方法，map 里的脏 entry 就一直挂着；或者只调用 get() 但没触发 rehash，stale entry 堆积。
立即学习“Java免费学习笔记（深入）”；
- clean up 发生在
set()的扩容路径或get()的探测失败后，不是必然执行 - 即使触发了，也只清理「当前探查链」上的 null key，不是全量 sweep
- value 引用的对象可能持有 DB 连接、大 byte[]、甚至整个上下文对象，泄漏成本远高于 key
remove() 不是可选项，是必调操作
只要 ThreadLocal 生命周期短于线程（尤其是线程池场景），就必须在业务逻辑结束前显式调用 remove()。这不是“推荐做法”，是防止泄漏的硬性补丁。
示例：在 try-finally 或 try-with-resources 中包裹，确保无论是否异常都会执行：
private static final ThreadLocal<SimpleDateFormat> DATE_FORMAT = ThreadLocal.withInitial(() -> new SimpleDateFormat("yyyy-MM-dd"));
错误写法：DATE_FORMAT.set(...); 后无清理 → 泄漏
正确写法：
try {
DATE_FORMAT.get().parse("2024-01-01");
} finally {
DATE_FORMAT.remove(); // 必须！不能省
}
- 不要依赖线程退出时自动清理——线程池线程永不退出
- 不要在
ThreadLocal初始化时用 lambda 捕获外部变量，容易延长 value 生命周期 - 如果 value 是可关闭资源（如
Connection），应在remove()前手动 close，再remove()
弱引用 key 的设计意图与现实落差
设计上，key 设为弱引用是为了让 ThreadLocal 实例能被及时回收，避免因 map 持有强引用导致其无法 GC。但这个设计把清理责任转嫁给了使用者：value 的生命周期必须由程序员显式控制。
真正起保护作用的是「及时 remove」，而不是「key 是弱引用」。很多人以为 weak reference = 自动安全，结果掉进坑里。
- Entry 的 key 弱引用仅解决「ThreadLocal 对象本身」的泄漏，不解决 value 泄漏
- 没有
remove()，value 会随线程存活，哪怕 key 已为null - 某些 JDK 版本（如 8u202+）在
ThreadLocalMap.expungeStaleEntries()中加强了清理，但仍不替代主动remove()
最常被忽略的一点：在线程复用场景下，不 remove() 的代价不是“多占点内存”，而是 value 可能携带过期状态（比如上一个请求的用户 ID、事务标志），造成隐蔽的逻辑错乱。
