好奇怪，@Value不能获取最新的配置？

╰半橙微兮° 2023-10-10 18:36 77阅读 0赞

### 前言 ###

公司使用Apollo做配置中心，也没怎么具体了解过。只知道有配置使用时用@Value就能获取到了，而且还能自动刷新。遂一直以为@Value本身有自动刷新功能。

直到有一天用nacos做配置中心。哎？我的配置怎么不能自动刷新了？`@Value`出问题了吗？

#### 我的controller ####

![format_png][]

#### 我的nacos配置 ####

![format_png 1][]

#### 修改nacos配置 ####

把`account.name`改为杜甫

![format_png 2][]

可以看到控制台也打印了`refresh keys changed`

![format_png 3][]

可是调用接口得到的值仍是更新前的

![format_png 4][]

后面才知道nacos要配合`@RefreshScope`使用才能自动刷新。Apollo的`@Value`自动刷新功能算是一个机制了。

于是加上`@RefreshScope`试验一下

![format_png 5][]

先把nacos中的`account.name`配置改为李白，启动项目之后，再改为杜甫，然后调用接口获取`account.name`

![format_png 6][]

这次获取到的配置就是最新的了。

为什么Apollo能实现`@Value`的自动刷新，而nacos需要配合`@RefreshScope`呢？

本文旨在分析Apollo和nacos为什么能实现配置自动，和他们的实现方式有什么不同。

先简单看一下Apollo为什么能实现`@Value`的自动更新

### Apollo的自动更新 ###

Apollo的自动更新比较简单

`AutoUpdateConfigChangeListener#onChange`

`AutoUpdateConfigChangeListener`是一个监听器，监听`ConfigChangeEvent`事件。客户端会一直向远程拉取，当配置发生变化就会发布这个事件。

![format_png 7][]

可以看到通过`springValueRegistry`获取到了`SpringValue`的集合。`SpringValue`是Apollo维护的来更新spring中`@Value`值变化后的类。里面维护了`@Value`的占位符，bean，field等信息。通过继承BeanPostProcessor实现`postProcessBeforeInitialization`来维护起来的，这里不管他，只要知道他维护了`@Value`注释的字段和bean信息就行了。

继续看`updateSpringValue`

typescript

复制代码

`private void updateSpringValue(SpringValue springValue) { try { //解析出表达式的值 Object value = resolvePropertyValue(springValue); //更新 springValue.update(value); logger.info("Auto update apollo changed value successfully, new value: {}, {}", value, springValue); } catch (Throwable ex) { logger.error("Auto update apollo changed value failed, {}", springValue.toString(), ex); } }`

继续走`springValue.update()`方法

![format_png 8][]

我们这里挑一个看

![format_png 9][]

![format_png 10][]

可以看到这里先获取bean(弱引用)，然后更新这个字段的值(`Field.set()`方法)。

#### 总结： ####

Apollo自己维护了`@Value`的信息，当有变化时，Apollo直接更新使用`@Value`注解bean的字段值

### nacos的自动更新 ###

nacos的自动更新使用了spring的机制，因此比较复杂，所以nacos的自动更新机制我们详细看看。

在nacos-config的`spring.factoies`中,注入了`NacosConfigAutoConfiguration`

![format_png 11][]

在`NacosConfigAutoConfiguration`里面注入了一个`NacosContextRefresher`的Bean

![format_png 12][]

这个Bean实现了`ApplicationListener`，监听`ApplicationReadyEvent`事件，这个事件会在spring就绪后发布，也就是`SpringApplication#run()`的最后。

![format_png 13][]

![format_png 14][]

![format_png 15][]

继续到`registerNacosListener`里，重点看一下画红圈的部分

![format_png 16][]

`applicationContext.publishEvent`，这里发布了一个`RefreshEvent`事件，这个事件会由`RefreshEventListener`来处理，这个事件的处理我们下面说。

先来看`configService.addListener`。`configService`是nacos具体实现配置发布、更新、获取、删除的实现类，具体就是拼接url和参数调用远程的nacos服务。`addListener`就是添加监听器

![format_png 17][]

![format_png 18][]

到这里nacos添加上了配置更新的监听器，那么这个监听器是在哪触发的呢？

还是`ConfigService`，它的实现类`NacosConfigService`中的构造方法中。

![format_png 19][]

在构造方法中，创建了`ClientWorker`。

![format_png 20][]

在`ClientWorker`会启动定时任务调用`checkConfigInfo()`。还创建了一个线程池赋值给executorService。

在`checkConfigInfo()`中会使用这个线程池执行任务

![format_png 21][]

可以看到提交了`LongPollingRunnable`这个任务，继续看一下他的`run`方法

这个方法有点长，只截取一部分

![format_png 22][]

可以看到如果 远程发现了有配置更新，就会更新缓存为最新值，`checkUpdateDataIds`和`getServerConfig`就是http请求nacos服务端获取数据，这里不展开了，感兴趣的可以自己看一下。

到此为止，我们动态更新的配置已经可以被nacos检测到了。那为什么`@Value`返回的值还是旧的呢。

