为何为SecurityContext设置Authentication会引发竞态条件？

首先要明确：ThreadLocal的线程隔离只是基础，竞态条件的根源在于SecurityContext实例的可变性+线程复用/线程继承场景

1. 线程池复用导致的实例复用问题 #

Web容器（如Tomcat）或业务线程池会复用线程，若ThreadLocal中的SecurityContext未被正确清理，新请求会复用旧线程中残留的SecurityContext实例。如果直接调用SecurityContextHolder.getContext().setAuthentication(authentication)修改这个旧实例的状态，而不是创建新实例替换，可能出现：

• 前一个请求的异步操作还在执行，后一个请求已经修改了同一个SecurityContext的Authentication，导致异步操作拿到错误的身份信息
• 线程复用后，新请求的身份信息被旧请求的残留状态干扰

2. 可继承ThreadLocal的线程共享场景 #

当SecurityContextHolder使用MODE_INHERITABLETHREADLOCAL策略时，子线程会继承父线程的SecurityContext实例引用。此时如果父线程通过setAuthentication修改同一个实例的状态，子线程会实时看到这个修改，反之亦然。这种跨线程的实例共享修改，就会引发典型的竞态条件——多个线程同时修改同一个可变对象的属性。

3. 可变对象的线程安全风险 #

SecurityContext是一个可变对象，setAuthentication方法是修改其内部状态，而非替换整个实例。即便在纯ThreadLocal场景下，若存在同一线程内的并发操作（比如同一请求内的多个异步任务共享该线程的SecurityContext），直接修改实例状态也可能导致线程内的状态不一致（虽然这种场景少见，但Spring文档做了严谨的防御性建议）。

文档建议的本质 #

创建新的SecurityContext实例并通过SecurityContextHolder.setContext(newContext)替换，本质是用不可变的实例替换逻辑代替可变实例的修改逻辑：

• 线程复用场景下，新实例完全隔离了旧请求的状态
• 线程继承场景下，子线程继承的是新实例的引用，父线程后续的操作不会影响子线程的上下文
• 从根源上避免了可变对象带来的线程安全隐患

Spring Security文档原文（翻译）：我们从创建一个空的SecurityContext开始。你应该创建一个新的SecurityContext实例，而不是使用SecurityContextHolder.getContext().setAuthentication(authentication)，以避免跨多个线程的竞态条件。

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