@Scope作用域代理的应用：@RefreshScope注解实现动态刷新配置的底层原理与实现

@RefreshScope这个注解存在于spring-cloud-context规范包中，它的作用就是允许在服务运行的过程中，在加了@Value注解的类上加上@RefreshScope注解，那么这个属性就能够实时地动态刷新其属性值，通常用于服务整合配置中心的场景。如果认真地想一下就会觉得这个功能很神奇，因为正常来说一个bean在服务启动的时候经历了自己的生命周期，包括属性注入，之后在服务运行期间这个bean就基本不会做关于生命周期的任何事情了，也就是说也不会再次经历属性注入这个阶段了，那么这样的话动态刷新属性值是如何实现的？接下来我们就来看一下它的底层实现是如何做到这个神奇的功能的

实现原理

@RefreshScope的实现原理其实主要就是基于@Scope注解的作用域代理的基础上进行扩展实现的，因为当配置中心的配置发生改变的时候，对应加了@RefreshScope直接的类中加了@Value注解的属性值能够发生改变就说明肯定是又生成了一个新的bean（只有重新走一遍bean的生命周期才有可能使得加了@Value注解的属性重新被初始化为新的值），所以作用域代理就能够适用于解决这种场景了：当一个普通的bean依赖了一个加了@RefreshScope注解的bean之后，通过作用域代理使得这个普通bean依赖的是一个代理对象，每当调用这个代理对象的目标方法的时候就从目标源中获取到原始bean实例，而获取的方式就是通过调用getBean方法，在getBean方法中会寻找refresh作用域的scope处理类，通过这个scope处理类去生成原始bean，而这个scope处理类生成原始bean有两种方式，一种是直接取bean缓存，一种是从bean工厂中创建，当从bean工厂中创建出来的bean实例就会放到bean缓存中，只要配置中心不发生更改，那么这个缓存就一直存在，但是如果配置中心发生了变更，会把变更的配置更新到spring容器的Environment中，并且同时bean缓存就会被清空，从而就会从bean工厂中创建bean实例了，而这次创建bean实例的时候就会继续经历这个bean的生命周期，使得@Value属性值能够从Environment中获取到最新的属性值，这样整个过程就达到了动态刷新配置的效果

源码分析

（1）@RefreshScope

可以看到@RefreshScope注解其实就是给@Scope注解包了一层，并且指定了refresh这个自定义的scope作用域，同时也声明开启了proxyMode，也就是开启了scope的作用域代理

（2）RefreshAutoConfiguration

在spring-cloud-context包的spring.factories文件中，可以看到有一个叫RefreshAutoConfiguration的自动配置类，该配置类就是与自动刷新有关，打开这个类可以看到有一个比较重要的组件RefreshScope：

RefreshScope继承于GenericScope，我们继续看它的父类GenericScope

（3）GenericScope

通过继承图可以看出，GenericScope继承了BeanDefinitionRegistryPostprocessor，熟悉spring的应该知道这个组件是spring中很重要的一个组件，对于自定义的BeanDefinitionRegistryPostprocessor的执行时机是在spring扫描到所有的BeanDefinition之后去执行的，也就是说在自定义BeanDefinitionRegistryPostprocessor的postProcessBeanDefinitionRegistry方法中就可以获取到spring容器中的所有BeanDefinition了，那么我们看一下GenericScope是如何实现postProcessBeanDefinitionRegistry方法的：

在该方法中会去获取到spring容器中所有的BeanDefinition进行遍历，遍历的时候会有个很重要的条件进行判断找到decoratedDefinition属性不为空并且beanClass等于ScopedProxyFactory的BeanDefinition，那么什么BeanDefinition能符合这两个条件呢？答案就是使用了scope作用域代理的BeanDefinition，其中就包括了我们这里说的加了@RefreshScope注解的bean。当找到了这个bean之后，就把beanClass改成LockedScopedProxyFactoryBean类型，然后还把当前的RefreshScope对象作为LockedScopedProxyFactoryBean实例化构造方法的参数，看下LockedScopedProxyFactoryBean的构造方法：

其中这个泛型S就是RefreshScope实例。我们再回到GenericScope的继承图，它还实现了一个比较重要的接口，那就是Scope接口，Scope接口就是spring给用户自己拓展scope作用域的时候去使用的，因为上面我们知道@RefreshScope注解所声明的scope作用域是refresh，所以自然也需要有一个负责生成refresh作用域的bean的处理类，该处理类就需要实现Scope接口，以上都是关于spring的自定义scope的知识，这里就不再细说了。所以自然地我们就需要去关注实现了scope接口的方法，但是我们这里先不用去看，我们关注的是这个scope是如何注册上spring的

在GenericScope实现的postProcessBeanFactory方法中就可以找到通过BeanFactory去把自身这个scope注册到容器中了，并且注意的是这个注册scope的阶段是在postProcessBeanDefinitionRegistry方法执行之后执行的

（4）LockedScopedProxyFactoryBean

通过上面我们可以知道加了@RefreshScope注解的bean的classBean会变成LockedScopedProxyFactoryBean这个类型，首先看下它的继承图

