从RefreshScope实现原理看刷新配置失效问题

前言

在SpringIOC中，我们熟知的BeanScope有单例（singleton）、原型（prototype）， Bean的Scope影响了Bean的创建方式，例如创建Scope=singleton的Bean时，IOC会保存实例在一个Map中，保证这个Bean在一个IOC上下文有且仅有一个实例。SpringCloud新增了一个refresh范围的scope，同样用了一种独特的方式改变了Bean的创建方式，使得其可以通过外部化配置（.properties）的刷新，在应用不需要重启的情况下热加载新的外部化配置的值。

那么这个scope是如何做到热加载的呢？RefreshScope主要做了以下动作：

• 单独管理Bean生命周期
  • 创建Bean的时候如果是RefreshScope就缓存在一个专门管理的ScopeMap中，这样就可以管理Scope是Refresh的Bean的生命周期了
• 重新创建Bean
  • 外部化配置刷新之后，会触发一个动作，这个动作将上面的ScopeMap中的Bean清空，这样，这些Bean就会重新被IOC容器创建一次，使用最新的外部化配置的值注入类中，达到热加载新值的效果

下面我们深入源码，来验证我们上述的讲法。

1. 管理RefreshBean的生命周期

首先，若想要一个Bean可以自动热加载配置值，这个Bean要被打上@RefreshScope注解，那么就看看这个注解做了什么：

@Target({ ElementType.TYPE, ElementType.METHOD })
@Retention(RetentionPolicy.RUNTIME)
@Scope("refresh")
@Documented
public @interface RefreshScope {

	/**
	 * @see Scope#proxyMode()
	 * @return proxy mode
	 */
	ScopedProxyMode proxyMode() default ScopedProxyMode.TARGET_CLASS;

}

可以发现RefreshScope有一个属性 proxyMode=ScopedProxyMode.TARGET_CLASS，这个是AOP动态代理用，之后会再来提这个

可以看出其是一个复合注解，被标注了 @Scope("refresh") ，其将Bean的Scope变为refresh这个类型，在SpringBoot中BootStrap类上打上@SpringBootApplication注解（里面是一个@ComponentScan），就会扫描包中的注解驱动Bean，扫描到打上RefreshScope注解的Bean的时候，就会将其的BeanDefinition的scope变为refresh，这有什么用呢？

创建一个Bean的时候，会去BeanFactory的doGetBean方法创建Bean，不同scope有不同的创建方式：

protected  T doGetBean(final String name, @Nullable final Class requiredType,
                          @Nullable final Object[] args, boolean typeCheckOnly) throws BeansException {

  //....

  // Create bean instance.
  // 单例Bean的创建
  if (mbd.isSingleton()) {
    sharedInstance = getSingleton(beanName, () -> {
      try {
        return createBean(beanName, mbd, args);
      }
      //...
    });
    bean = getObjectForBeanInstance(sharedInstance, name, beanName, mbd);
  }

  // 原型Bean的创建
  else if (mbd.isPrototype()) {
    // It's a prototype -> create a new instance.
		// ...
    try {
      prototypeInstance = createBean(beanName, mbd, args);
    }
    //...
    bean = getObjectForBeanInstance(prototypeInstance, name, beanName, mbd);
  }

  else {
    // 由上面的RefreshScope注解可以知道，这里scopeName=refresh
    String scopeName = mbd.getScope();
    // 获取Refresh的Scope对象
    final Scope scope = this.scopes.get(scopeName);
    if (scope == null) {
      throw new IllegalStateException("No Scope registered for scope name '" + scopeName + "'");
    }
    try {
      // 让Scope对象去管理Bean
      Object scopedInstance = scope.get(beanName, () -> {
        beforePrototypeCreation(beanName);
        try {
          return createBean(beanName, mbd, args);
        }
        finally {
          afterPrototypeCreation(beanName);
        }
      });
      bean = getObjectForBeanInstance(scopedInstance, name, beanName, mbd);
    }
    //...
  }
}
//...
}

//...
}

这里可以看到几件事情：

• 单例和原型scope的Bean是硬编码单独处理的
• 除了单例和原型Bean，其他Scope是由Scope对象处理的
• 具体创建Bean的过程都是由IOC做的，只不过Bean的获取是通过Scope对象

这里scope.get获取的Scope对象为RefreshScope，可以看到，创建Bean还是由IOC来做（createBean方法），但是获取Bean，都由RefreshScope对象的get方法去获取，其get方法在父类GenericScope中实现：

