线程池中threadlocal更易泄漏，因线程复用导致threadlocalmap中弱引用key回收后强引用value滞留；必须在任务结束前用try-finally调用remove()彻底清除entry，避免存大对象或外部引用。

在 Java 线程池中使用 ThreadLocal 时，若不主动清理，极易引发内存泄漏——根本原因是线程复用导致 ThreadLocalMap 中的 Entry（弱引用 Key + 强引用 Value）长期滞留，Value 无法被回收。

为什么线程池中 ThreadLocal 更容易泄漏？

普通线程执行完就销毁，其绑定的 ThreadLocalMap 也随之释放；但线程池中的线程会被反复复用，ThreadLocal 的 value 若未手动清除，会一直留在该线程的 ThreadLocalMap 中，尤其当 value 是大对象（如 Connection、StringBuilder 或自定义上下文）时，会持续占用堆内存，最终 OOM。

正确使用方式：set 后必须 remove

不要依赖 ThreadLocal 的自动清理机制。在线程任务结束前（尤其是 Runnable 或 Callable 执行末尾），显式调用 remove()：

Java Maven Common

Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。

下载

• 避免只用 set(null) —— 这只是把 value 设为 null，Entry 仍存在，Key（弱引用）可能已回收，变成“stale entry”，但 value 引用还在，照样泄漏
• 务必调用 threadLocal.remove()，它会真正从 ThreadLocalMap 中移除整个 Entry
• 推荐写法：用 try-finally 保证执行，例如：
    try {
      myThreadLocal.set(value);
      // ... 业务逻辑
    } finally {
      myThreadLocal.remove(); // 关键！
    }

避免在 ThreadLocal 中存大对象或外部引用

ThreadLocal 本质是“以空间换隔离”，不是缓存工具。设计时应遵循：

• 只存轻量级、线程独有、生命周期与任务对齐的数据（如请求 ID、用户身份标识）
• 禁止存储数据库连接、文件句柄、大型集合等需显式释放的资源
• 避免持有外部对象（如 Service 实例、Spring Bean）的强引用，否则可能阻止整个 Spring 上下文卸载

利用 InheritableThreadLocal 要格外谨慎

子线程继承父线程的 ThreadLocal 值时，若父线程来自线程池，子线程（尤其短生命周期任务）可能让父线程的 ThreadLocal 值意外延长存活时间。除非明确需要传递上下文，否则优先用显式参数传递，或改用 TransmittableThreadLocal（阿里开源，支持线程池场景下的上下文传递并自动清理）。

不复杂但容易忽略：每次 set 就要配对 remove，这是线程池里用好 ThreadLocal 的铁律。

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南