Spring Security与线程池复用引发竞态条件：RxJava微服务用户ID异常

这问题我之前帮好几个开发者排查过，核心就是Spring Security的上下文绑定机制和RxJava线程调度的冲突，正好踩中了线程复用带来的竞态条件坑。

问题根源 #

Spring Security默认把SecurityContext绑定在当前线程的ThreadLocal里，当你用RxJava的IO调度器切换到线程池中的线程时，新线程本身没有当前登录用户的上下文。而线程池会复用旧线程，如果之前的线程没有正确清除ThreadLocal里的SecurityContext，就会导致后续请求复用这个线程时，拿到的是上一个用户的上下文，直接就出现用户ID串号的情况了。

解决方案 #

下面给你几个从易到难的解决思路，按需选择：

1. 手动在RxJava流中传递并清理上下文

这是最直接的方式，在切换线程前捕获当前的SecurityContext，在执行业务逻辑时设置到当前线程，执行完务必清理，避免污染线程池：

// 先获取当前请求线程的安全上下文
SecurityContext currentContext = SecurityContextHolder.getContext();

yourDataObservable
    .subscribeOn(Schedulers.io())
    .map(data -> {
        // 设置上下文到当前IO线程
        SecurityContextHolder.setContext(currentContext);
        try {
            // 执行保存数据的逻辑，此时就能正确获取当前用户ID了
            return yourDataService.saveWithUserId(data);
        } finally {
            // 必须清理，否则线程复用会带旧上下文
            SecurityContextHolder.clearContext();
        }
    })
    .subscribe(result -> {
        // 处理结果
    }, error -> {
        // 处理异常
    });

2. 用RxJava的Context API优雅传递上下文

RxJava 2+提供了Context API，可以在整个数据流中携带上下文信息，不用手动在每个操作符里传递：

yourDataObservable
    // 把当前安全上下文写入数据流的Context
    .contextWrite(ctx -> ctx.put("SECURITY_CONTEXT", SecurityContextHolder.getContext()))
    .subscribeOn(Schedulers.io())
    .map((data, ctx) -> {
        // 从Context中取出安全上下文并设置
        SecurityContext context = ctx.get("SECURITY_CONTEXT");
        SecurityContextHolder.setContext(context);
        try {
            return yourDataService.saveWithUserId(data);
        } finally {
            SecurityContextHolder.clearContext();
        }
    })
    .subscribe(...);

3. 自定义调度器自动处理上下文传递

如果项目中大量使用RxJava的IO调度器，手动写上下文处理会很繁琐，这时候可以自定义一个包装调度器，自动帮你处理SecurityContext的传递和恢复：

public class SecurityAwareScheduler extends Scheduler {
    private final Scheduler delegate;

    public SecurityAwareScheduler(Scheduler delegate) {
        this.delegate = delegate;
    }

    @Override
    public Worker createWorker() {
        return new SecurityAwareWorker(delegate.createWorker());
    }

    private static class SecurityAwareWorker extends Worker {
        private final Worker delegate;

        SecurityAwareWorker(Worker delegate) {
            this.delegate = delegate;
        }

        @Override
        public Disposable schedule(@NonNull Runnable run) {
            // 捕获当前线程的安全上下文
            SecurityContext currentContext = SecurityContextHolder.getContext();
            // 包装任务，执行前设置上下文，执行后恢复原上下文
            return delegate.schedule(() -> {
                SecurityContext originalContext = SecurityContextHolder.getContext();
                try {
                    SecurityContextHolder.setContext(currentContext);
                    run.run();
                } finally {
                    // 恢复原上下文，避免影响后续任务
                    SecurityContextHolder.setContext(originalContext);
                }
            });
        }

        @Override
        public void dispose() {
            delegate.dispose();
        }

        @Override
        public boolean isDisposed() {
            return delegate.isDisposed();
        }
    }
}

使用的时候，把原来的Schedulers.io()替换成我们自定义的调度器：

Scheduler securityAwareIo = new SecurityAwareScheduler(Schedulers.io());

yourDataObservable
    .subscribeOn(securityAwareIo)
    .map(data -> yourDataService.saveWithUserId(data))
    .subscribe(...);

这样所有用这个调度器的RxJava流都会自动处理安全上下文，不用重复写代码。

关键注意事项 #

• 无论用哪种方式，一定要在finally块中清理或恢复上下文，这是避免线程污染的核心，千万不能省略。
• 如果你的项目中还有其他自定义线程池，也要做类似的上下文传递处理，原理是一样的。

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