threadlocal 配合线程池易引发内存泄漏，必须在 finally 中调用 remove() 清理，或通过工具类统一 clear()；静态声明 + 封装方法 + 线程池 afterexecute 兜底清理是关键措施。
线程池配合 ThreadLocal 时，内存泄漏不是偶然问题，而是设计上必然存在的风险——因为线程复用，而 ThreadLocal 的 value 是强引用，key 却是弱引用。一旦不主动清理，value 就会一直挂在 Thread 的 ThreadLocalMap 里，GC 清不掉。
必须显式调用 remove()，不能靠 set(null)
set(null) 只是把 value 设为 null，Entry 还在，key=null 的“脏项”照旧残留，无法触发 map 内部的探测清理机制。真正有效的是 remove()，它会真正删除 Entry，并顺带扫描并清理附近 key 为 null 的脏项。
- 每次业务逻辑结束前，在 finally 块中调用 remove()
- 即使只执行了 get() 没 set()，只要用过，也建议 clear，尤其在 Web 请求这类短生命周期场景
- 不要写成 if (xxx.get() != null) xxx.remove() —— get() 可能返回默认值或旧值，判断无意义
静态声明 + 封装工具方法，统一管理入口
ThreadLocal 应声明为 private static final，避免重复创建实例，也便于集中管控。同时提供 clear() 工具方法，把 remove() 封装起来，降低误用概率。
- 例如：public static void clear() { currentUser.remove(); }
- 所有业务代码统一调用 clear()，而不是直接操作 remove()
- 工具类命名清晰，比如 UserContext.clear()、TraceIdContext.clear()
在线程池层面兜底：重写 afterExecute()
仅靠任务内部 try-finally 不够可靠：任务可能被中断、抛出未捕获异常、甚至根本没执行到 finally。最稳妥的方式是在任务执行结束后由线程池统一清理。
- 继承 ThreadPoolExecutor，重写 afterExecute(Runnable r, Throwable t)
- 在该方法中对所有已知的 ThreadLocal 实例调用 clear()
- 注意：要确保这些 ThreadLocal 是可访问的（如定义在工具类里且有 public clear 方法）
哪些 ThreadLocal 特别危险，必须清理？
以下三类场景不清理就极易引发明显内存增长，甚至 OOM：
- 存放大对象：如 Map、List、JSON 字符串、完整用户上下文（含 token、权限树等）
- 绑定请求生命周期：在 Tomcat/Jetty 等容器中，一个请求对应一个线程，但线程被复用后旧上下文仍在
- 静态持有 + 长期运行：private static final ThreadLocal
日志缓冲区，若不清理，100 个线程就占 100 个缓冲区
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
