- 服务启动的时候,SpringApplication内部做了什么?
- 创建上下文的时候是使用的哪一种ApplicationContext?
- Bean 是在哪个步骤定义的,BeanDefinition怎么排序的?
- Bean 是在哪个步骤创建和初始化的?
- 监听器有什么作用,都发布了哪些事件?
本篇文章主要介绍Bean是什么时候定义的,及Bean是如何创建的。
application.yml
client:
id: 1
server: localhost
MyClientAutoConfiguration
@Configuration
@EnableConfigurationProperties(ClientProperties.class)
@ConditionalOnProperty(prefix = "client", name = "enable", havingValue = "true")
public class MyClientAutoConfiguration {
private ClientProperties properties;
@Autowired
public MyClientAutoConfiguration(ClientProperties properties) {
this.properties = properties;
}
@Bean
public MyClient client1() {
return new MyClient(1);
}
@Configuration
@ConditionalOnProperty(name = "client.valid", havingValue = "true", matchIfMissing = true)
static class ClientConfiger {
@Bean
public MyClient client2() {
return new MyClient(2);
}
@Configuration
static class MyClientConfiger {
private final MyClient client;
@Autowired
public MyClientConfiger(MyClient client) {
this.client = client;
}
}
}
}
ConditionalBootstrap
@SpringBootApplication
public class ConditionalBootStrap {
public static void main(String[] args) {
SpringApplication.run(ConditionalBootStrap.class, args);
}
}
当服务启动的时候,大家可以先猜测一下,哪些Bean会被注册(registerBeanDefinition)?
让我们直接达到 SpringApplication.run 中的 refreshContext 方法,看看里面做了什么?
@Override
public void refresh() throws BeansException, IllegalStateException {
...
try {
...
// Invoke factory processors registered as beans in the context.
invokeBeanFactoryPostProcessors(beanFactory);
...
// Instantiate all remaining (non-lazy-init) singletons.
finishBeanFactoryInitialization(beanFactory);
}
从源码中我们看看这两个方法主要是完成什么工作的。
Instantiate and invoke all registered BeanFactoryPostProcessor beans, respecting explicit order if given. Must be called before singleton instantiation
这个方法主要完成BeanDefinition的工作:
- 哪些Class 实现了 registerBeanDefinition?
- BeanDefinitions 的顺序是什么样的?
提示:到refreshContext这一步之前,有些内置的类和 primarySource(即 ConditionalBootStrap)已经放到了BeanDefinitionMap中
哪些Class 实现了 registerBeanDefinition?
通过ConfigurationClassParser#parse 解析上面的configCandidates:
到这一步时,可以猜一下上面实例中哪些类是有效的
这里你有没有疑问:
问:为什么MyClientAutoConfiguration类是无效的?
答:因为@ConditionalOnProperty(prefix = "client", name = "enable", havingValue = "true") 不满足条件,yml中没有 client.enable=true,所以 ConditionEvaluator#shouldSkip=true,就被跳过了。
问:为什么内部类 MyClientConfiger 和 ClientConfiger是有效的?
答:因为这两个类都是 @Configuration Class ,而且 ConditionEvaluator#shouldSkip=false ;@ConditionalOnProperty(matchIfMissing = true) 中 matchIfMissing=true的意思是如果没有找到匹配的也放行。
所谓BeanMethod 就是标有@Bean的方法
上面实例中标有@Bean 的方法有:
MyClientAutoConfiguration#client1 方法 和 MyClientAutoConfiguration$ClientConfiger#client2 方法,但是因为MyClientAutoConfiguration类不符合条件,所以client1 bean method也是无效的,到这里获取到的 BeanMethod 只有client2
将此BeanMethod进行注册,即
registry.registerBeanDefinition(beanName, beanDefToRegister)。
到目前为止在此过程中注册了3个BeanDefinition, 即MyClientConfiger 和 ClientConfiger ,及client2,那么MyClientConfiger 和 ClientConfiger的顺序是怎么控制的?
在上面步骤中我们说了,获取basePackages下的所有类(getResources),那么Class的顺序就是在getResources 过程中改变:
protected File[] listDirectory(File dir) {
File[] files = dir.listFiles();
if (files == null) {
if (logger.isInfoEnabled()) {
logger.info("Could not retrieve contents of directory [" + dir.getAbsolutePath() + "]");
}
return new File[0];
}
Arrays.sort(files, Comparator.comparing(File::getName));
return files;
}
从上面源码中我们可以看到,如果是文件,那么是根据文件名进行排序的,排序后变成
那么如果是Jar文件呢,大家可以看下源码,是根据JarFile解压之后的顺序。
此方法主要完成BeanDefinition -> Bean的过程。
这里或按照顺序依次遍历之前的 BeanDefinitions,然后进行 getBean -> createBean -> initialize ,但是有个地方需要注意就是当一个Bean创建/初始化过程中如果需要/依赖其他的Bean,且这个依赖的Bean 还没有创建的时候,则优先会创建这个Bean(doResolveDependency),比如:
@Autowired
public MyClientConfiger(MyClient client) {
this.client = client;
}
MyClientConfiger 在创建Bean初始化过程中,发现构造函数中需要依赖 MyClient 类型的Bean ,此时就会优先创建MyClient Bean ,即beanName=client2,如果没有找到这个BeanDefinition,则此时就会报错 throw new
NoSuchBeanDefinitionException 。
好了,Bean定义和创建的过程已经讲完了,下面我抛一个问题给大家,假如我把 client.enable=true 配置加上会发生什么?
client:
id: 1
server: localhost
enable: true