面经策

SecurityContext 和 SecurityContextHolder 是什么？为什么默认用 ThreadLocal 策略？异步和子线程中怎么传递？ ​

  • 标签：Spring Security、认证授权、后端

🏛 业务架构师 ​

SecurityContext 是"当前认证信息的容器"（持有 Authentication：身份+权限）；SecurityContextHolder 是访问它的静态门面——默认策略是 MODE_THREADLOCAL：每个线程一份，线程内任何层都能静态获取当前用户，无需层层传参。

为什么默认 ThreadLocal：Web 请求的处理天然"一线程一请求"——ThreadLocal 让认证信息随请求隔离（防串号）、随调用栈隐式传递（Controller/Service 随处可用），这是性能与便利的甜点。

异步与子线程的传递（重点坑）：

  1. @Async / 自建线程池：新线程不复制 ThreadLocal → 当前用户"消失"（get 返回 null → 业务代码 NPE 或越权判断失效）。对策：配置 SecurityContextHolder.setStrategyName(MODE_INHERITABLETHREADLOCAL)（有线程池复用污染风险，慎用）；正解是上下文传递装饰器——主线程先 DelegatingSecurityContextRunnable 包装任务，或 Spring Security 的 DelegatingSecurityContextAsyncTaskExecutor 包装线程池（提交时快照、执行时恢复、结束清理）；
  2. @Transactional 内开线程同理；
  3. 虚拟线程时代的新注意（2026 相关）：JDK 21 虚拟线程每个任务一线程，ThreadLocal 的"线程复用污染"问题消失，但"百万线程×ThreadLocal 副本"的内存成本上升——Spring Security 6.x 已提供 SecurityContext 与虚拟线程兼容的方案，新项目建议评估 ScopedValue 语义的未来迁移。

业务教训：异步丢上下文是生产高频事故（"定时任务里获取当前用户为 null"）——上线前必须测试异步链路的权限行为，别等审计时才发现某些异步操作绕过了用户上下文。

🏗 系统架构师 ​

SecurityContext = 当前认证信息的容器（装 Authentication：主体、权限、凭据）；SecurityContextHolder = 访问它的静态入口——默认策略 MODE_THREADLOCAL（绑定当前线程）。

为什么默认 ThreadLocal：Web 请求的处理天然"一线程一请求"——ThreadLocal 让任意深度的业务代码零参数传递地拿到身份（SecurityContextHolder.getContext().getAuthentication()），避免把用户信息层层透传污染所有方法签名；同时线程间隔离防止串号。代价是"与线程生命周期绑定"——换线程就丢，这正是异步场景问题的根源。

异步/子线程的传递方案：

  • 同容器内线程池：DelegatingSecurityContextExecutor（包装 executor，任务提交时快照上下文、执行时恢复）+ DelegatingSecurityContextRunnable——手工包装的通用方案；
  • @Async 方法：配置 SecurityContextHolder strategy 或在异步方法前显式传递；Spring 的 syncSecurityContext 机制；
  • 反应式/协程式：非阻塞模型没有"当前线程"——Spring Security 提供 ReactiveSecurityContext（基于 Reactor Context 随数据流传递），WebFlux 必须用它；
  • 虚拟线程（JDK 21）：每请求一虚拟线程，ThreadLocal 模型仍成立但注意海量线程的内存语义——ScopedValue 是官方指出的演进方向（不可变、生命周期有界）；
  • 跨进程：上下文不跨服务传——微服务间用令牌传递（JWT 原样转发或内部 token 换发），下游服务独立验签重建自己的 SecurityContext。

架构纪律：SecurityContext 只在请求生命周期内有效，业务需要的身份信息在请求入口显式取出传入领域层（防止框架依赖渗透到 domain，也规避异步丢失）——上下文是 Web 层机制，不是全局变量。

💻 全栈开发专家 ​

SecurityContext：当前认证信息的容器（持有 Authentication：principal、credentials、authorities、状态）。 SecurityContextHolder：访问 SecurityContext 的静态门面——框架把「当前用户是谁」放在这里，任何层都能 SecurityContextHolder.getContext().getAuthentication() 拿到。

为什么默认 ThreadLocal 策略：Servlet 是「一线程一请求」模型，ThreadLocal 让认证信息在同一线程的过滤器、Controller、Service 间免传参透传，且天然请求隔离——成本低、用法直白。（可选 MODE_GLOBAL/INHERITABLETHREADLOCAL，基本不用。）

异步/子线程的传递（这是必考的工程点）：

  • ThreadLocal 不跨线程——@Async、CompletableFuture、自建线程池里 getContext() 拿到 null 或别人的（池化复用导致脏数据，比 null 更危险）。

正确姿势：

java
// 1. Spring 生态最省事：委派 SecurityContext 到任务（底层用 context propagation）
@Async
public void audit() { ... }  // 配合 spring.security.context-propagation 自动透传（Boot 3.2+）

// 2. 显式快照模式
var ctx = SecurityContextHolder.getContext();
executor.submit(() -> {
    SecurityContextHolder.setContext(ctx);       // 进任务先装上下文
    try { business(); }
    finally { SecurityContextHolder.clearContext(); }  // 用完必清（池化线程防串号）
});

// 3. 方法级安全在异步里失效的坑：@PreAuthorize 基于 AOP 代理，
//    手动 new 线程里调用代理方法仍可工作，但调用同类内部方法（this.xxx）不走代理——经典失效场景

相关机制：请求结束时 SecurityContextPersistenceFilter（session 场景）/SecurityContextHolderFilter（6.x，显式 SecurityContextRepository）负责装入/清理；反应式栈（WebFlux）换 ReactiveSecurityContextHolder（基于 Reactor Context）。血泪教训：所有手写线程池代码 review 必查「有没有 setContext/clearContext 成对出现」——漏 clear 的串号是线上最难查的安全 bug 之一。