RequestContextHolder更安全，因其封装了自动绑定与reset机制：在FrameworkServlet的doService()中自动清理，避免线程复用导致的数据残留；而裸用ThreadLocal需手动ensure remove()，否则易内存泄漏或信息错乱。
ThreadLocal 不能直接跨线程传递 HTTP 请求上下文，必须配合 Web 容器线程模型手动绑定和清理，否则会内存泄漏或信息错乱。
为什么 Spring 的 RequestContextHolder 比裸用 ThreadLocal 更安全
Web 容器（如 Tomcat）通常复用线程处理多个请求，ThreadLocal 变量不会自动清空。如果只在拦截器里 set() 不 remove()，后续请求可能读到上一个用户的残留数据。Spring 的 RequestContextHolder 在 FrameworkServlet 的 doService() 中做了自动 reset()，本质是封装了可靠的生命周期管理。
- 裸用
ThreadLocal需在Filter或Interceptor的afterCompletion()中显式调用remove() -
RequestContextHolder默认使用ThreadLocal存储，但提供了reset()入口，且 Spring Boot 自动注册了清理逻辑 - 若用异步（如
@Async、CompletableFuture），ThreadLocal值不会继承，需手动透传 ——RequestContextHolder也一样，得配合RequestScope或自定义TaskDecorator
手动实现用户信息 ThreadLocal 的关键三步
适用于轻量框架或需要完全控制上下文的场景。核心是「绑定→使用→清理」闭环，缺一不可。
- 声明静态
ThreadLocal：用withInitial()避免null判断，例如private static final ThreadLocal<userinfo> USER_HOLDER = ThreadLocal.withInitial(() -> null);</userinfo> - 在
Filter中绑定：从HttpServletRequest解析 token 或 session，调用USER_HOLDER.set(userInfo)；注意要在chain.doFilter()前执行 - 务必在
finally块中remove()：即使发生异常也要清理，否则线程复用时会泄露前序请求的数据
示例片段：
立即学习“Java免费学习笔记（深入）”；
public void doFilter(ServletRequest req, ServletResponse res, FilterChain chain) {
HttpServletRequest request = (HttpServletRequest) req;
UserInfo user = extractFromRequest(request);
USER_HOLDER.set(user);
try {
chain.doFilter(req, res);
} finally {
USER_HOLDER.remove(); // 关键！不能省略
}
}
ThreadLocal 在异步调用中失效的典型表现与修复
当 Controller 中启动新线程（如 new Thread(() -> service.doWork()).start()），子线程无法访问父线程的 ThreadLocal 值，get() 返回 null 或默认值，导致权限校验失败、日志埋点丢失用户 ID 等问题。
- 现象：
USER_HOLDER.get()在子线程中为null，即使主线程刚 set 过 - 修复方式一（推荐）：用
InheritableThreadLocal替换，但仅限父子线程继承，不支持线程池（因为线程池复用线程，不是“新建”） - 修复方式二（生产首选）：在线程池提交任务前，手动把当前
UserInfo传入闭包，例如executor.submit(() -> { UserInfo u = USER_HOLDER.get(); doWork(u); }) - 修复方式三（Spring 场景）：配置
ThreadPoolTaskExecutor的taskDecorator，在decorate()中复制ThreadLocal值
容易被忽略的内存泄漏点：static + ThreadLocal + classloader
如果 ThreadLocal 变量是 static 的（必须是），而它存的 UserInfo 引用了 Spring Bean 或 Web 上下文对象，又没及时 remove()，在热部署或容器重启时，该 ThreadLocal 会持有旧 classloader 的引用，触发内存泄漏。
- 验证方式：用
jmap -histo:live <pid></pid>查看ThreadLocalMap$Entry数量是否持续增长 - 根本解法：坚持每次请求结束都
remove()；避免在ThreadLocal中存大对象或含强引用的对象图 - 替代思路：优先用 Spring 的
@RequestScopeBean，由容器管理生命周期，比手写ThreadLocal更不易出错