public Object get(String name, ObjectFactory objectFactory) {
  // 将Bean缓存下来
  BeanLifecycleWrapper value = this.cache.put(name,
                                              new BeanLifecycleWrapper(name, objectFactory));
  this.locks.putIfAbsent(name, new ReentrantReadWriteLock());
  try {
    // 创建Bean，只会创建一次，后面直接返回创建好的Bean
    return value.getBean();
  }
  catch (RuntimeException e) {
    this.errors.put(name, e);
    throw e;
  }
}

首先这里将Bean包装起来缓存下来

private final ScopeCache cache;
// 这里进入上面的 BeanLifecycleWrapper value = this.cache.put(name, new BeanLifecycleWrapper(name, objectFactory));
public BeanLifecycleWrapper put(String name, BeanLifecycleWrapper value) {
  return (BeanLifecycleWrapper) this.cache.put(name, value);
}

这里的ScopeCache对象其实就是一个HashMap：

public class StandardScopeCache implements ScopeCache {

  private final ConcurrentMap cache = new ConcurrentHashMap();

  //...

  public Object get(String name) {
    return this.cache.get(name);
  }

  // 如果不存在，才会put进去
  public Object put(String name, Object value) {
    // result若不等于null，表示缓存存在了，不会进行put操作
    Object result = this.cache.putIfAbsent(name, value);
    if (result != null) {
      // 直接返回旧对象
      return result;
    }
    // put成功，返回新对象
    return value;
  }
}

• 1

这里就是将Bean包装成一个对象，缓存在一个Map中，下次如果再GetBean，还是那个旧的BeanWrapper。回到Scope的get方法，接下来就是调用BeanWrapper的getBean方法：

// 实际Bean对象，缓存下来了
private Object bean;

public Object getBean() {
  if (this.bean == null) {
    synchronized (this.name) {
      if (this.bean == null) {
        this.bean = this.objectFactory.getObject();
      }
    }
  }
  return this.bean;
}

可以看出来，BeanWrapper中的bean变量即为实际Bean，如果第一次get肯定为空，就会调用BeanFactory的createBean方法创建Bean，创建出来之后就会一直保存下来。

由此可见，RefreshScope管理了Scope=Refresh的Bean的生命周期。

2. 重新创建RefreshBean

当配置中心刷新配置之后，有两种方式可以动态刷新Bean的配置变量值，（SpringCloud-Bus还是Nacos差不多都是这么实现的）：

• 向上下文发布一个RefreshEvent事件
• Http访问/refresh这个EndPoint

不管是什么方式，最终都会调用ContextRefresher这个类的refresh方法，那么我们由此为入口来分析一下，热加载配置的原理：

我们一般是使用@Value、@ConfigurationProperties去获取配置变量值，其底层在IOC中则是通过上下文的Environment对象去获取property值，然后依赖注入利用反射Set到Bean对象中去的。

那么如果我们更新Environment里的Property值，然后重新创建一次RefreshBean，再进行一次上述的依赖注入，是不是就能完成配置热加载了呢？@Value的变量值就可以加载为最新的了。

这里说的刷新Environment对象并重新依赖注入则为上述两个方法做的事情：

• Set keys = refreshEnvironment();
• this.scope.refreshAll();

2.1 刷新Environment对象

下面简单介绍一下如何刷新Environment里的Property值

public synchronized Set refreshEnvironment() {
  // 获取刷新配置前的配置信息，对比用
  Map before = extract(
    this.context.getEnvironment().getPropertySources());
  // 刷新Environment
  addConfigFilesToEnvironment();
  // 这里上下文的Environment已经是新的值了
  // 进行新旧对比，结果返回有变化的值
  Set keys = changes(before,
                          extract(this.context.getEnvironment().getPropertySources())).keySet();
  this.context.publishEvent(new EnvironmentChangeEvent(this.context, keys));
  return keys;
}

我们的重点在addConfigFilesToEnvironment方法，刷新Environment：

