nacos配置动态刷新源码分析(也就是@RefreshScope的工作原理)

最新推荐文章于 2024-03-18 09:18:53 发布

喜欢读源码的小白

最新推荐文章于 2024-03-18 09:18:53 发布

阅读量2.8k

点赞数 2

分类专栏： spring源码解析 springboot源码解析 java 文章标签： spring java springboot spring cloud

本文链接：https://blog.csdn.net/qq_41835065/article/details/128660046

版权

springboot源码解析同时被 3 个专栏收录

2 篇文章 0 订阅

订阅专栏

java

2 篇文章 0 订阅

订阅专栏

spring源码解析

1 篇文章 0 订阅

订阅专栏

@RefreshScope注解的源码分析(基于nacos的讲解)

1.本篇文章主要解答的问题步骤

①.RefreshScope bean对应的BeanDefinition的解析

②.RefreshScope bean创建过程解析

③.nacos的刷新事件解析

2. 功能介绍:

当配置中心的属性发生更改时该注解可以让bean对应的属性值实时更新

3 使用介绍

@RefreshScope
@Component
@Data()
public class NacosConfig {

    @Value("${server.port}")
    private String port;

}

注意:

①. 配置的类必须要注入到ioc容器中
②.必须要提供get方法,否则不会生效(具体原因下面解析会说)

4.宏观流程

在这里插入图片描述

5.源码分析

宏观流程解析

1.spring对@RefreshScopre注解的bean做的事情

1.当调用被@RefreshScope注解的bean的属性的get方法时则先从本地缓存里面获取
2.当本地缓存中不存在当前bean时则重新创建此时会获取 sping中最新环境配置
3.如果本地缓存中存在当前 bean则直接返回对应属性值

2.nacos对@RefreshScopre注解的bean做的事情

1.当配置更改时 nacos服务端会发步一个配置已被更新事件
2.此时 naocs客户端会接受到这个事件接受到以后会再在spring中发布环境配置刷新事件
3.然后对应的监听器收到以后则刷新spring环境配置以及清空本地缓存

6.相信很多人看完流程图后会有很多问题比如:

1. 为什么调用get方法时会从缓存里面获取bean 我明明get方法里面什么逻辑也没做呀

2.@RefreshScope注解的bean 是如何创建的和其他的常规单例bean有什么不一样,缓存是存在哪里的

3.nacos配置中心刷新事件是在哪触发的如何触发的

7.解答

1. 为什么调用get方法时会从缓存里面获取bean 我明明get方法里面什么逻辑也没做呀

①答案是动态代理没错此时的bean被spring代理了并且对get方法做了拦截

②.源码解析

(1)先认识一下@RefreshScope注解的定义

@RefreshScope注解上只有一个核心注解@Scope 并且value为refresh,spring就是根据这个@Scope注解来扫描解析的