可以看到它继承了ScopedProxyFactoryBean，这个类很熟悉，就是处理scope作用域代理的时候生成代理对象的一个关键类，对于这个类的作用这里就不再阐述了，之前讲spring的scope作用域代理的时候已经说过了。并且LockedScopedProxyFactoryBean还实现了MethodInterceptor接口，表示自己是一个拦截器，接下来看下LockedScopedProxyFactoryBean的setBeanFactory方法：

首先会调用父类ScopedProxyFactoryBean的setBeanFactory方法，执行完父类的方法之后此时就可以通过getObject方法拿到生成的代理对象了，并且如果代理对象实现了Advised接口，那么就会把当前自己这个拦截器放入到候选的拦截器列表中（在代理对象执行代理方法的时候会从候选的拦截器列表中通过pointcut去筛选出待执行的拦截器，而这里通过addAdvice方法直接添加的拦截器默认的pointcut就是全部方法都经过该拦截器）

在invoke方法中：

1.当调用equal方法，toString方法，hashCode方法以及ScopedObject的getTargetObject方法的时候就继续进行后面拦截器的链式调用

2.获取一把读锁

3.加读锁，从spring容器中获取到对应最新的bean，然后在这个bean中执行代理方法

很明显，这个拦截器主要做的事情就是从目标源中获取到spring容器中最新的bean，然后对这个bean执行目标代理方法，这样每次都从spring容器中重新获取一次最新的bean就可以保证这个bean中带有@Value注解的属性值是最新的，达到我们动态刷新属性配置的目的​​​​​​​

（5）获取refresh作用域的bean实例

我们知道当作用域代理对象调用代理方法的时候会从目标源中获取到一个当前spring容器最新的bean的作为目标代理对象，也就是调用getBean方法，在调用getBean方法的过程中因为这个bean加了@RefreshScope注解，所以spring会去寻找处理refresh作用域的scope组件，此时就会来到GenericScope的get方法

 

可以看到cache这个map中会存放每一个refresh作用域的beanName及其对应的BeanLifecycleWrapper对象，然后这个BeanLifecycleWrapper对象里面就会存储refresh作用域的那个bean，但是这里是做了一个缓存的，就是缓存了代理对象第一次调用代理方法的时候从spring容器中获取到的bean实例，这个缓存的作用就是防止一直从spring中去获取这个bean实例，比如说这个bean中带有@Value的属性值一直都没有在配置中心中进行修改，那么每一次代理对象在执行代理方法时都会通过目标源从spring容器中去拿这个bean实例显然是没必要的。

（6）配置中心发生改变后刷新bean缓存

上面说的bean缓存的作用是这个bean@Value属性值一直没有被配置中心修改防止无必要地去spring容器中获取最新的bean实例，但这就又有一个问题了，就是如果配置中心修改了这个bean的@Value属性值呢？那么这个缓存不得需要失效吗？确实是这样，当配置中心发生了修改，这个缓存会被清空：

 

 

通过debug，可以看到在配置中心发生修改的时候会来到RefreshScope的refreshAll方法，并且会调用父类GenericScope的destroy方法，在这个destroy方法中就会把缓存赋值为null，同时，在refreshAll方法中还会发发布一个RefreshScopeRefreshedEvent事件，但是这个事件springcloud并没有对其进行实现监听，用户可以自己进行对这个事件进行监听扩展

（7）配置中心发生改变后从哪里开始发起刷新bean缓存

根据debug我们可以发现在spring-cloud-context包发起刷新bean缓存的调用链源头是在RefreshEventListner这个类中

可以发现这个RefreshEventListener是一个监听器，监听了RefreshEvent事件，当收到RefreshEvent事件之后就会最终调用到GenericScope的destroy方法刷新bean缓存，那么这个RefreshEvent事件是谁发出来的呢？首先RefreshEvent这个事件是在spring-cloud-context中定义的，所以也就是意味着这个事件是由具体的配置中心整个springcloud的时候去进行发起的，这就是spring-cloud-context规范包起到的低耦合高内聚的作用了，那么我们这里是使用nacos作为配置中心的，所以我们去nacos配置中心的springcloud整合包就可以找到发起RefreshEvent事件了

 

 

可以看到在nacos配置中心的springcloud整合包中有一个NacosContextRefresher的类，这个类也是一个监听器，它监听的事件是ApplicationReadyEvent事件，这个事件是在springboot启动完成的时候进行发起的，当监听器这个事件之后就会把nacos的配置监听器进行注册，如果配置发生了改变，那么就会回调这个配置监听器，而这个配置监听器的回调逻辑其中就有发送一个RefreshEvent事件，发起这个事件之后，就会被我们上面说的spring-cloud-context包中的RefreshEventListener监听器所监听到，最终刷新GenericScope的bean缓存

（8）配置中心改变后如何同步到spring的Environment中？

在配置中心发生改变之后，应该是需要把对应的最新配置更新到spring的Environemnt中的，然后后面通过getBean方法所生成的bean中的@Value属性值才会是最新的，那么这个过程是在哪里做的呢？

根据上面所分析的当监听到配置中心所发布的RefreshEvent事件之后，就会调用ContextRefresh的refresh方法，在这个refresh方法中就会有一个refreshEnviroment方法，在这个方法中就会把最新的配置更新到spring容器的Environment中，具体如何更新的比较复杂这里就不说了

整个动态刷新配置的流程图