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

妖狐艹你老母 2023-09-27 23:44 25阅读 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/3156cab23c53643388f8fcc513ee1b5e.webp?x-oss-process=image/format,png
[format_png 1]: https://img-blog.csdnimg.cn/img_convert/4ed037697bc8942e6fa0708809ab60a6.webp?x-oss-process=image/format,png
[format_png 2]: https://img-blog.csdnimg.cn/img_convert/43fe23c2be24273acb51a2351e8866e3.webp?x-oss-process=image/format,png
[format_png 3]: https://img-blog.csdnimg.cn/img_convert/d7c415027184e471f5726551caab82f5.webp?x-oss-process=image/format,png
[format_png 4]: https://img-blog.csdnimg.cn/img_convert/d03ec37a6ed840076c0e6ac0bc4c1808.webp?x-oss-process=image/format,png
[format_png 5]: https://img-blog.csdnimg.cn/img_convert/2e135c53ed6a3209775dc5812d6a1650.webp?x-oss-process=image/format,png
[format_png 6]: https://img-blog.csdnimg.cn/img_convert/f640cfb91cbc2980d2f547402221ba40.webp?x-oss-process=image/format,png
[format_png 7]: https://img-blog.csdnimg.cn/img_convert/1fbc5f598954847621557ecb6aeafe42.webp?x-oss-process=image/format,png
[format_png 8]: https://img-blog.csdnimg.cn/img_convert/0c76ff5fee9419889d44220a0b0bcf7f.webp?x-oss-process=image/format,png
[format_png 9]: https://img-blog.csdnimg.cn/img_convert/694af1ebb6ee2be302b8d2b06a4cd39b.webp?x-oss-process=image/format,png
[format_png 10]: https://img-blog.csdnimg.cn/img_convert/ab7a3a6d9de51370b71aded4617c009d.webp?x-oss-process=image/format,png
[format_png 11]: https://img-blog.csdnimg.cn/img_convert/acb473dd87a434b3aa1120be24ed990d.webp?x-oss-process=image/format,png
[format_png 12]: https://img-blog.csdnimg.cn/img_convert/8ec91621a88add4c6793d40b5e31e260.webp?x-oss-process=image/format,png
[format_png 13]: https://img-blog.csdnimg.cn/img_convert/c1a1279c5c8e04d721a061de54c04693.webp?x-oss-process=image/format,png
[format_png 14]: https://img-blog.csdnimg.cn/img_convert/a4fc552fe64456f022ee229c922049c7.webp?x-oss-process=image/format,png
[format_png 15]: https://img-blog.csdnimg.cn/img_convert/d85140e859e7dee1fbdc81812e960508.webp?x-oss-process=image/format,png
[format_png 16]: https://img-blog.csdnimg.cn/img_convert/6ddae7548792d601b50e6b2252440cf0.webp?x-oss-process=image/format,png
[format_png 17]: https://img-blog.csdnimg.cn/img_convert/1ce3b8fd56af90e41f7abf06a31d18f4.webp?x-oss-process=image/format,png
[format_png 18]: https://img-blog.csdnimg.cn/img_convert/5bf158ef8d497872c2d707ebe28be72f.webp?x-oss-process=image/format,png
[format_png 19]: https://img-blog.csdnimg.cn/img_convert/090e72a13d7d2bb91eb5bddeccec040a.webp?x-oss-process=image/format,png
[format_png 20]: https://img-blog.csdnimg.cn/img_convert/82b1dbe40083f782feb9ffc3343bedf6.webp?x-oss-process=image/format,png
[format_png 21]: https://img-blog.csdnimg.cn/img_convert/6f7afc16a0137a8b738bc67e629e1163.webp?x-oss-process=image/format,png
[format_png 22]: https://img-blog.csdnimg.cn/img_convert/05a432aada9c6a78bcb1f681c02a4cab.webp?x-oss-process=image/format,png
[format_png 23]: https://img-blog.csdnimg.cn/img_convert/239851b65e2810c28b271ef4e89a43bc.webp?x-oss-process=image/format,png
[format_png 24]: https://img-blog.csdnimg.cn/img_convert/61bce1b7b6ed9b70077426d46b65b8d7.webp?x-oss-process=image/format,png
[format_png 25]: https://img-blog.csdnimg.cn/img_convert/3afeaa6f03a68e1d2cd6e53ff09b76d9.webp?x-oss-process=image/format,png
[format_png 26]: https://img-blog.csdnimg.cn/img_convert/254ed9092a62559d2bdabfea55b9be5d.webp?x-oss-process=image/format,png
[format_png 27]: https://img-blog.csdnimg.cn/img_convert/d85a8c093bba8ff3a69f38fe96228c8c.webp?x-oss-process=image/format,png
[format_png 28]: https://img-blog.csdnimg.cn/img_convert/7837d07ebf453041f26b8db96fe8ef04.webp?x-oss-process=image/format,png
[format_png 29]: https://img-blog.csdnimg.cn/img_convert/326218570dbb2c1b7eb49b7c60f4a944.webp?x-oss-process=image/format,png
[format_png 30]: https://img-blog.csdnimg.cn/img_convert/57a219506d7232c840dc70bb3d146643.webp?x-oss-process=image/format,png
[format_png 31]: https://img-blog.csdnimg.cn/img_convert/f1a32a8585896e924ccd2280a90f908d.webp?x-oss-process=image/format,png