RefreshScope刷新@ConfigurationProperties配置bean后访问配置bean有概率读取到旧值

[JunkCoder17]

• 我已经检查过discussions
• 我已经搜索过issues
• 我已经仔细检查过FAQ

描述bug

使用RefreshScope刷新被@ConfigurationProperties注解的配置类
在调用RefreshScope.refreshAll()后访问被刷新的配置类，发现配置类的内容有一定概率为旧值

复现

修改配置时概率复现

期望

调用RefreshScope.refreshAll()后访问被刷新的配置类，应该获取到新的配置内容

截图
为了保证我的listener执行时相关的配置bean已经刷新，我参考ApolloConfigChangeListener实现了PostRefreshConfigChangeListener，所有PostRefreshConfigChangeListener在RefreshScope.refreshAll()执行完之后才会执行，ApolloConfigChangeListener负责执行RefreshScope.refreshAll()和触发listener，相关代码如下

@Component
@RequiredArgsConstructor
@Slf4j
public class ApolloAutoRefreshConfig implements BeanPostProcessor {
 
    public static final String APOLLO_NAMESPACES = "${apollo.bootstrap.namespaces}";
    private final RefreshScope refreshScope;
    private final Environment environment;
 
    private final List<PostRefreshConfigChangeListener> listeners;
    private static final String NAMESPACE_DELIMITER = ",";
    private static final Splitter NAMESPACE_SPLITTER = Splitter.on(NAMESPACE_DELIMITER)
        .omitEmptyStrings().trimResults();
 
    @ApolloConfigChangeListener(value = APOLLO_NAMESPACES)
    @Trace
    public void onChange(ConfigChangeEvent changeEvent) {
        refreshScope.refreshAll();
        log.info("Apollo config refreshed, namespace: {}, keys: {}", changeEvent.getNamespace(), changeEvent.changedKeys());
        for (PostRefreshConfigChangeListener listener : listeners) {
            if (listenerInterestedInEvent(listener, changeEvent)) {
                listener.onChange(changeEvent);
            }
        }
    }
 
    private boolean listenerInterestedInEvent(PostRefreshConfigChangeListener listener, ConfigChangeEvent changeEvent) {
        String namespace = changeEvent.getNamespace();
        Set<String> changedKeys = changeEvent.changedKeys();
        Set<String> interestedNamespaces = listener.getNamespaces();
        Set<String> interestedKeys = listener.getInterestedKeys();
        Set<String> interestedKeyPrefixes = listener.getInterestedKeyPrefixes();
        if (!interestedNamespaces.contains(namespace)) {
            return false;
        }
        if (CollectionUtils.isEmpty(interestedKeys) && CollectionUtils.isEmpty(interestedKeyPrefixes)) {
            return true;
        }
        if (interestedKeys != null) {
            for (String interestedKey : interestedKeys) {
                if (changedKeys.contains(interestedKey)) {
                    return true;
                }
            }
        }
        if (interestedKeyPrefixes != null) {
            for (String prefix : interestedKeyPrefixes) {
                for (String changedKey : changedKeys) {
                    if (changedKey.startsWith(prefix)) {
                        return true;
                    }
                }
            }
        }
        return false;
    }
 
    @Override
    public Object postProcessBeforeInitialization(Object bean, String beanName) throws BeansException {
        Class<?> clazz = bean.getClass();
 
        List<Method> methods = new ArrayList<>();
        ReflectionUtils.doWithMethods(clazz, methods::add);
 
        for (Method method : methods) {
            PostRefreshApolloConfigChangeListener annotation = AnnotationUtils
                .findAnnotation(method, PostRefreshApolloConfigChangeListener.class);
            if (annotation == null) {
                continue;
            }
            Class<?>[] parameterTypes = method.getParameterTypes();
            Preconditions.checkArgument(parameterTypes.length == 1,
                "Invalid number of parameters: %s for method: %s, should be 1", parameterTypes.length,
                method);
            Preconditions.checkArgument(ConfigChangeEvent.class.isAssignableFrom(parameterTypes[0]),
                "Invalid parameter type: %s for method: %s, should be ConfigChangeEvent", parameterTypes[0],
                method);
 
            ReflectionUtils.makeAccessible(method);
            String[] namespaces = annotation.value();
            String[] annotatedInterestedKeys = annotation.interestedKeys();
            String[] annotatedInterestedKeyPrefixes = annotation.interestedKeyPrefixes();
 
            Set<String> resolvedNamespaces = new HashSet<>();
            for (String namespace : namespaces) {
                String resolvedNamespace = environment.resolveRequiredPlaceholders(namespace);
                if (resolvedNamespace.contains(NAMESPACE_DELIMITER)) {
                    resolvedNamespaces.addAll(NAMESPACE_SPLITTER.splitToList(resolvedNamespace));
                } else {
                    resolvedNamespaces.add(resolvedNamespace);
                }
            }
 
            Set<String> interestedKeys =
                annotatedInterestedKeys.length > 0 ? Sets.newHashSet(annotatedInterestedKeys) : null;
            Set<String> interestedKeyPrefixes =
                annotatedInterestedKeyPrefixes.length > 0 ? Sets.newHashSet(annotatedInterestedKeyPrefixes)
                    : null;
            PostRefreshConfigChangeListener listener = new PostRefreshConfigChangeListener(bean, method, resolvedNamespaces, interestedKeys, interestedKeyPrefixes);
            listeners.add(listener);
            log.info("add custom listener {}", beanName);
        }
        return bean;
    }
 