这就要回到我们刚才略过的`applicationContext.publishEvent`，发布的`RefreshEvent`事件了。

![format_png 23][]

`RefreshEventListener`监听`RefreshEvent`事件，在`RefreshEventListener`的`handle`里对事件做处理

![format_png 24][]

`refresh`方法就是能刷新配置的重点了。`refresh`方法里一共调用了两个方法我们一个一个来看

先看`refreshEnvironment`

![format_png 25][]

`refreshEnvironment`是一个更新配置的方法，可以看到是先获取到before(之前的配置)，然后用之后的配置更新配置。同样都是使用`this.context.getEnvironment().getPropertySources()`来获取配置，在中间调用了`addConfigFilesToEnvironment()`，为什么调用`addConfigFilesToEnvironment`之后就能获取到新的了呢？

在`addConfigFilesToEnvironment`中会创建一个新的spring上下文，最终会调用到`SpringApplication.run()`里(是不是很熟悉，又到了spring经典的`run`方法)。

在`run()`方法中有个`prepareContext()`，再往里调用`applyInitializers`。在`applyInitializers`里会遍历所有实现了`ApplicationContextInitializer`的接口(在Spring容器刷新之前执行的一个回调函数，通常用于向Spring容器中注入属性)，调用其中的`initialize`方法。

啊啊啊？这都哪到哪啊。这个关我自动刷新什么事？别急，这就有关联了。

`PropertySourceBootstrapConfiguration`(也会由`spring.factories`注入)，这个类就实现了`ApplicationContextInitializer`(也就是向spring容器注入属性的接口)。所以在`prepareContext`的`applyInitializers`方法中就会调用它的`initialize`方法。

在`initialize`中会调用`PropertySourceLocator`接口的`locateCollection`。nacos的`NacosPropertySourceLocator`就实现了这个接口，会向nacos获取配置，这样nacos里的配置就是最新的了。再往下他会塞到`environment`里，这样`this.context.getEnvironment().getPropertySources()`就能获取到最新的配置了。

在`addConfigFilesToEnvironment`做完这些工作后就会把新创建的spring上下文关闭。

看到这好像大功告成了，但其实还有个问题，配置变了，bean里通过`@Value`获取到的值可没变。怎么把它的值给更新呢？spring选择了非常简便的方法，弄个新的出来。

继续看refresh里调用的`refreshAll()`方法

![format_png 26][]

![format_png 27][]

这里的`this.cache`是`BeanLifecycleWrapperCache`，里边存放`BeanLifecycleWrapper`。`BeanLifecycleWrapper`里存放了bean的名称和`ObjectFactory`。`ObjectFactory`提供了一个`getObject()`方法，用于获取对象实例。

![format_png 28][]

那代码把`cache`清空，把`BeanLifecycleWrapper`都销毁有什么用呢？我们先去看一下`BeanLifecycleWrapper`是怎么放进去的。

看一下`Scope`的实现类`GenericScope`的`get`方法

![format_png 29][]

`get`方法创建了新的`BeanLifecycleWrapper`放入到`cache`里。注意这里的`cache.put()`最终调用的是`ConcurrentHashMap`的`putIfAbsent`，如果已有可就不放了。返回的即是`BeanLifecycleWrapper`的`getBean()`方法。

![format_png 30][]

`getBean`就会调用`ObjectFactory`的`getObject`方法来获取对象。

那这个`get`方法在哪里被调用的呢，就是我们最熟悉的`doGetBean`

![format_png 31][]

在`doGetBean`里会检测bean的`scope`，`scope`不是单例和原型的会走这个else里的逻辑。然后回去`scope`里调用`get`。标注了`@RefreshScope`注解的bean的`scope`为`refresh`，就会走这个else里的逻辑。

那逻辑就清楚了：在有值更新后，销毁scope里cache里的`BeanLifecycleWrapper`，当有请求到达bean的时候，`doGetBean`获取bean时，由于找不到原来的`BeanLifecycleWrapper`，又新建一个`BeanLifecycleWrapper`然后调用`getBean`,返回一个全新的bean，在新的bean里就有刷新的配置了。如果没有值更新，下次当有请求到达bean的时候，`doGetBean`获取bean时，`BeanLifecycleWrapper`仍存在，返回的bean仍是上次那个。

到这里，自动刷新才算完成了。最后我们大白话总结一下。

#### 总结 ####

nacos有任务去检查远程的配置和本地的配置是否一样，不一样的话就发布spring的事件，spring监听到后会创建一个新的上下文环境获取最新配置然后刷新配置，并且删除掉scope的缓存，使下次获取bean时重新创建一个新的bean，在新的bean中就会有刷新后的配置。

