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

刺骨的言语ヽ痛彻心扉 2023-02-14 05:45 23阅读 0赞

# 前言 #

在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> T doGetBean(final String name, @Nullable final Class<T> 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<String, Object> cache = new ConcurrentHashMap<String, Object>();
    
      //...
    
      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;
      }
    }

这里就是将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方法，那么我们由此为入口来分析一下，热加载配置的原理：

// 这就是我们上面一直分析的Scope对象（实际上可以看作一个保存refreshBean的Map）
    private RefreshScope scope;
    
    public synchronized Set<String> refresh() { 
      // 更新上下文中Environment外部化配置值
      Set<String> keys = refreshEnvironment();
      // 调用scope对象的refreshAll方法
      this.scope.refreshAll();
      return keys;
    }

我们一般是使用@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<String> refreshEnvironment() { 
      // 获取刷新配置前的配置信息，对比用
      Map<String, Object> before = extract(
        this.context.getEnvironment().getPropertySources());
      // 刷新Environment
      addConfigFilesToEnvironment();
      // 这里上下文的Environment已经是新的值了
      // 进行新旧对比，结果返回有变化的值
      Set<String> 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<Throwable> errors = new ArrayList<Throwable>();
      // 缓存清空
      Collection<BeanLifecycleWrapper> wrappers = this.cache.clear();
      // ...
    }

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

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

public Object get(String name, ObjectFactory<?> objectFactory) { 
      // 由于刚刚清空了缓存Map，这里就会put一个新的BeanLifecycleWrapper实例
      BeanLifecycleWrapper value = this.cache.put(name,
                                                  new BeanLifecycleWrapper(name, objectFactory));
      this.locks.putIfAbsent(name, new ReentrantReadWriteLock());
      try { 
        // 在这里是新的BeanLifecycleWrapper实例调用getBean方法
        return value.getBean();
      }
      catch (RuntimeException e) { 
        this.errors.put(name, e);
        throw e;
      }
    }

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] 中有讲到，SpringBoot的注解驱动注册Bean是由ConfigurationClassPostProcessor类来做的，其中@ComponentScan会扫描并注册包下带有@Componet注解的类为Bean，达到一个注解驱动注册Bean的效果。而扫描Bean并注册为BeanDefinition这一过程是由ClassPathBeanDefinitionScanner类的doScan方法去做的，我们先来看看扫描Bean的时候，对于RefreshScope的Bean有什么特殊处理：

protected Set<BeanDefinitionHolder> doScan(String... basePackages) { 
      Assert.notEmpty(basePackages, "At least one base package must be specified");
      Set<BeanDefinitionHolder> 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这个类  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxNzM3NzE2_size_16_color_FFFFFF_t_70_pic_center]

然而这个类又是一个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<WebFilter> webFilters = context
        .getBeanProvider(WebFilter.class)
        .orderedStream()
        .collect(Collectors.toList());
      builder.filters(filters -> filters.addAll(webFilters));
    
      //...
    
      return builder;
    }

这里组装加载WebFilter的时候会获取IOC中WebFilter类型的Bean，这里我Debug给大家看看这个List列表  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxNzM3NzE2_size_16_color_FFFFFF_t_70_pic_center 1]

怎么会有两个重复的呢？

思路回到第三节讨论的扫描并注册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）  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxNzM3NzE2_size_16_color_FFFFFF_t_70_pic_center 2]

可以看到，这里注册了两个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());
      }
    }

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxNzM3NzE2_size_16_color_FFFFFF_t_70_pic_center 3]  
到这里我们可以知道，其实这个加了前缀的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<String> refresh() { 
      // 刷新环境
      Set<String> keys = refreshEnvironment();
      this.scope.refreshAll();
      return keys;
    }

关键在refreshEnvironment方法：

public synchronized Set<String> refreshEnvironment() { 
      Map<String, Object> before = extract(
        this.context.getEnvironment().getPropertySources());
      addConfigFilesToEnvironment();
      Set<String> 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保存了什么  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxNzM3NzE2_size_16_color_FFFFFF_t_70_pic_center 4]

可以看到，这里保存了54个ConfigurationProperties类实例，其中我们的ConfigurationProperties类就是上面的greyProperties  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxNzM3NzE2_size_16_color_FFFFFF_t_70_pic_center 5]

继续往下走，看看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比较方便：  
![在这里插入图片描述][20200601090153827.png_pic_center]

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

# 4. 总结 #

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

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

[SpringBoot]: https://blog.csdn.net/qq_41737716/article/details/98028738
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxNzM3NzE2_size_16_color_FFFFFF_t_70_pic_center]: https://img-blog.csdnimg.cn/20200601090017930.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxNzM3NzE2,size_16,color_FFFFFF,t_70#pic_center
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxNzM3NzE2_size_16_color_FFFFFF_t_70_pic_center 1]: https://img-blog.csdnimg.cn/20200601090035822.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxNzM3NzE2,size_16,color_FFFFFF,t_70#pic_center
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxNzM3NzE2_size_16_color_FFFFFF_t_70_pic_center 2]: https://img-blog.csdnimg.cn/20200601090053747.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxNzM3NzE2,size_16,color_FFFFFF,t_70#pic_center
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxNzM3NzE2_size_16_color_FFFFFF_t_70_pic_center 3]: https://img-blog.csdnimg.cn/20200601090109929.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxNzM3NzE2,size_16,color_FFFFFF,t_70#pic_center
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxNzM3NzE2_size_16_color_FFFFFF_t_70_pic_center 4]: https://img-blog.csdnimg.cn/20200601090126162.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxNzM3NzE2,size_16,color_FFFFFF,t_70#pic_center
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxNzM3NzE2_size_16_color_FFFFFF_t_70_pic_center 5]: https://img-blog.csdnimg.cn/20200601090139595.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxNzM3NzE2,size_16,color_FFFFFF,t_70#pic_center
[20200601090153827.png_pic_center]: https://img-blog.csdnimg.cn/20200601090153827.png#pic_center