记一次spring注解@Value不生效的深度排查

​上周遇到一个有意思的问题,拿出来分享一下。 问题可以简单地描述如下:在 springboot 中以

starter 的方式引入 dubbo ,但注册中心配置使用 javaConfig 的方式,先贴出配置代码

@Configurationpublic class DubboRegistryConfig {​    @Value("${dynamic.dubbo.registries.nacos.address:#{null}}")    private String nacosAddress;​    @Value("${dynamic.dubbo.registries.zk.address:#{null}}")    private String zkAddress;​    @Bean    public RegistryConfig nacosRegistry() {        RegistryConfig nacosConfig = new RegistryConfig();        nacosConfig.setAddress(nacosAddress);        nacosConfig.setProtocol("nacos");        return nacosConfig;    }​    @Bean    public RegistryConfig zkRegistry() {        RegistryConfig zkConfig = new RegistryConfig();        zkConfig.setAddress(zkAddress);        zkConfig.setProtocol("zookeeper");        return zkConfig;    }​    @Bean    public ConsumerConfig consumerConfig() {        ConsumerConfig consumerConfig = new ConsumerConfig();        List<RegistryConfig> registryConfigs = new ArrayList<>(2);        registryConfigs.add(nacosRegistry());        registryConfigs.add(zkRegistry());        consumerConfig.setRegistries(registryConfigs);        return consumerConfig;    }​    @Bean    public ProviderConfig providerConfig() {        ProviderConfig providerConfig = new ProviderConfig();        providerConfig.setRegistry(zkRegistry());        return providerConfig;    }​}复制代码

将这段代码打成jar包,在主工程中引入,启动类上使用 @Import 引入

@SpringBootApplication@Import(DubboRegistryConfig.class)public class Application {    public static void main(String[] args) {        SpringApplication application = new SpringApplication(Application.class);        application.run(args);    }}复制代码

当然,注册中心地址写在 application.properties 文件中。

运行一下,奇怪的事情发生了,方便起见,我把调试截图贴出来

记一次spring注解@Value不生效的深度排查

当运行到 consumerConfig 代码时,两个注册中心的地址并没有注入进来,这是怎么回事?下意识地看了下程序运行日志,发现了一条可疑日志

ConfigurationClassPostProcessor.enhanceConfigurationClasses()|Cannot enhance @Configuration bean definition 'com.lkxiaolou.registry.dynamic.config.DubboRegistryConfig' since its singleton instance has been created too early. The typical cause is a non-static @Bean method with a BeanDefinitionRegistryPostProcessor return type: Consider declaring such methods as 'static'. 复制代码

大概意思是,由于 DubboRegistryConfig  bean实例化太早,导致没有被 ConfigurationClassPostProcessor 增强。好像跟bean的生命周期有关,这个配置类中定义了三个bean,加上配置类自身也是一个bean,想办法看一下这四个bean的加载顺序是不是有助于问题的解决?于是,我在配置代码中输出一些调试信息

@Configurationpublic class DubboRegistryConfig {​    @Value("${dynamic.dubbo.registries.nacos.address:#{null}}")    private String nacosAddress;​    @Value("${dynamic.dubbo.registries.zk.address:#{null}}")    private String zkAddress;​    @PostConstruct    public void init() {        System.out.println("=== DubboRegistryConfig inited");    }​    @Bean    @DependsOn("dubboRegistryConfig")    public RegistryConfig nacosRegistry() {        System.out.println("=== nacosRegistry create");        RegistryConfig nacosConfig = new RegistryConfig();        nacosConfig.setAddress(nacosAddress);        nacosConfig.setProtocol("nacos");        return nacosConfig;    }​    @Bean    public RegistryConfig zkRegistry() {        System.out.println("=== zkRegistry create");        RegistryConfig zkConfig = new RegistryConfig();        zkConfig.setAddress(zkAddress);        zkConfig.setProtocol("zookeeper");        return zkConfig;    }​    @Bean    public ConsumerConfig consumerConfig() {        System.out.println("=== consumerConfig create");        ConsumerConfig consumerConfig = new ConsumerConfig();        List<RegistryConfig> registryConfigs = new ArrayList<>(2);        registryConfigs.add(nacosRegistry());        registryConfigs.add(zkRegistry());        consumerConfig.setRegistries(registryConfigs);        return consumerConfig;    }​    @Bean    public ProviderConfig providerConfig() {        System.out.println("=== providerConfig create");        ProviderConfig providerConfig = new ProviderConfig();        providerConfig.setRegistry(zkRegistry());        return providerConfig;    }}复制代码

最后只有三个bean正常输出了调试信息

=== consumerConfig create=== nacosRegistry create=== zkRegistry create复制代码

providerConfig 没有输出可以理解,因为程序挂掉了,但是为什么 DubboRegistryConfig 没有执行 @PostConstruct ?它的bean是存在的吗?还是没来得及初始化?试着给它注入个 ApplicationContext ,调试一把

记一次spring注解@Value不生效的深度排查

发现在 nacosRegistry 创建的时候,居然找不到 DubboRegistryConfig 的bean定义,难道是 @Import 使用姿势不对? 于是把 @Import 改成包扫描,再调试发现可以找 DubboRegistryConfig

的bean了,但是

@PostConstruct

依然不执行,属性依旧没有注入。

记一次spring注解@Value不生效的深度排查