ConfigurableApplicationContext addConfigFilesToEnvironment() {
  ConfigurableApplicationContext capture = null;
  try {
    // 从上下文拿出Environment对象，copy一份
    StandardEnvironment environment = copyEnvironment(
      this.context.getEnvironment());
    // SpringBoot启动类builder，准备新做一个Spring上下文启动
    SpringApplicationBuilder builder = new SpringApplicationBuilder(Empty.class)
      // banner和web都关闭，因为只是想单纯利用新的Spring上下文构造一个新的Environment
      .bannerMode(Mode.OFF).web(WebApplicationType.NONE)
      // 传入我们刚刚copy的Environment实例
      .environment(environment);
    // 启动上下文
    capture = builder.run();
    // 这个时候，通过上下文SpringIOC的启动，刚刚Environment对象就变成带有最新配置值的Environment了
    // 获取旧的外部化配置列表
    MutablePropertySources target = this.context.getEnvironment()
      .getPropertySources();
    String targetName = null;
    // 遍历这个最新的Environment外部化配置列表
    for (PropertySource source : environment.getPropertySources()) {
      String name = source.getName();
      if (target.contains(name)) {
        targetName = name;
      }
      // 某些配置源不做替换，读者自行查看源码
      // 一般的配置源都会进入if语句
      if (!this.standardSources.contains(name)) {
        if (target.contains(name)) {
          // 用新的配置替换旧的配置
          target.replace(name, source);
        }
        else {
          //....
        }
      }
    }
  }
  //....
}

可以看到，这里归根结底就是SpringBoot启动上下文那种方法，新做了一个Spring上下文，因为Spring启动后会对上下文中的Environment进行初始化，获取最新配置，所以这里利用Spring的启动，达到了获取最新的Environment对象的目的。然后去替换旧的上下文中的Environment对象中的配置值即可。

2.2 重新创建RefreshBean

经过上述刷新Environment对象的动作，此时上下文中的配置值已经是最新的了。思路回到ContextRefresher的refresh方法，接下来会调用Scope对象的refreshAll方法：

public void refreshAll() {
  // 销毁Bean
  super.destroy();
  this.context.publishEvent(new RefreshScopeRefreshedEvent());
}

public void destroy() {
  List errors = new ArrayList();
  // 缓存清空
  Collection wrappers = this.cache.clear();
  // ...
}

还记得上面的管理RefreshBean生命周期那一节关于缓存的讨论吗，cache变量是一个Map保存着RefreshBean实例，这里直接就将Map清空了。

思路回到BeanFactory的doGetBean的流程中，从IOC容器中获取RefreshBean是交给RefreshScope的get方法做的：

public Object getBean() {
  // 由于是新的BeanLifecycleWrapper实例，这里一定为null
  if (this.bean == null) {
    synchronized (this.name) {
      if (this.bean == null) {
        // 调用IOC容器的createBean，再创建一个Bean出来
        this.bean = this.objectFactory.getObject();
      }
    }
  }
  return this.bean;
}

可以看到，此时RefreshBean被IOC容器重新创建一个出来了，经过IOC的依赖注入功能，@Value的就是一个新的配置值了。到这里热加载功能实现基本结束。

根据以上分析，我们可以看出只要每次我们都从IOC容器中getBean，那么拿到的RefreshBean一定是带有最新配置值的Bean。

3. 动态刷新的应用

在我们正常使用@RefreshScope的时候，也没有做一些getBean的操作，为什么也可以动态刷新呢？因为Spring利用AOP动态代理了原先的Bean，在调用Bean的方法前，会拦截并从IOC容器中getBean，然后针对返回的新Bean做方法调用，这样就达到了使用的配置值一直是最新的效果了。下面我们来分析分析这AOP动态代理的过程。

3.1 动态代理RefreshBean

在本人另一篇文章， SpringBoot自动装配的魔法 中有讲到，SpringBoot的注解驱动注册Bean是由ConfigurationClassPostProcessor类来做的，其中@ComponentScan会扫描并注册包下带有@Componet注解的类为Bean，达到一个注解驱动注册Bean的效果。而扫描Bean并注册为BeanDefinition这一过程是由ClassPathBeanDefinitionScanner类的doScan方法去做的，我们先来看看扫描Bean的时候，对于RefreshScope的Bean有什么特殊处理：

protected Set doScan(String... basePackages) {
  Assert.notEmpty(basePackages, "At least one base package must be specified");
  Set beanDefinitions = new LinkedHashSet<>();
  // 扫描basePackages所在的包下的所有的类，带@Componet的类都会被注册为BeanDefinition
  for (String basePackage : basePackages) {
    	//...
      if (checkCandidate(beanName, candidate)) {
        BeanDefinitionHolder definitionHolder = new BeanDefinitionHolder(candidate, beanName);
        // 这里就是Scope的Bean的统一处理，是一个改变BeanDefinition的回调机会
        definitionHolder =
          AnnotationConfigUtils.applyScopedProxyMode(scopeMetadata, definitionHolder, this.registry);
        beanDefinitions.add(definitionHolder);
        // 注册BeanDefinition到IOC容器中
        registerBeanDefinition(definitionHolder, this.registry);
      }
    }
  }
  return beanDefinitions;
}

