threadlocal.remove()必须手动调用，因线程复用（如线程池）时旧值滞留于threadlocalmap中导致内存泄漏；jvm仅在线程销毁时清空map，而线程池线程几乎不销毁，故需在使用后显式remove()，不可依赖set(null)或withinitial()。
ThreadLocal.remove() 为什么必须手动调用
ThreadLocal 不会自动清理，线程复用（比如线程池）时，旧值会一直留在 ThreadLocalMap 中，导致内存泄漏。JVM 只在 Thread 销毁时才清空整个 ThreadLocalMap，但线程池里的线程几乎永不销毁。
常见错误现象：OutOfMemoryError: GC overhead limit exceeded，尤其在长期运行的 Web 应用中，ThreadLocal 存了大对象（如 SimpleDateFormat、上下文 Map、数据库连接信息）后又不 remove()，就会越积越多。
- 必须在「使用完 ThreadLocal 的最后位置」显式调用
remove()，不能依赖set(null)或set(…)覆盖 - 在
try-finally块里做清理最稳妥，哪怕中间抛异常也能兜住 - 如果用在过滤器、拦截器、AOP 切面中，确保
finally在响应返回前执行，而不是在方法退出时 —— 否则异步逻辑可能读到残留值
线程池场景下 ThreadLocal 清理的最佳时机
线程池复用线程是内存泄漏高发地。不是“任务结束就安全”，而是“下次任务开始前必须确认干净”。Spring 的 RequestContextHolder 就是典型反例：它内部用 ThreadLocal 存请求上下文，但若你手动起线程或用了异步（@Async），没主动重置，子线程就会继承父线程的脏上下文。
- 不要等线程退出再清理 —— 线程根本不会退出
- 在任务入口（如
Runnable.run()开头）先remove()所有已知业务ThreadLocal，再set()新值；或者封装成模板方法 - 避免在
ThreadLocal中存可变对象（如HashMap），否则即使remove()了，外部仍可能通过引用修改状态，造成跨任务污染 - 注意
ForkJoinPool的特殊性：它用工作窃取，线程可能执行多个任务，且inheritableThreadLocals默认不继承，需额外处理
为什么 ThreadLocal.withInitial() 不能替代 remove()
withInitial() 只控制「首次 get() 时初始化什么值」，不影响已有值的生命周期。它生成的 Supplier 每次只调用一次，后续 get() 都直接返回缓存值 —— 所以该缓存值只要没被 remove()，就一直存在。
立即学习“Java免费学习笔记（深入）”；
常见误用：static final ThreadLocal<map object>> ctx = ThreadLocal.withInitial(HashMap::new);</map>，以为每次 get 都新建 map，实际是每个线程只建一次，之后永远复用那个 map。
-
withInitial()和new ThreadLocal() { … }在清理逻辑上完全等价，都不自动清理 - 如果初始值是轻量对象（如空
ArrayList），漏掉remove()影响小；但如果是带缓存、连接、IO 资源的对象，就必须清理 - 别用
set(null)代替remove()——null是合法值，ThreadLocalMap仍会保留该 entry，只是 value 为 null，key（弱引用）回收后变成 stale entry，得靠后续get()/set()触发探测式清理，不可靠
如何检测 ThreadLocal 泄漏（不靠猜）
靠日志或监控发现 OOM 再查太晚。真正有效的办法是在测试和预发阶段主动扫描 ThreadLocalMap 内容，尤其是线程池中的活跃线程。
- 用反射读取
Thread.currentThread().threadLocals（类型是ThreadLocalMap），遍历其table数组，检查 key 是否为 null（stale entry）或 value 是否为预期类型 - 在单元测试 tearDown 或 Spring @AfterEach 里，对测试用的线程池执行一次全量
remove()并断言 size == 0 - 生产环境可用 JVM TI 工具（如 Arthas）执行
ognl '@java.lang.Thread@currentThread().threadLocals.table'查看当前线程的 map 状态 - 重点盯住
SoftReference和WeakReference的行为差异：ThreadLocal 的 key 是弱引用，value 是强引用 —— 这就是泄漏根源：key 被回收后 value 还挂着，GC 不掉
复杂点在于：ThreadLocal 的清理不是原子操作，也不是线程安全的 —— 多个地方并发 remove() 没问题，但「先 get 再 remove」这种模式在高并发下可能因指令重排或可见性出错；最容易被忽略的是：自定义类加载器 + ThreadLocal 组合，会导致 ClassLoader 泄漏，比普通对象泄漏更难排查。