    @RequiredArgsConstructor
    @Getter
    public static class PostRefreshConfigChangeListener implements ConfigChangeListener {
        private final Object bean;
        private final Method method;
        private final Set<String> namespaces;
        private final Set<String> interestedKeys;
        private final Set<String> interestedKeyPrefixes;
 
        @Override
        public void onChange(ConfigChangeEvent configChangeEvent) {
            ReflectionUtils.invokeMethod(method, bean, configChangeEvent);
        }
    }
}

@RefreshScope
@Component
@ConfigurationProperties("props")
@Getter
@Setter
public class MyProps {
    private List<Pair> pairs;
 
    @Getter
    @Setter
    public static class Pair {
        private String k;
        private String v;
    }
}

@Component
@RequiredArgsConstructor
@Slf4j
public class MyListener {
 
    private final MyProps myProps;
    private Map<String, String> map;
 
    @PostRefreshApolloConfigChangeListener(value = "${apollo.bootstrap.namespaces}", interestedKeyPrefixes = {"props"})
    public void onChange(ConfigChangeEvent changeEvent) {
        this.map = myProps.getPairs().stream().collect(Collectors.toMap(Pair::getK, Pair::getV));
        log.info("Loaded Map: {}", this.map.keySet());
    }
}

配置变更
发布前配置

props:
  pairs:
    - k: k1
      v: v1

发布后配置

props:
  pairs:
    - k: k1
      v: v1
    - k: k2
      v: v2

出现问题时的输出日志，可以看到ConfigChangeEvent中有k2的条目，但访问配置bean时只加载到了k1

INFO [Apollo-Config-2] [TID: N/A] c.t.n.e.r.c.ApolloAutoRefreshConfig: Apollo config refreshed, namespace: application.yaml, keys: [props.pairs[1].v, props.pairs[1].k]
INFO [Apollo-Config-2] [TID: N/A] c.t.n.e.t.MyListener: Loaded Map: [k1]

额外的细节和日志

• 版本：Apollo客户端 2.2.0，Apollo服务端 2.0.1，SpringBoot 3.5.7，SpringCloud 4.3.0，JDK 21.0.7
• 错误日志
• 配置：
• 平台和操作系统

[github-actions]

🤖

感谢详细的问题报告。您提供的版本信息、代码示例和日志已经非常完整。

根据描述，这是一个与 RefreshScope 和 @ConfigurationProperties 配合使用时的并发刷新问题。从日志看，ConfigChangeEvent 正确包含了新增的配置项，但在 listener 中访问配置 bean 时仍读到旧值，说明可能存在时序问题。

已添加 bug、area/client、need investigation 标签，维护者会进一步分析这个刷新时机的问题。

AI generated by Apollo Issue Triage

[nobodyiam]

暂未复现。基于你提供的 Spring Boot 3.5.7 / Spring Cloud 4.3.0 / JDK 21 组合，我用最小 Spring Cloud 用例验证了 @RefreshScope + @ConfigurationProperties 在 refreshScope.refreshAll() 后立即读取的行为，包括 @Bean 风格和你示例里的 @Component 风格；连续多次刷新后都能读到新值，所以目前还不能确认这是 Apollo client 侧的稳定复现问题。

当前能力与边界：

• 从 Apollo Java client 2.2.0 的实现看，DefaultConfig 会先更新本地配置并清理缓存，再触发 ConfigChangeEvent；AbstractConfig 中的 listener 派发是异步执行的。
• @ApolloConfigChangeListener 本身只是把方法注册成 Apollo ConfigChangeListener，不提供“Spring Cloud @ConfigurationProperties 已经完成重新绑定并且所有自定义 listener 都串行完成”的额外保证。
• RefreshScope.refreshAll() 的 Spring Cloud 语义是销毁 refresh scope 中当前实例，并在下一次方法访问时重新创建实例；它不是 Apollo client 提供的同步重绑定 API。
• Apollo 文档里也说明 @ConfigurationProperties 动态更新需要配合 EnvironmentChangeEvent 或 RefreshScope，可参考 docs/zh/client/java-sdk-user-guide.md 中 ConfigurationProperties使用方式 一节。