其中关键在于AnnotationConfigUtils的applyScopedProxyMode方法：

static BeanDefinitionHolder applyScopedProxyMode(
  ScopeMetadata metadata, BeanDefinitionHolder definition, BeanDefinitionRegistry registry) {
	// 获取Scope的代理模式
  ScopedProxyMode scopedProxyMode = metadata.getScopedProxyMode();
  // 如果代理模式为NO，就不进行代理了
  if (scopedProxyMode.equals(ScopedProxyMode.NO)) {
    return definition;
  }
  boolean proxyTargetClass = scopedProxyMode.equals(ScopedProxyMode.TARGET_CLASS);
  // 进行代理
  return ScopedProxyCreator.createScopedProxy(definition, registry, proxyTargetClass);
}

回顾开头分析的@RefreshScope注解，其proxyMode值为ScopedProxyMode.TARGET_CLASS

public @interface RefreshScope {

  /**
	 * @see Scope#proxyMode()
	 * @return proxy mode
	 */
  ScopedProxyMode proxyMode() default ScopedProxyMode.TARGET_CLASS;
}

所以这里被打上@RefreshScope的Bean类会进入接下来ScopedProxyCreator的createScopedProxy方法：

public static BeanDefinitionHolder createScopedProxy(
  BeanDefinitionHolder definitionHolder, BeanDefinitionRegistry registry, boolean proxyTargetClass) {

  return ScopedProxyUtils.createScopedProxy(definitionHolder, registry, proxyTargetClass);
}

public static BeanDefinitionHolder createScopedProxy(BeanDefinitionHolder definition,
                                                     BeanDefinitionRegistry registry, boolean proxyTargetClass) {

  // ...

  // Create a scoped proxy definition for the original bean name,
  // "hiding" the target bean in an internal target definition.
  // 重点，这里构造函数中将beanClass设置为了ScopedProxyFactoryBean.class
  RootBeanDefinition proxyDefinition = new RootBeanDefinition(ScopedProxyFactoryBean.class);
  // targetDefinition是被代理的原生Bean
  proxyDefinition.setDecoratedDefinition(new BeanDefinitionHolder(targetDefinition, targetBeanName));
  
  // ...

  // Return the scoped proxy definition as primary bean definition
  // (potentially an inner bean).
  return new BeanDefinitionHolder(proxyDefinition, originalBeanName, definition.getAliases());
}

这里一堆构建BeanDefinition的逻辑，先不看，只关注一件事，这里将BeanDefinition的beanClass设置为了ScopedProxyFactoryBean.class，而Scope的通用处理类GenericScope类是一个BeanDefinitionRegistryPostProcessor，其在postProcessBeanDefinitionRegistry回调方法中会针对刚刚那个beanClass为ScopedProxyFactoryBean.class的BeanDefinition做一个特殊的处理：

// GenericScope.class
public void postProcessBeanDefinitionRegistry(BeanDefinitionRegistry registry)
  throws BeansException {
  // 获取所有BeanDefinition的名称
  for (String name : registry.getBeanDefinitionNames()) {
    BeanDefinition definition = registry.getBeanDefinition(name);
    // 针对RootBeanDefinition这个BeanDefinition来做，这和上面的逻辑吻合
    if (definition instanceof RootBeanDefinition) {
      RootBeanDefinition root = (RootBeanDefinition) definition;
      // 判断BeanClass == ScopedProxyFactoryBean.class
      if (root.getDecoratedDefinition() != null && root.hasBeanClass()
          && root.getBeanClass() == ScopedProxyFactoryBean.class) {
        if (getName().equals(root.getDecoratedDefinition().getBeanDefinition()
                             .getScope())) {
          // 将BeanClass换为LockedScopedProxyFactoryBean
          root.setBeanClass(LockedScopedProxyFactoryBean.class);
          root.getConstructorArgumentValues().addGenericArgumentValue(this);
          // surprising that a scoped proxy bean definition is not already
          // marked as synthetic?
          root.setSynthetic(true);
        }
      }
    }
  }
}

到这里可以知道，GenericScope将ScopeBean，变为LockedScopedProxyFactoryBean这个类