[format_png]: https://img-blog.csdnimg.cn/img_convert/22226c5890c6cbb448f87f95c1e01c90.webp?x-oss-process=image/format,png
[format_png 1]: https://img-blog.csdnimg.cn/img_convert/91171095c385728915f9c1f7ce0a0e21.webp?x-oss-process=image/format,png
[format_png 2]: https://img-blog.csdnimg.cn/img_convert/77633a31a0145c4a11669abdd3e65d1f.webp?x-oss-process=image/format,png
[format_png 3]: https://img-blog.csdnimg.cn/img_convert/8c051fbb358aec86311a8b3f8e007658.webp?x-oss-process=image/format,png
[format_png 4]: https://img-blog.csdnimg.cn/img_convert/5a4a6c73c4eae0339cd9de2c2b05f24b.webp?x-oss-process=image/format,png
[format_png 5]: https://img-blog.csdnimg.cn/img_convert/6af09ac523dcb8c160577353ab54bd56.webp?x-oss-process=image/format,png
[format_png 6]: https://img-blog.csdnimg.cn/img_convert/862c0ce14adc1fbfe4ffee6837ae2223.webp?x-oss-process=image/format,png
[format_png 7]: https://img-blog.csdnimg.cn/img_convert/b7e98f898f923c79ca52442fa1362c3c.webp?x-oss-process=image/format,png
[format_png 8]: https://img-blog.csdnimg.cn/img_convert/b1a61382a6f0dd3543a464cd04f6096c.webp?x-oss-process=image/format,png
[format_png 9]: https://img-blog.csdnimg.cn/img_convert/739af736edaa9eb71d230e7573eaf9f8.webp?x-oss-process=image/format,png
[format_png 10]: https://img-blog.csdnimg.cn/img_convert/14c601192b5e8009383cd62ad7c7a110.webp?x-oss-process=image/format,png
[format_png 11]: https://img-blog.csdnimg.cn/img_convert/c12b0fb7e1bf161a193a920a41d1eb3a.webp?x-oss-process=image/format,png
[format_png 12]: https://img-blog.csdnimg.cn/img_convert/16add2a2b8fc024a42fda7c72761a72f.webp?x-oss-process=image/format,png
[format_png 13]: https://img-blog.csdnimg.cn/img_convert/5531d5083394b3b0741db1365aca31e3.webp?x-oss-process=image/format,png
[format_png 14]: https://img-blog.csdnimg.cn/img_convert/746bddab7b8ba324255c6a81150d0de5.webp?x-oss-process=image/format,png
[format_png 15]: https://img-blog.csdnimg.cn/img_convert/93f6b5bcebc3cdfe8ffd6aaaff43057f.webp?x-oss-process=image/format,png
[format_png 16]: https://img-blog.csdnimg.cn/img_convert/abb5d98477141d15dbd0beacfd132ce5.webp?x-oss-process=image/format,png
[format_png 17]: https://img-blog.csdnimg.cn/img_convert/aa03b17460a7c2264b91ec340e142469.webp?x-oss-process=image/format,png
[format_png 18]: https://img-blog.csdnimg.cn/img_convert/c2f8f789c9b6e02f57f2a1d3d1dcecfb.webp?x-oss-process=image/format,png
[format_png 19]: https://img-blog.csdnimg.cn/img_convert/e588e5783557e2d21dcb89f158f83045.webp?x-oss-process=image/format,png
[format_png 20]: https://img-blog.csdnimg.cn/img_convert/28317708e1bf8b9c3989d8573f3cb4f8.webp?x-oss-process=image/format,png
[format_png 21]: https://img-blog.csdnimg.cn/img_convert/1136e75a68c0a59b13735415c27c0244.webp?x-oss-process=image/format,png
[format_png 22]: https://img-blog.csdnimg.cn/img_convert/ae8576ff851c37260863f8a397783ab5.webp?x-oss-process=image/format,png
[format_png 23]: https://img-blog.csdnimg.cn/img_convert/1934968e8f6bf4aa4b24527f022fbf23.webp?x-oss-process=image/format,png
[format_png 24]: https://img-blog.csdnimg.cn/img_convert/e0f0a8e2839cd619650c2c898f0d8f97.webp?x-oss-process=image/format,png
[format_png 25]: https://img-blog.csdnimg.cn/img_convert/30b9a501f766b5b1945526a146adeaeb.webp?x-oss-process=image/format,png
[format_png 26]: https://img-blog.csdnimg.cn/img_convert/593966c400b5af53bb47b51b826e26b7.webp?x-oss-process=image/format,png
[format_png 27]: https://img-blog.csdnimg.cn/img_convert/bb58edbc5d382fa3db147b27fbc0b303.webp?x-oss-process=image/format,png
[format_png 28]: https://img-blog.csdnimg.cn/img_convert/814c90c03dc06a24edd7aeda01997561.webp?x-oss-process=image/format,png
[format_png 29]: https://img-blog.csdnimg.cn/img_convert/6526dceefca66d8cdacb670bba7ba5a7.webp?x-oss-process=image/format,png
[format_png 30]: https://img-blog.csdnimg.cn/img_convert/a408b1d7035037f5e55412acd1afb79c.webp?x-oss-process=image/format,png
[format_png 31]: https://img-blog.csdnimg.cn/img_convert/16d36e24f31b658743f210d1828252ac.webp?x-oss-process=image/format,png