ThreadLocal 内存泄漏是弱引用设计导致的必然结果：key 用弱引用避免 ThreadLocal 对象泄漏，但 value 需手动 remove 否则在线程池等长生命周期线程中堆积；唯一可靠解法是显式调用 remove()。

ThreadLocal 内存泄漏不是 bug，而是弱引用设计下的必然结果——它用“键可自动回收”换来了“值必须手动清理”的责任转移。

为什么 Entry 的 key 必须是弱引用

如果 key 是强引用，ThreadLocal 实例一旦被外部置为 null，它仍会被 ThreadLocalMap 中的 Entry 持有，导致自身无法被 GC 回收。这会造成 ThreadLocal 对象本身的长期驻留，尤其在大量定义匿名 ThreadLocal 或 Spring Bean 中注入 ThreadLocal 的场景下，泄漏更隐蔽、更顽固。

弱引用 key 的作用很明确：只要外部不再强引用该 ThreadLocal 实例，下次 GC 就能把它收走，避免 ThreadLocal 对象堆积。

但代价也很清楚：key 变成 null 后，Entry 依然存在，value 还牢牢被强引用着。

泄漏真正发生的条件

光有 key=null 不会立即泄漏，关键在于线程是否长期存活：

• 普通短生命周期线程：执行完就销毁，ThreadLocalMap 随线程一起回收，value 自然释放
• 线程池中的核心线程：复用不销毁，ThreadLocalMap 始终存在，残留的 value 就卡在内存里出不去
• Web 容器（如 Tomcat）中：请求线程来自线程池，一次请求 set 一个大对象，没 remove，下次请求又来一套——value 积累速度极快

Entry 清理机制其实存在，但不可靠

ThreadLocalMap 并非完全放任不管。它在 set()、get()、remove() 等方法中会触发 expungeStaleEntry()，主动扫描并清除 key == null 的 Entry，同时把后续哈希冲突位置上也顺带清理一遍。

但这个机制有两个硬伤：

• 只在 ThreadLocal 的常规操作时触发，如果某个 ThreadLocal 只 set 过一次、之后再没调用过 get 或 set，那它的 stale Entry 就永远沉睡
• 清理是启发式、非全量的，不会遍历整个 table，漏掉部分 stale Entry 很常见

真正可靠的解决方案只有显式 remove()

remove() 是唯一能及时切断 value 强引用链的操作。它不只是清空当前 Entry，还会触发一次完整的 stale 清理，效果比被动等待强得多。

最佳实践建议：

• 在线程复用场景（如 Filter、Interceptor、@Async 方法）中，每次使用完 ThreadLocal 后紧跟 remove()
• 用 try-finally 包裹，确保异常路径下也能清理：try { tl.set(x); ... } finally { tl.remove(); }
• 避免在 ThreadLocal 中存放大对象（如 byte[]、List、Map），尤其不要存 IO 流、数据库连接等资源类对象
• Spring 环境下可考虑使用 RequestContextHolder 替代自定义 ThreadLocal，它由框架自动 manage 生命周期