关键在于对齐ThreadLocal与Web应用生命周期，避免静态引用阻塞类加载器卸载；需在contextDestroyed()中反射清理线程池ThreadLocal，并在任务结束时显式remove，或选用RequestContextHolder等安全替代方案。
关键在于把 ThreadLocal 变量的生命周期和 Web 应用的生命周期对齐，而不是依赖线程本身的生命周期。Tomcat 线程池中的线程长期存活，若 ThreadLocal 值未及时清理，就会持续持有应用类加载器（WebappClassLoader）加载的对象，导致类加载器无法卸载、内存无法回收。
避免静态 ThreadLocal 引用
静态变量的生命周期与类绑定，而 Servlet 或工具类一旦被 WebappClassLoader 加载，其静态 ThreadLocal 就会一直存在，即使应用已停止。这直接阻断了类加载器的卸载路径。
- 不要在 Servlet、Filter 或 Listener 中声明 static final ThreadLocal
- 改用实例级 ThreadLocal，配合 Spring 的
@Scope("prototype")或手动管理作用域 - 若必须用静态 ThreadLocal（如全局上下文），确保它只存基础类型或 JDK 类对象，绝不持有任何 Web 应用类的实例
在应用卸载时主动清理所有线程的 ThreadLocal
Tomcat 在应用停止时会触发 ServletContextListener.contextDestroyed()，这是唯一可靠的统一清理入口。
- 在
contextDestroyed()中遍历当前 JVM 所有活跃线程（尤其是线程池线程） - 对每个线程调用
thread.getThreadLocals()（需反射访问私有字段threadLocals） - 遍历其
ThreadLocalMap，对每个 Entry 调用remove()或设 value = null；注意：需跳过 JDK 内部使用的 ThreadLocal（如InheritableThreadLocal或 Tomcat 自己用的） - 推荐使用 Apache Commons Lang 的
ThreadUtils辅助获取线程列表，或通过 JMX 获取线程池管理 Bean
任务执行后立即 remove，不依赖自动清理
ThreadLocalMap 的 expungeStaleEntry() 只在 get/set/remove 时被动触发，线程空闲时不会运行。在线程池场景下，一次任务结束后必须显式清理。
- 在 Filter 或拦截器中，
doFilter()结束前调用yourThreadLocal.remove() - 使用 Spring AOP，在 @AfterReturning 或 @AfterThrowing 中统一 remove
- 若用 CompletableFuture 或自定义 Runnable，包装为
RunnableWrapper，在run()最后强制 remove - 切忌只在 try 块中 set、在 finally 中 remove —— 若 set 后抛出异常且未被捕获，remove 可能不执行
选用替代方案降低风险
不是所有场景都必须用 ThreadLocal。高风险环境下可考虑更可控的替代方式：
- 将上下文数据作为方法参数逐层传递（适合调用链清晰的业务）
- 用 Spring 的
RequestContextHolder（基于 ThreadLocal 封装，但 Spring Boot 2.6+ 已内置销毁钩子） - 在异步任务中，用
MDC（Mapped Diagnostic Context）管理日志上下文，它本身支持 clearOnEnd - 对数据库连接或事务上下文，优先使用 Spring 的
TransactionSynchronizationManager，它会在请求结束时自动 reset
