SecurityContextHolder是否线程安全？Spring Security过滤器并发认证问题

嘿，这两个问题问到了Spring Security里关于SecurityContextHolder的核心细节，我来给你逐一梳理清楚：

答案是默认情况下完全线程安全，这也是Spring Security设计它的核心考量之一。

SecurityContextHolder默认采用MODE_THREADLOCAL策略，简单来说就是每个线程都会持有自己独立的SecurityContext副本——线程A的上下文和线程B的完全隔离，互相不会干扰。你在一个线程里修改自己的SecurityContext内容，完全不会影响其他线程的上下文状态。

当然它也支持其他模式：

• MODE_INHERITABLETHREADLOCAL：允许子线程继承父线程的SecurityContext，适合异步任务场景
• MODE_GLOBAL：全局共享同一个SecurityContext实例，这种模式不是线程安全的，几乎不会在生产环境中使用

绝大多数业务场景下，我们用的都是默认的THREADLOCAL模式，放心用就好。

默认情况下不会影响其他并发请求，核心原因和上面的线程安全机制直接相关：

在标准的Servlet容器（比如Tomcat）中，每个用户的并发请求都会被分配一个独立的线程来处理，而默认的MODE_THREADLOCAL策略让每个线程拥有专属的SecurityContext实例。你在某个请求的过滤器里执行SecurityContextHolder.getContext().setAuthentication(null)，只是把当前处理这个请求的线程的Authentication置为null，其他99个请求各自在自己的线程里运行，它们的SecurityContext还是保持原来的认证状态，完全不受这个操作的影响。

只有当你特意配置了MODE_GLOBAL这种全局共享上下文的模式时，这个操作才会让所有请求的Authentication都变成null，但这种模式因为存在严重的线程安全问题，几乎不会被使用。

额外提一句：如果你的应用使用了线程池，一定要记得在任务执行完成后调用SecurityContextHolder.clearContext()清理上下文，避免出现上下文泄露导致后续线程复用旧的认证信息，但这和你当前问的这个操作的直接影响是两码事。

内容的提问来源于stack exchange，提问作者ArslanAnjum