Spring WebFlux中使用AtomicReference是否存在竞态条件及优化方案

原写法是否存在竞态条件？ #

不存在跨请求的竞态条件。原因如下：

• 你声明的AtomicReference<String> tenantId是方法局部变量，每个getData方法的调用（对应单个请求）都会创建一个全新的实例，不会被其他请求或线程共享。
• Reactor的操作符执行顺序严格遵循响应式链：flatMap里的tenantId.set()只会在resourceMapperService.getResource(id)成功完成后执行，而doFinally则会在整个Mono链完成（成功或失败）后触发，只要flatMap执行过，tenantId就一定已经被赋值，不会出现doFinally先于tenantId.set()执行的情况。

不过这种写法存在两个小问题：

1. 如果resourceMapperService.getResource(id)调用失败，flatMap不会执行，tenantId会保持null，此时doFinally里的日志会拿到null值。
2. 用AtomicReference存储状态不符合响应式编程的无状态设计原则，写法不够优雅。

最佳处理方式：使用Reactor Context传递tenantId #

Reactor提供了Context机制来在响应式链中传递上下文数据，这是处理这类场景的标准方案，既符合响应式编程范式，又能安全传递状态。

优化后的代码示例：

@Override
public Mono<String> getData(String id) {
    return resourceMapperService.getResource(id)
            // 获取tenantId并写入Context
            .flatMap(resource -> {
                String tenantId = resource.getTenantId();
                return uriConfigurationMono.flatMap(uriConfiguration -> 
                        getSearchData(resource.getServerId(), uriConfiguration.getDataProxyUri(), id))
                        .contextWrite(Context.of("tenantId", tenantId));
            })
            // 从Context中读取tenantId完成日志记录
            .doFinally(signal -> {
                ContextView context = signal.getContextView();
                String tenantId = context.getOrDefault("tenantId", null);
                telemetryService.addLogging(tenantId, id);
            });
}

方案优势： #

• 完全遵循响应式无状态设计，避免了局部状态变量的使用。
• 上下文数据和响应式链绑定，不会出现跨请求的状态污染。
• 可以清晰处理getResource(id)失败的场景：此时Context中不会有tenantId，通过getOrDefault可以优雅处理null值。

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