先捋一捋,我们最初的问题是 @Configuration 无法注入 @Value ,通过 @Import 导入 @Configuration @Configuration 本身不是一个bean,自然@Value就无法装配属性,但当我们改成包扫描后,能获取到@Configuration本身的bean,但是属性依然没有注入 @PostConstruct 依然没有执行。 bean生成了,但 @Value @PostConstruct 注解没有生效,我们把焦点放到这两个注解上,这两个注解是怎么实现的?查询了一下资料, @PostConstruct 是依靠 InitDestroyAnnotationBeanPostProcessor 实现,@Value是依靠 AutowiredAnnotationBeanPostProcessor 实现,从名字上就能看出这两个类实现了 BeanPostProcesser BeanPostProcesser 提供了在bean执行初始化(init-method)前后插入hock的能力。也就是说, DubboRegistryConfig 的bean没有执行 BeanPostProcesser ,为了验证猜想,断点找出堆栈,顺藤摸瓜

记一次spring注解@Value不生效的深度排查

从堆栈中发现了是dubbo的 ReferenceBean 触发了 DubboRegistry 的bean的初始化

记一次spring注解@Value不生效的深度排查

那么为什么 ReferenceBean 初始化 DubboRegistryConfig 中的bean不会触发 BeanPostProcesser

呢?又是谁初始化
ReferenceBean

的?

接着调试,发现Spring容器初始化的时候初始化了

ServiceAnnotationBeanPostProcessor ,这是 dubbo-spring-boot-starter 提供的一个类,它实现了 BeanFactoryPostProcessor 接口的方法postProcessBeanDefinitionRegistry,可以在bean定义加载完成后,bean尚未初始化时对bean的定义进行修改。它和 BeanPostProcesser

的执行顺序是先调用
BeanFactoryPostProcessor ,再注册
BeanPostProcesser ,如果BeanFactoryPostProcessor中创建了bean,那么它就不会执行
BeanPostProcesser ,也就是
@Value

@PostConstruct

无法生效。

记一次spring注解@Value不生效的深度排查

那么问题归结于,为什么在 BeanFactoryPostProcessor 中会创建bean呢? 接着调试, ServiceAnnotationBeanPostProcessor 定义在 DubboAutoConfiguration ,并且需要注入一个 Environment

记一次spring注解@Value不生效的深度排查

通过调试发现问题就出在注入 Environment 这个过程。 注入 Envioment 需要先找到 Environment

这个类型的bean,调用
DefaultListableBeanFactory

.

doGetBeanNamesForType

记一次spring注解@Value不生效的深度排查

doGetBeanNamesForType 需要遍历所有bean定义,判断出需要的bean(并不需要初始化bean),但是在循环到dubbo的 ReferenceBean 时,发现它的 isFactoryBean 为true,此时会调用 AbstractBeanFactory . getTypeForFactoryBean 方法

记一次spring注解@Value不生效的深度排查

这个方法就会初始化bean了,这是为什么?

原来 ReferenceBean 实现了 FactoryBean 接口, FactoryBean 可以理解为生产bean的bean,可以根据复杂的情况生产不同的bean,再来看 ReferenceBean 其实很好理解,因为dubbo的reference是不同的调用代理,也就是不同的bean,用 ReferenceBean 来实现很好理解。 那为什么判断类型时 FactoryBean 产生的bean需要实例化呢?也好理解,如果不实例化是不知道 FactoryBean 产生的是什么bean,所以只有这种类型的bean会被提前初始化。 差不多到这里已经水落石出了,我们简单总结一下:

  1. @ Configuration 中无法注入@ Value 与@ PostConstruct 无法执行,我们查到是 Configuration 的bean已经初始化,但是注解失效;

  2. 调研了一下@Value与 @ PostConstruct 的原理是 BeanPostProcesser

  3. 根据堆栈找到 dubbo-spring-starter ServiceAnnotationBeanPostProcessor 的实现是 BeanFactoryPostProcesser ,它的执行要在BeanPostProcesser注入之前;

  4. 实例化 ServiceAnnotationBeanPostProcessor 时注入 Environment ,需要扫描所有bean的定义;

  5. dubbo的 ReferenceBean 是基于 FactoryBean 实现,而4中的扫描对于普通bean不会触发实例化,但 FactoryBean 产生的bean会被实例化;

  6. 于是ReferenceBean实例化时触发 DubboRegistryConfig 中bean的实例化,进而触发

    DubboRegistryConfig 实例化,而这一切发生在 BeanPostProcesser 生效之前。

问题找到了,解决就很简单,这种情况下不要使用这两种注解,可以实现 InitializingBean

afterPropertiesSet 来代替 @ Postconstruct ,实现 EnvironmentAwaresetEnvironment

接口来代替
@

Value

获取配置。

最后,文章中还有几处没有详细写出来,大家伙可以试着分析分析,一是为什么@Import导入的jar包中的@Configuration不是一个bean?另一个是文章中第一次执行程序输出日志有什么意义?

—–

欢迎扫码关注我的公众号“捉虫大师”,一个找bug小能手,专注后端,bug分析,源码分析。

记一次spring注解@Value不生效的深度排查

原文 

https://juejin.im/post/5e91947351882573954eb429

本站部分文章源于互联网,本着传播知识、有益学习和研究的目的进行的转载,为网友免费提供。如有著作权人或出版方提出异议,本站将立即删除。如果您对文章转载有任何疑问请告之我们,以便我们及时纠正。

PS:推荐一个微信公众号: askHarries 或者qq群:474807195,里面会分享一些资深架构师录制的视频录像:有Spring,MyBatis,Netty源码分析,高并发、高性能、分布式、微服务架构的原理,JVM性能优化这些成为架构师必备的知识体系。还能领取免费的学习资源,目前受益良多

转载请注明原文出处:Harries Blog™ » 记一次spring注解@Value不生效的深度排查

赞 (0)
分享到:更多 ()

评论 0

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址