建议下一步提供一个最小可运行 demo，最好只保留：

1. application.yaml namespace 的配置；
2. MyProps、ApolloAutoRefreshConfig、MyListener；
3. 完整依赖版本和 Apollo 加载方式，例如 apollo.bootstrap.* / spring.config.import=apollo://...；
4. 可循环触发配置发布并观察旧值的脚本或步骤。

同时建议在 refreshAll() 后的自定义 listener 里打印几组对照数据：

• changeEvent 中 props.pairs[1].k / props.pairs[1].v 的 new value；
• ConfigService.getConfig("application.yaml") 直接读取同一 key 的结果；
• myProps.getClass()，确认注入的是 refresh scope proxy；
• myProps.getPairs() 在立即读取和延迟几十毫秒读取时的结果。

如果 ConfigService 已经是新值但 myProps 仍然偶发旧值，排查重点会更偏向 Spring Cloud RefreshScope/绑定或并发读取链路；如果 ConfigService 同时也是旧值，再继续看 Apollo YAML namespace/property source 更新链路。在有稳定 demo 后，可以把回归用例补到 apollo-java 的 Spring Boot compatibility tests 中。

[JunkCoder17]

我这边发现，如果发布的application.yaml文件较大的话，会更容易复现

1. 请问Apollo配置变更的内容同步到 spring Environment中的时机是什么时候？
2. 同步到Environment和@ApolloConfigChangeListener触发的先后顺序是否是固定的？
3. 是否有可能调用 RefreshScope.refreshAll() 时，Environment中的值仍为旧值导致重建myProps时使用的也为旧值？

[nobodyiam]

暂未复现新的稳定用例，但这几个时序点可以先明确一下：从 Apollo Java client 2.2.0 的代码看，Spring Environment 里的 Apollo 配置不是每次变更时单独复制/写入一份，而是启动时注册 ConfigPropertySource，后续 Environment#getProperty(...) 会透过这个 PropertySource 读取底层 Apollo Config。

逐条回答：

1. Apollo 配置进入 Spring Environment 的注册发生在应用启动阶段，主要是 PropertySourcesProcessor#postProcessBeanFactory -> initializePropertySources 把 ConfigPropertySource 挂到 Environment。配置变更时，DefaultConfig 会先更新本地 m_configProperties 并清理缓存，然后才触发 ConfigChangeEvent；ConfigPropertySource#getProperty(...) 读取的是底层 Config#getProperty(...)。所以这里没有一个独立的“同步到 Environment 完成”的回调点。

2. 如果说的是“底层 Apollo Config 更新”和“@ApolloConfigChangeListener 触发”的顺序，代码路径上是先更新底层 Config，再 fireConfigChange。但如果说的是 Apollo 内部发布 ApolloConfigChangeEvent 的 listener 和用户自定义 @ApolloConfigChangeListener 的执行完成顺序，这个不能依赖固定顺序。两者最终都是 ConfigChangeListener，AbstractConfig#fireConfigChange 会对匹配 listener 调用 notifyAsync，通过 cached thread pool 异步执行；注册顺序不能作为串行完成保证。

3. 因此，在同一个 Apollo 变更事件已经触发到 listener 后，单纯因为 Apollo 还没有把新值放进 Environment 而导致 refreshScope.refreshAll() 重建时读旧值，不是当前代码路径上最符合的解释。更需要排查的是：RefreshScope 销毁/重建和业务读取是否并发、注入的 MyProps 是否确实是 refresh scope proxy、YAML namespace 转 properties 的链路是否已经完成、以及是否存在 Spring Binder/集合绑定或业务侧缓存/旧对象引用导致的旧值读取。

较大的 application.yaml 更容易复现这一点很有价值，它可能放大 YAML 解析、bean 重建或业务 listener 执行的时间窗口，但还不能直接证明 Environment 本身仍是旧值。

建议在同一个 onChange 里补几组对照日志：

• environment.getProperty("props.pairs[1].k")
• ConfigService.getConfig("application.yaml").getProperty("props.pairs[1].k", null)
• myProps.getClass()，确认注入的是 refresh scope proxy
• refreshAll() 前、刚返回后、延迟几十毫秒后分别打印 myProps.getPairs()

如果 Environment 和 ConfigService 都已经是新值，但 myProps 偶发旧值，排查重点应放在 Spring Cloud RefreshScope/bean 绑定或并发访问链路；如果 Environment 本身仍是旧值，才更像 Apollo ConfigPropertySource 或 YAML properties-compatible 更新链路的问题，可以基于最小 demo 补到 apollo-java 的 compatibility tests 里继续定位。