(2) 在看一下解析@RefreshScope的地方(代码位置:ClassPathBeanDefinitionScanner#doScan)

在这里插入图片描述

1.第276行代码是扫描当前的类路径(值为ComponentScan注解的value值) 找到所有在指定路径下符合条件的类
2.第278行是查询指定类上有没有@Scope注解如果有则将value值设置到bean定义中然后注册到ioc容器中
3. @RefreshScope注解上有@Scope注解所以在这里也可以被扫描到(具体的可以打断点进去看)
4. 第290行主要是对当前bean定义在做一层封装具体看下图

在这里插入图片描述

1.接着上面的图的逻辑跟进来发现就是又创建了一个RootBean定义然后设置了类型为ScopedProxyFactoryBean(这个类很重要) 主要是关注这个ScopedProxyFactoryBean类(后面会用到)
2.对我们的bean做了动态代理的就是这个类(ScopedProxyFactoryBean)是嫌疑犯之一后面会重点介绍

现在又引入了一个新的问题为什么要设置成ScopedProxyFactoryBean类上面说到是为了做代理那么它又是在哪里被引用的又是做了哪些代理这个就不得不说到 RefreshScope 这个类了注意这个是类嗷不是注解看下图的RefreshScope类层级结构

在这里插入图片描述

1.可以看到RefreshScope类继承了GeneriScopre(这个类是重点)

GeneriScopre绝对的重点类(做缓存的就是它) 下面是GenScope的类定义图

先前介绍:BeanDefinitionRegistryPostProcessor的作用以及触发时机

1.作用:允许在所有常规bean注册之前对ioc容器中的bean定义做进一步修改
2.触发时机:从上面一句话也能看到是在所有常规bean注册之前
3.代码触发初始位置是在:AbstractApplicationContext#refresh方法中调用invokeBeanFactoryPostProcessors方法其实BeanDefinitionRegistryPostProcessor是来自BeanFactoryPostProcessor的扩展也就是继承了BeanFactoryPostProcessor接口
4.该类只有一个方法postProcessBeanDefinitionRegistry

在这里插入图片描述

从上面的介绍以及图中的红框也大致猜出来了重点是在BeanDefinitionRegistryPostProcessor类中所以下面我们来看看GenericScope对postProcessBeanDefinitionRegistry的实现

在这里插入图片描述

1.第248行判断进来的bean定义的类是否是ScopedProxyFactoryBean类(这是一开始扫描的时候要设置类为ScopedProxyFactoryBean的原因第一个原因)
2.因为RefreshScope继承了GenericScope并且默认构造器中修改了name属性然后看下面的调用栈其实这里是从RefreshScope进来的所以第249行的getName是Refresh字符串
3.如果类型是ScopedProxyFactoryBean并且当前bean的Scope为Refresh 则将对应的bean class改为LockedScopedProxyFactoryBean类(动态代理的最后一个嫌疑犯来了)

前面铺垫的差不多了到这里ScopedProxyFactoryBean以及LockedScopedProxyFactoryBean两个做动态代理最最重要的两个类来了下面就是开始对第一个问题答案做最终的解答

老规矩先介绍一下这两个类

1.ScopedProxyFactoryBean

先前介绍:1.BeanFactoryAware 的作用和触发时机

1.作用:为指定的提供一个beanFactory实例只有一个方法setBeanFactory 并且传入了一个当前beanFactory实例
2.触发时机:在指定bean实例化之后初始化之前代码位置:AbstractAutowireCapableBeanFactory#initializeBean的第一行调用invokeAwareMethods方法

在这里插入图片描述

看完先前介绍也差不多明白了这个类核心逻辑是在beanFactory#setBeanFactory方法中所以一起来看看吧(这个方法也就是生成代理对象的逻辑)

在这里插入图片描述

1.215行之前都是在设置各种接口什么
2.215行就是真正的生成代理
3.第95行我圈出了一个SimpleBeanTargetSource 这个类里面有一个getTarget 这个方法也就是代理之后真正执行的逻辑具体看下图

在这里插入图片描述

1.也就是再调用一次ioc的getBean方法重新创建一个bean
2.到这里可以透露一下刷新机制就是先删除之前的bean 之后再创建新的

####上面生成代理对象的逻辑找到了那么拦截的地方在哪了我们可以看一下下面的调用栈
在这里插入图片描述

1.可以看到我圈出来的地方很惊奇的发现当前断点是从LockedScopedProxyFactoryBean这个类里面进来的那么你们也差不多猜到了这个LockedScopedProxyFactoryBean肯定是继承了ScopedProxyFactoryBean
2.一般要对方法拦截那么肯定会实现MethodInterceptor这个接口而我们在ScopedProxyFactoryBean这个类没有看见那么肯定就在LockedScopedProxyFactoryBean这个类里面了因此让我们在看一下LockedScopedProxyFactoryBean这个类吧看下图

在这里插入图片描述

果然LockedScopedProxyFactoryBean这个类实现了MethodInterceptor接口所以拦截的地方就在这个类了所以接下来重点看一下MethodInterceptor#invoke方法

在这里插入图片描述

1.从调用栈第二个圈的地方可以看出我们当前调用的这个对象是一个代理对象
2.482行里面的advised.getTargetSource().getTarget()这里就是代理增强的代码的调用
也就是会调用到我在调用栈里第一个圈的地方这个方法的路径看下图

在这里插入图片描述

1.重点在35行打断点的地方会调用一次 beanFaacctory的getBean方法
2.这getBean里面的逻辑是下一个问题的答案这里先简单说一下
3.这里的getBean方法要走的逻辑是先判断当前本地缓存里面有没有当前bean对象
如果有的话则直接取如果没有的话则直接重新创建对象重新获取spring环境里的最新配置值
4.那么什么时候会没有呢当配置中心发起配置更新事件此时客户端对应的监听事件会清空缓存并且更新spring环境具体过程往下看

2.@RefreshScope注解的bean 是如何创建的缓存是存在哪里的

1.首先看下图位置在AbstractBeanFactory#doGetBean里

在这里插入图片描述

1.这一段代码是被@scope注解的对象的创建逻辑
2.可以看到 362行在创建之前(也就是在调用beanFactory的createBean之前) 会先调用RefreshScope的get方法传入了两个参数一个beanName 还有一个lambda表达式这个表达式是ObjectFactory类型的看到下面就知道了
3.其实这个get方法是GenericScope提供的 RefreshScope类并没有重写所以我们直接来看GenericScope#get方法

在这里插入图片描述

1.看第二个参数就可以得知刚刚上张图传进来的lambda表达式是个ObjectFactory类型的也就是一个创建对象的工厂类
2.重点来了看第176行一进来首先就把beanName和对应的工厂对象放进一个BeanLifecycleWrapper类然后放入到this.cache里面这个是真正的缓存类
3.第179就是真正的创建对象了然后我们来看BeanLifecycleWrapper#getBean方法这个类重点的逻辑就在这里面

在这里插入图片描述

1.这一段逻辑就是真正的核心逻辑了
2.先判断当前这个缓存里面是不是为null 如果不是就从对应的ObjectFactory
工厂中重新创建
3.如果不为null 则直接返回当前bean

这下@RefreshScope的对象如何创建的缓存又是那个类这个问题解决了接下来就是解析缓存里的对象是什么时候清空的该解决第三个问题了

3.nacos配置中心刷新事件是在哪触发的如何触发的

首先让我们了解一下 NacosContextRefresher类

1.这个类监听了ApplicationReadyEvent事件这个是重点
2.那么既然实现了ApplicationReadyEvent的监听器那么onApplicationEvent方法里的逻辑则是重点

这个ApplicationReadyEvent是什么时候触发的 onApplicationEvent里面的逻辑是怎么实现的我们接的往下看

在这之前我本来用的是jdk17+springboot3 但是一开始说spring源码的时候没有问题但是当说第三方start库(如nacos)时就会发现出现问题了因为jdk17很多依赖路径的改变还有spring-boot3丢弃了读取spring.factory文件的自动配置类逻辑所以导致
很多第三方自动配置加载不了所以下面的项目我换成了jdk8+springboot2.2.6版本了

在这里插入图片描述