然而这个类又是一个FactoryBean，由其父类ScopedProxyFactoryBean的getObject方法实现FactoryBean接口，我们知道，创建一个FactoryBean，其实最终会调用其getObject方法，这个方法的返回值才是最终被创建出来的Bean实例，所以我们的重点就在getObject方法中：

public Object getObject() {
  if (this.proxy == null) {
    throw new FactoryBeanNotInitializedException();
  }
  return this.proxy;
}

似乎早就被动态代理好了，全局搜索proxy变量在哪里被赋值。可以发现，ScopedProxyFactoryBean还是一个BeanFactoryAware，其setBeanFactory会在比较早的时机被回调：

public void setBeanFactory(BeanFactory beanFactory) {
  
  // ...
  
	// 这里是一个比较关键的点，scopedTargetSource变量是一个SimpleBeanTargetSource
  // scopedTargetSource中保存了IOC容器
  this.scopedTargetSource.setBeanFactory(beanFactory);

  // 创建动态代理前，将动态代理的信息都保存到ProxyFactory中
  ProxyFactory pf = new ProxyFactory();
  pf.copyFrom(this);
  // 注意，这里的TargetSource就是刚刚说的scopedTargetSource
  pf.setTargetSource(this.scopedTargetSource);
  
	// ...

  this.proxy = pf.getProxy(cbf.getBeanClassLoader());
}

这里先记住，scopedTargetSource是SimpleBeanTargetSource这个类就行，其保存了IOC容器。

接着调用pf的getProxy方法开始进行动态代理

下面就是AOP的一些逻辑了，不是本篇文章讨论的重点，一笔带过

private Callback[] getCallbacks(Class rootClass) throws Exception {

  // ...

  // Choose an "aop" interceptor (used for AOP calls).
  // 这里的MethodInterceptor实例是DynamicAdvisedInterceptor这个类
  Callback aopInterceptor = new DynamicAdvisedInterceptor(this.advised);

  // ...
  return callbacks;
}

我们知道，CGLib动态代理都会实现一个MethodInterceptor，被代理的类的每一个方法调用实质上都是在调用MethodInterceptor的intercept方法，那么我们看看DynamicAdvisedInterceptor这个类的intercept方法：

public Object intercept(Object proxy, Method method, Object[] args, MethodProxy methodProxy) throws Throwable {
  // 记得吗，刚刚我们反复强调的TargetSource
  TargetSource targetSource = this.advised.getTargetSource();
  try {
    // ...
    // Get as late as possible to minimize the time we "own" the target, in case it comes from a pool...
    // 重点，这里调用了targetSource的getTarget
    // target变量就是被代理的类，调用实际方法的时候反射调用其对应方法
    target = targetSource.getTarget();
   // ...
    if (chain.isEmpty() && Modifier.isPublic(method.getModifiers())) {
      // ...
      // target变量就是被代理的类，调用实际方法的时候反射调用其对应方法
      retVal = methodProxy.invoke(target, argsToUse);
    }
    else {
      // We need to create a method invocation...
      // target变量就是被代理的类，调用实际方法的时候反射调用其对应方法
      retVal = new CglibMethodInvocation(proxy, target, method, args, targetClass, chain, methodProxy).proceed();
    }
    // target变量就是被代理的类，调用实际方法的时候反射调用其对应方法
    retVal = processReturnType(proxy, target, method, retVal);
    return retVal;
  }
  // ...
}

直接看重点，targetSource的getTarget()方法的返回值是被代理的类，那么这个getTarget做了什么逻辑呢？回顾上面来看我们知道这里TargetSource的实现类是SimpleBeanTargetSource：

public class SimpleBeanTargetSource extends AbstractBeanFactoryBasedTargetSource {

  @Override
  public Object getTarget() throws Exception {
    // 从IOC中getBean
    return getBeanFactory().getBean(getTargetBeanName());
  }
}

到这里就已经揭晓了答案，原来被打上@RefreshScope的Bean都会被Spring做AOP动态代理，每次调用方法之前，都会去IOC中调用getBean方法获取真正的原始Bean，而原始Bean又被存放在GenericScope对象中的Map里，在refresh刷新配置的时候会清空缓存Map，在刷新配置的时候，调用类方法前去IOC获取Bean，然后到GenericScope查看缓存，发现没有这个Bean缓存就会重新从IOC容器创建一份Bean，依赖注入配置属性值的时候注入的就是最新的值了，这样就能达到动态刷新的作用。

