SpringCloud在使用RefreshScope刷新配置信息后,新的配置信息实例如何初始化?

原创
2020/09/02 14:35
阅读数 2.3K

背景

标题有点长,我在这里描述下背景

我们有一个配置类:

@Component("smsTemplateConfig")
@ConfigurationProperties(prefix = "zt.sms")
@Data
//注意如下注解
@RefreshScope
@Slf4j
public class SmsTemplateConfig {
    /**
     * 是否发送短信
     */
    private Boolean send;
    /**
     * 短信位数
     */
    private Integer msgCodeDigits;


    @PostConstruct
    private void initialize() {
        log.info("SmsTemplateConfig initialized -  send: {},msgCodeDigits: {}", send, msgCodeDigits);
    }
}

该配置类,会在如下类种被用到:

@Component
public class MsgUtils {

    @Autowired
    private SmsTemplateConfig config;

    public SmsTemplateConfig getConfig() {
        return config;
    }

}

该配置类是关于短信配置相关的,然后,我们在配置中心修改了这个配置信息,那么服务就可以通过SpringCloud的RefreshScope这个类来热加载配置信息,代码如下:

RefreshScope.refresh("smsTemplateConfig");

RefreshScope的原理是:会先摧毁(destory),名称为smsTemplateConfig这个实例,然后当smsTemplateConfig这个实例再被用到的时候再重新初始化。

那么,问题来了,MsgUtils 这个类是单例,在容器中只会初始化一次,容器不会再帮我们注入新的smsTemplateConfig实例,那么smsTemplateConfig被销毁之后,是如何重新初始化的呢?

解决

普及两个概念:

1.Spring中bean的生命周期可以用类Scope来标识,生命周期(Scope的子类)有Singleton,Prototype,Request,Session,SpringCloud又新增了Thread,Refresh这几种,其中Singleton和Prototype是单独的类,其它的都是Scope的子类 ;不同生命周期的Bean由各自对应的Scope来管理。

2.Spring对非Singleton的Scode都使用了代理机制。

基于上面两个概念, 我们SmsTemplateConfig这个类上面有@RefreshScope这个注解,这个注解表示这个类的Scope是Refresh,也就是说,我们每次调用smsTemplateConfig这个实例,其实调用的是它的代理类。

有了这个结论之后,我们就需要去看代理类中添加了哪些逻辑,具体过程太复杂,这里直接说结论:每次通过代理对象执行原始对象的方法时,我们肯定要获取到原始对象,这里,我们的原始对象smsTemplateConfig,它的生命周期是refresh,所以由RefreshScope管理,所以需要先获取自身对应的RefreshScope,然后通过RefreshScope获取对应实例,到了这一步,马上就要揭开谜底了,既然是由RefreshScope获取对应实例的,那么我就要看RefreshScope获取的逻辑就好了,这里也是直接说结论,RefreshScope类内部有一个缓存,缓存了所有的生命周期为refresh的实例,假如缓存没有命中,就会重新生成对应的实例,在前文中我们是不是摧毁了smsTemplateConfig的实例,那么在这里就会重新生成,也就是重新初始化了smsTemplateConfig实例。

 

展开阅读全文
加载中
点击引领话题📣 发布并加入讨论🔥
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部