必须在handlerinterceptor.aftercompletion()中调用threadlocal.remove()，因其在响应写出、视图渲染完成后无条件执行，覆盖正常与异常路径；需用try-finally包裹并匹配/**路径，确保同线程内清理且避免子线程误用。

在 Spring MVC 中，必须在请求链路真正结束时调用 ThreadLocal.remove()，否则线程池复用会导致 value 强引用长期滞留，引发内存泄漏。

最稳妥的位置：HandlerInterceptor.afterCompletion()

这是 Web 场景下唯一能覆盖所有请求路径（包括异常流）的可靠时机：

• 它在视图渲染完成、响应已写出后触发，无论 controller 是否抛出异常都会执行
• 第三个参数 Exception ex 可区分正常返回或异常退出，但清理逻辑必须无条件执行
• 注册拦截器时需匹配 /**，避免漏掉静态资源、API 前缀外的路径
• 务必用 try-finally 包裹 remove 调用，防止 remove() 自身异常导致跳过清理

为什么不能用 postHandle() 或 finally 块？

postHandle() 发生在视图渲染前，后续仍可能抛出 RuntimeException（如视图解析失败、IO 异常），导致清理被跳过；而仅靠任务内部的 finally 不覆盖 Filter 中断、异步请求、Spring 异常处理器接管等边界场景。

Java Development Manual

Java开发手册规约集合，基于阿里巴巴Java开发手册（嵩山版）。 涵盖7大维度：编程规约、异常日志、单元测试、安全规约、MySQL数据库、工程结构、设计规约。 当用户需要：(1) 编写或审查Java代码 (2) 检查命名/代码规范 (3) 处理异常和日志 (4) 编写单元测试 (5) 安全编码 (6) 数据库设...

下载

• @PreDestroy 或普通方法退出不保证执行时机，也不适用于每次 HTTP 请求
• Filter 的 doFilter() 中写 finally 是可行方案，但需确保链完整且未被其他 Filter 提前终止
• 若项目已使用 WebMvcConfigurer 注册拦截器，应确认其生效范围覆盖全部请求路径

remove() 必须和 set() 在同一线程内完成

ThreadLocal 是线程绑定的，跨线程调用主线程定义的 remove() 完全无效——子线程操作的是自己的 ThreadLocalMap，主线程的 value 依然挂着。

• 异步场景（如 @Async、CompletableFuture.supplyAsync()）必须手动透传上下文，并在子线程中独立 set() 和 remove()
• 不要依赖 InheritableThreadLocal，它只是让子线程“继承”了泄漏风险，仍需各自清理
• 每个自定义 ThreadLocal 实例都应单独调用 remove()，嵌套使用的工具类也需各自负责清理

推荐封装方式：自动清理资源类

直接裸用 set() + remove() 容易遗漏。可封装为 AutoCloseable 类型，在业务代码中配合 try-with-resources 使用：

• 构造时调用 set()，close() 方法内调用 remove()
• JDK 7+ 支持自动调用 close()，无需人工写 finally
• 对老版本 JDK 或非标准生命周期，退回到显式 try-finally 调用 scope.close()
• 静态 ThreadLocal 实例建议声明为 private static final，避免类卸载问题

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南