3.2 Refresh动态刷新失效问题

大部分场景下RefreshBean动态刷新是不会失效的，但是笔者在使用WebFlux的时候，用到WebFilter过滤器时出现了失效的问题。这里从现象看本质，如果你的应用Refresh也失效了，大概率也是跟我差不多问题，知道了原理，解决这个问题会变得十分简单。

这里重点要看你的Bean是如何被加载使用的，这里看看常见的两个方式是如何使用的：

• Controller：在Controller中，@Value依赖注入一个外部化配置值，是否能得到动态刷新呢？
• @Autowired：依赖注入任意一个Bean，注入的Bean中有@Value一个外部化配置值，是否能得到动态刷新呢？

3.2.1 Controller的使用

@RestController
@RefreshScope
public class TestController {
  
  @Value("${test.refresh}")
  private boolean test;
  
  @GetMapping("/get/refresh/test/value")
  public boolean test() {
    return test;
  }

}

涉及一些SpringMVC的知识，这里默认读者具有SpringMVC的相关知识

我们写的Controller都会被DispatcherServlet进行路由，而这种路径的路由@RequestMapping这种方式则是由RequestMappingHandlerMapping这个类去找到对应的controller方法，通过反射调用方法从而调用我们上面的test方法，那么就肯定要拿到TestController这个类，这个操作是由其父类AbstractHandlerMethodMapping的getHandlerInternal方法做的：

protected HandlerMethod getHandlerInternal(HttpServletRequest request) throws Exception {
  String lookupPath = getUrlPathHelper().getLookupPathForRequest(request);
  this.mappingRegistry.acquireReadLock();
  try {
    // 根据请求拿到需要反射调用的方法
    HandlerMethod handlerMethod = lookupHandlerMethod(lookupPath, request);
    // 关键：handlerMethod.createWithResolvedBean()获取调用方法的类
    return (handlerMethod != null ? handlerMethod.createWithResolvedBean() : null);
  }
  finally {
    this.mappingRegistry.releaseReadLock();
  }
}

这里直接看handlerMethod的关键方法createWithResolvedBean：

public HandlerMethod createWithResolvedBean() {
  Object handler = this.bean;
  if (this.bean instanceof String) {
    Assert.state(this.beanFactory != null, "Cannot resolve bean name without BeanFactory");
    String beanName = (String) this.bean;
    // 会使用testController这个beanName获取Bean
    handler = this.beanFactory.getBean(beanName);
  }
  return new HandlerMethod(this, handler);
}

如果Controller被打上@RefreshScope注解，这里getBean的返回值就是CGLib动态代理对象，根据以上流程走自然可以达到动态刷新的效果

3.2.2 @Autowired的使用

@Component
public class Test {

  @Autowired
  private PropertiesSource propertiesSource;

  public boolean test(){
    propertiesSource.getValue();
  }
}

@Service
@RefreshScope
public class PropertiesSource {

  @Value("${test.refresh}")
  private boolean test;

  public boolean getValue(){
    return test;
  }
}

这样使用也可以达到动态刷新的作用，Test类依赖注入PropertiesSource对象时会注入CGLib动态代理对象。

3.2.3 失效问题

从上面两个使用场景来看，RefreshBean被正确加载为CGLib动态代理对象就能正常动态刷新，那么什么时候会不正常加载呢？这里举一个我在3.2小节开头举的例子，WebFilter。

在WebFlux中，组装WebFilter是在WebHttpHandlerBuilder类的applicationContext方法中：

public static WebHttpHandlerBuilder applicationContext(ApplicationContext context) {
  WebHttpHandlerBuilder builder = new WebHttpHandlerBuilder(
    context.getBean(WEB_HANDLER_BEAN_NAME, WebHandler.class), context);

  // 获取上下文中 Class为WebFilter的所有Bean
  List webFilters = context
    .getBeanProvider(WebFilter.class)
    .orderedStream()
    .collect(Collectors.toList());
  builder.filters(filters -> filters.addAll(webFilters));

  //...

  return builder;
}

这里组装加载WebFilter的时候会获取IOC中WebFilter类型的Bean，这里我Debug给大家看看这个List列表
 

怎么会有两个重复的呢？

思路回到第三节讨论的扫描并注册Bean入口doScan中的createScopedProxy方法，其中针对特定Scope做一个BeanDefinition的修改：

