threadlocal不调用remove()会导致内存泄漏，因value被线程池线程长期强引用而key弱引用失效，残留entry无法自动清理，需在业务逻辑出口显式调用remove()触发探测式清理。
ThreadLocal.remove() 不调用会泄漏内存
在高并发 Web 应用（比如 Spring Boot + Tomcat）里，ThreadLocal 不手动 remove()，大概率导致 OutOfMemoryError: Metaspace 或堆内存缓慢上涨。根本原因不是 ThreadLocal 本身大，而是它持有的 value（比如数据库连接、用户上下文、格式化器）被线程池中的线程长期持有，且 key 是弱引用、value 是强引用——key 被回收后 value 变成“不可达但未释放”的残留项，只有 remove() 或 set(null) 才能触发清理。
常见错误现象：java.lang.OutOfMemoryError: GC overhead limit exceeded 出现在压测后期；用 jmap -histo 发现大量自定义对象实例数异常偏高；MAT 分析显示这些对象被 ThreadLocalMap$Entry 强引用。
- Tomcat 默认使用线程池复用
http-nio-8080-exec-*线程，一个请求结束 ≠ 线程销毁 - Spring 的
RequestContextHolder、LocaleContextHolder内部都基于ThreadLocal，它们自己会reset()，但你自定义的不会 - 不要依赖
finally块里写tl.set(null)：这只能清 value，不能触发Entry的探测式清理（remove()会顺带扫描并驱逐 key==null 的脏 entry）
什么时候必须显式调用 remove()
不是所有 ThreadLocal 使用场景都需要 remove()，但只要满足以下任一条件，就必须加：
- 变量生命周期 > 单次请求处理（例如：在 Filter 中 set，在异步线程中用，或跨多个 @Async 方法传递）
- value 是大对象（如
StringBuilder、SimpleDateFormat、缓存 map、加密上下文） - 运行在共享线程池上（
Executors.newFixedThreadPool()、@Scheduled、WebMvcConfigurer注册的拦截器） - 使用了
InheritableThreadLocal且子线程未主动清理（子线程继承后不remove()，父线程结束也没用）
反例：在 Controller 方法里 new 一个 ThreadLocal<integer></integer> 并只在本方法内 get()/set()，理论上可以不 remove() —— 但不推荐，因为难以保证后续没人把它提取成类字段或复用。
remove() 的正确位置：靠近 set()，而非 try-finally 末端
很多人把 remove() 放在 finally 最底部，结果在异常分支里 value 已经被改写或覆盖，导致该清的没清。更稳妥的做法是：在明确知道“这段逻辑已彻底用完该 ThreadLocal”时立即清除，通常就在业务逻辑出口处。
示例（Spring MVC Filter）：
public void doFilter(ServletRequest req, ServletResponse res, FilterChain chain) {
MyContext.set(extractContext((HttpServletRequest) req));
try {
chain.doFilter(req, res);
} finally {
MyContext.remove(); // ✅ 这里清，不是在 catch 之后再清
}
}
- 避免在
catch里单独remove()：如果 try 块里已发生异常但还没执行到业务末尾，value 可能仍是有效状态，提前清掉反而影响错误日志或 fallback 逻辑 - 不要在
@PreDestroy或 Bean 销毁方法里调用remove()：此时线程早已不属于当前 Bean 生命周期 - 若用 Lombok
@Cleanup，注意它生成的是close()，对ThreadLocal无效；必须手写remove()
为什么 ThreadLocal.withInitial() 不能替代 remove()
ThreadLocal.withInitial() 只控制首次 get() 时的默认值构造，和生命周期清理完全无关。它甚至会让问题更隐蔽：因为每次 get() 都可能触发新对象创建（比如 new SimpleDateFormat），而旧 value 如果没被 remove()，就继续挂着。
- 错误认知：“用了 withInitial 就不用 remove 了” → 实际上，withInitial 构造的对象一样会被线程长期持有
- 性能影响：withInitial 的 Supplier 每次首次 get 都执行，若构造开销大（如初始化连接池），又没清理，等于反复浪费资源
- 兼容性无问题，但它解决的是“如何初始化”，不是“何时释放”——这两个问题必须分开处理
真正省心的方式是封装工具类，比如：
public class SafeThreadLocal<T> extends ThreadLocal<T> {
@Override protected void finalize() throws Throwable {
remove(); // ⚠️ 仅作兜底，不能依赖
super.finalize();
}
}
但 finalize 已被废弃，且不保证执行时机，所以仍要靠人工调用 remove()。最可靠的方案，还是在业务边界点写清楚、写对那一行 MyContext.remove()。
