必须调用ThreadLocal.remove()，因为其ThreadLocalMap中value为强引用、key为弱引用，线程复用时若不手动清理，key回收后value仍长期滞留导致内存泄漏；在线程池中应重写afterExecute统一兜底清理。
ThreadLocal.remove() 为什么必须在使用后调用？
在线程池中，线程被复用，ThreadLocal 的值不会自动清除。如果只调用 set() 或 get() 而不调用 remove()，旧线程可能携带前一个任务遗留的 ThreadLocal 值（尤其是大对象或持有外部引用的对象），导致内存无法回收——这不是 GC 漏洞，而是应用层引用泄漏。
关键点在于：ThreadLocal 的内部 ThreadLocalMap 使用弱引用指向 ThreadLocal 实例，但其 value 是强引用。一旦 ThreadLocal 实例被回收（比如被 GC），对应 entry 的 key 变为 null，但 value 仍滞留，直到下一次 set()/get()/remove() 触发探测式清理。而线程池中的空闲线程往往长期不触发这些操作，value 就一直挂着。
在 ExecutorService 中怎么安全调用 remove()？
不能依赖 finally 块写在任务内部——任务可能抛异常未捕获、可能被中断、也可能根本没执行到 finally。更可靠的方式是统一在任务执行完毕后兜底清理，尤其适用于自定义 ThreadPoolExecutor。
- 重写
afterExecute(Runnable r, Throwable t)，在里面对所有已知的ThreadLocal变量显式调用remove() - 确保每个需要隔离状态的
ThreadLocal都是private static final，避免被意外覆盖或重复初始化 - 若使用 Spring 等框架，注意其
RequestContextHolder、TransactionSynchronizationManager等底层也依赖ThreadLocal，它们通常自带清理逻辑；但自定义的必须自己管
示例：
public class CleanThreadPoolExecutor extends ThreadPoolExecutor {
private static final ThreadLocal<string> currentUser = new ThreadLocal();
public CleanThreadPoolExecutor(int corePoolSize, int maxPoolSize, long keepAliveTime,
TimeUnit unit, BlockingQueue<runnable> workQueue) {
super(corePoolSize, maxPoolSize, keepAliveTime, unit, workQueue);
}
@Override
protected void afterExecute(Runnable r, Throwable t) {
super.afterExecute(r, t);
currentUser.remove(); // 必须放在这里，而非任务内部
}
}</runnable></string>
哪些 ThreadLocal 场景最容易漏掉 remove()？
不是所有 ThreadLocal 都需要手动 remove()，但以下三类必须加：
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
- 存储大对象（如
StringBuilder、缓存Map、数据库连接上下文） - 持有业务实体引用（如用户信息
UserContext、租户 ID），且该实体本身引用了更多对象 - 在过滤器、拦截器、AOP 切面中设置，但未配对清理（例如 Spring 的
OncePerRequestFilter默认不清理自定义ThreadLocal）
反例：只在 set() 后跟 get()，从不 remove()；或者只在正常流程里 remove()，但忽略异常分支；又或者把 remove() 写在 try 块末尾却没包住整个逻辑。
remove() 调用时机和性能影响
remove() 本身开销极小，就是从 ThreadLocalMap 中删除一个 entry 并尝试清理脏 entry。它不会触发 full GC，也不阻塞线程。真正影响性能的是「不调用」带来的间接成本：堆内存持续增长、GC 频率上升、甚至 OOM。
- 不要在每次
get()后立即remove()——这会让ThreadLocal失去“线程内共享”的意义 - 应在明确生命周期终点调用，例如：HTTP 请求结束时、数据库事务提交/回滚后、批处理子任务完成时
- 如果线程池配置了
allowCoreThreadTimeOut(true)，核心线程也可能被回收，此时ThreadLocalMap会随线程销毁而释放；但不能依赖这点，因为大多数生产环境禁用该选项
最易被忽略的一点：多个 ThreadLocal 变量共存时，必须各自 remove()，不能只清一个。每个 ThreadLocal 实例在 ThreadLocalMap 中是独立 entry，互不影响。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