public static BeanDefinitionHolder createScopedProxy(BeanDefinitionHolder definition,
                                                     BeanDefinitionRegistry registry, boolean proxyTargetClass) {

  // 原始Bean的名称
  String originalBeanName = definition.getBeanName();
  BeanDefinition targetDefinition = definition.getBeanDefinition();
  // 加了前缀的Bean名称
  String targetBeanName = getTargetBeanName(originalBeanName);
	
  // ...

  // Register the target bean as separate bean in the factory.
  // 这里会注册原始Bean，以targetBeanName为beanName
  registry.registerBeanDefinition(targetBeanName, targetDefinition);

  // Return the scoped proxy definition as primary bean definition
  // (potentially an inner bean).
  // 注册会生成代理Bean的FactoryBean
  return new BeanDefinitionHolder(proxyDefinition, originalBeanName, definition.getAliases());
}

可以看到，其实这里依然会将原生Bean注册到IOC容器中，只不过beanName是被加了前缀的，这里我debug看看加了什么前缀（假设我的beanName是gatewayPropertiesSource）

可以看到，这里注册了两个Bean，一个是原始名称的FactoryBean，用于生成CGLib的动态代理Bean，一个是被加上 scopedTarget. 前缀的原生Bean，为什么要注册两个Bean呢？因为后面一个Bean是被Scope对象的Map缓存所管理的，后面那个Bean则是我们的Bean本尊，动态代理Bean调用方法要获取的Bean就是这个对象，从哪里可以看出来呢？回顾3.1节的最后，getObject关键方法：

public class SimpleBeanTargetSource extends AbstractBeanFactoryBasedTargetSource {

  @Override
  public Object getTarget() throws Exception {
    // getTargetBeanName,这里是加了前缀的名称
    return getBeanFactory().getBean(getTargetBeanName());
  }
}

到这里我们可以知道，其实这个加了前缀的Bean才是我们最终使用的Bean，配置动态刷新的时候变的不是CGLib动态代理的Bean，而是里面加了前缀的Bean，这个Bean被Scope对象的Map所管理，当配置刷新时Map清空，动态代理的Bean调用方法之前先去IOC中获取加了前缀的Bean，这个加了前缀的Bean又是refresh的scope，又会去Scope中的Map寻找，发现找不到，就又在IOC容器中创建一个新的加了前缀的Bean，供后续使用，达到动态刷新的效果。

回到我们3.2.3节开头讲的失效问题，这里组装WebFilter的时候由于会获取类型为WebFilter的所有Bean，所以会把动态代理的Bean和前缀Bean全组装起来，在我们Web应用里就会使用到前缀Bean本尊，由于这个Bean不像那个动态代理Bean一样，每一次方法调用都会去IOC容器getBean，所以这个Bean是一成不变的，就算配置刷新，这个Bean实例还是那个旧的值，导致失效问题。

3.3 更优雅的动态刷新

我们知道，如果是@RefreshScope的话，每次都要去IOC获取一下Bean，感觉调用链路比较长，那么是否能不打@RefreshScope也能动态刷新属性值呢？这里还有一种方式达到动态刷新的目的，那就是@ConfigurationProperties注解，具体用法不过多赘述，这里详细讲讲ConfigurationProperties是如何做到动态刷新的。

思路回到我们第二节讲的，ContextRefresher这个类，当配置刷新的时候，这个类的refresh方法会被调用：

public synchronized Set refresh() {
  // 刷新环境
  Set keys = refreshEnvironment();
  this.scope.refreshAll();
  return keys;
}

关键在refreshEnvironment方法：

public synchronized Set refreshEnvironment() {
  Map before = extract(
    this.context.getEnvironment().getPropertySources());
  addConfigFilesToEnvironment();
  Set keys = changes(before,
                             extract(this.context.getEnvironment().getPropertySources())).keySet();
  // 发布一个EnvironmentChangeEvent事件
  this.context.publishEvent(new EnvironmentChangeEvent(this.context, keys));
  return keys;
}

熟悉的方法，这里我们的关注点在于其最后会发布一个EnvironmentChangeEvent事件，这个事件是由ConfigurationPropertiesRebinder这个类来监听的，看名字就知道，这个类负责重新设置ConfigurationProperties值。重点关注这个类的onApplicationEvent方法：

public void onApplicationEvent(EnvironmentChangeEvent event) {
  if (this.applicationContext.equals(event.getSource())
      // Backwards compatible
      || event.getKeys().equals(event.getSource())) {
    // 重新设置值
    rebind();
  }
}

