java中threadlocal存用户信息需“进时存、出时清”，核心是拦截器aftercompletion中强制remove，防止线程复用导致上下文串扰；异步场景须手动透传快照或用taskdecorator。
Java 中用 ThreadLocal 存放用户信息并配合拦截器清理，核心是“进时存、出时清”，确保线程隔离且不泄漏。关键不在存，而在及时 remove —— Tomcat 等容器复用线程，不清理会导致后续请求拿到上一个用户的上下文。
定义线程安全的上下文持有类
用 static final ThreadLocal 封装用户对象，提供 set/get/remove 三要素：
- 推荐使用
ThreadLocal.withInitial(() -> null)初始化，避免 get 返回非预期默认值 - remove 必须是 public 方法，且业务中不依赖自动初始化逻辑
- 上下文对象（如 UserContext）建议设计为不可变或仅含只读字段，防止被误改
在拦截器 preHandle 中设置上下文
从请求中提取用户标识（如 JWT 解析、Header X-User-ID、Session），构建上下文并写入：
- 若解析失败（token 过期、缺失 header），可设为 null 或匿名上下文，业务层需兼容判空
- 不要在 preHandle 中抛异常中断流程后忘记清理 —— 此时 remove 还没执行，必须靠 afterCompletion 保障
- 避免在拦截器里做耗时操作（如远程查用户详情），影响请求首屏性能
在拦截器 afterCompletion 中强制清理
这是最不能省的一步，无论请求成功、404 还是抛出 RuntimeException，都必须调用 remove：
- afterCompletion 的第四个参数
Exception ex可用于日志记录异常，但清理动作不能受其影响 - 如果用了 Filter（如 OncePerRequestFilter），清理应放在 try-finally 的 finally 块中，更底层、更可靠
- 切勿只在正常流程里 remove —— 异常路径遗漏是内存泄漏和上下文串扰的主因
异步场景要额外透传
普通线程池（@Async / submit）中的子线程不继承父线程的 ThreadLocal，直接 get() 会返回 null：
- 可在提交任务前手动捕获当前上下文快照（如 UserContext snapshot = UserContextHolder.get()）
- 用 Runnable 包装，在执行前 set，执行后 remove —— 推荐通过 TaskDecorator 实现，统一注入
- InheritableThreadLocal 仅支持父子线程直传，不适用于线程池，慎用
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