在这个方法消费EnvironmentChangeEvent这个事件，进入rebind方法：

public void rebind() {
  this.errors.clear();
  // beans保存着所有ConfigurationProperties实例
  for (String name : this.beans.getBeanNames()) {
    rebind(name);
  }
}

beans实则是一个Map，我们直接debug看看这个Map保存了什么

可以看到，这里保存了54个ConfigurationProperties类实例，其中我们的ConfigurationProperties类就是上面的greyProperties

继续往下走，看看rebind对这个实例做了什么：

public boolean rebind(String name) {
  //...
  if (this.applicationContext != null) {
    try {
      // 从上下文中获取这个Bean
      Object bean = this.applicationContext.getBean(name);
      if (AopUtils.isAopProxy(bean)) {
        bean = ProxyUtils.getTargetObject(bean);
      }
      if (bean != null) {
        // TODO: determine a more general approach to fix this.
        // see https://github.com/spring-cloud/spring-cloud-commons/issues/571
        if (getNeverRefreshable().contains(bean.getClass().getName())) {
          return false; // ignore
        }
        // 调用这个Bean的destroy流程
        this.applicationContext.getAutowireCapableBeanFactory()
          .destroyBean(bean);
        // 调用这个Bean的初始化流程
        this.applicationContext.getAutowireCapableBeanFactory()
          .initializeBean(bean, name);
        return true;
      }
    }
    //...
  }
  return false;
}

重点在于调用上下文的initializeBean方法初始化Bean：

protected Object initializeBean(final String beanName, final Object bean, @Nullable RootBeanDefinition mbd) {
  
  //...
  
  // 调用aware回调
  invokeAwareMethods(beanName, bean);

  Object wrappedBean = bean;
  if (mbd == null || !mbd.isSynthetic()) {
    // 重点，调用BeanPostProcessors回调
    wrappedBean = applyBeanPostProcessorsBeforeInitialization(wrappedBean, beanName);
  }

  //...

  return wrappedBean;
}

其中的重点在于applyBeanPostProcessorsBeforeInitialization方法：

public Object applyBeanPostProcessorsBeforeInitialization(Object existingBean, String beanName)
  throws BeansException {

  Object result = existingBean;
  // BeanPostProcessor的回调
  for (BeanPostProcessor processor : getBeanPostProcessors()) {
    Object current = processor.postProcessBeforeInitialization(result, beanName);
    if (current == null) {
      return result;
    }
    result = current;
  }
  return result;
}

在BeanPostProcessor的回调中，会有一个ConfigurationPropertiesBindingPostProcessor这个BeanPostProcessor在postProcessBeforeInitialization方法中利用Binder对象，将最新的配置值反射调用set方法注入到ConfigurationProperties这样的Bean里，达到动态刷新的效果。这里限于篇幅问题，就不继续深入研究了，感兴趣的小伙伴可以跟着思路去看看源码。

这里我们看到，ConfigurationProperties这种方式不需要一直去IOC容器里getBean，也不需要动态代理，没有以上那样的失效问题，从始至终就只有一个Bean的单例，这种方式个人感觉比较优雅，建议最好使用这种方式去装配外部化配置信息。

但有些场景又需要@RefreshScope这种方式，因为@Value可以解析一些复杂的表达式，比如设置默认值，或者把配置值处理成一个List比较方便：

总之，@Value这种比较灵活，但如果配置值多了，比如外部化配置有几十个，ConfigurationProperties又比较好了，只需要写一个前缀就可以装配前缀下的所有外部化配置。两者各有好处，但建议最好优先考虑一下ConfigurationProperties，使用@RefreshScope也可以，知道原理也就能避免一些失效问题了。

4. 总结

我们总结一下，当不正常获取RefreshScope的Bean时，动态刷新会失效。例如直接从IOC容器中获取所有某类型的Bean，把beanName带前缀的那个Bean直接拿来使用了。到此，我们可以知道只有使用被动态代理增强过的那个Bean，才可以有动态刷新的效果。

3.2.3节这种WebFilter这种情况告诉我们，不要在这种方式加载使用Bean的地方用@RefreshScope，会导致Filter链重复，你会得到两个一摸一样的Filter并且还不知道，潜在影响性能。解决方法就是把要动态刷新的配置值抽出来变成一个类，在这个类上打上@RefreshScope注解，然后在WebFilter中使用@Autowired这种方式依赖注入刚刚那个配置值的专门类，很好的解决了失效问题。