所有文章

https://www.cnblogs.com/lay2017/p/11478237.html

正文

在前面的几篇文章中,我们看到Environment创建、application配置文件的加载、ApplicationContext实例对象的创建、以及主类加载成为BeanDefinition。做了这么多的准备,终于到了核心的部分,也就是ioc容器的刷新。

这里,我们不免要再次回顾一下SpringAplication的run方法

public ConfigurableApplicationContext run(String... args) {
// 声明一个Context容器
ConfigurableApplicationContext context = null;
// 获取监听器
SpringApplicationRunListeners listeners = getRunListeners(args);
// 调用监听器的启动
listeners.starting(); try {
// 创建并配置Environment(这个过程会加载application配置文件)
ConfigurableEnvironment environment = prepareEnvironment(listeners, applicationArguments);
// 根据应用类型创建对应的Context容器
context = createApplicationContext(); // 刷新Context容器之前的准备
prepareContext(context, environment, listeners, applicationArguments, printedBanner);
// 刷新Context容器
refreshContext(context);
// 刷新Context容器之后处理
afterRefresh(context, applicationArguments); // Context容器refresh完毕发布
listeners.started(context); // 触发Context容器refresh完以后的执行
callRunners(context, applicationArguments);
} catch (Throwable ex) {} try {
// Context启动完毕,Runner运行完毕发布
listeners.running(context);
} catch (Throwable ex) {} return context;
}

run方法中,prepareContext和afterRefresh之间的refreshContext方法正是ioc容器刷新的入口方法。

ApplicationContext和BeanFactory

但是在阅读refreshContext方法之前,我们得先区分一下ApplicationContext和BeanFactory两者之间的关系。在之前的文章中,我们并没有把二者进行区分。比如,我们总是说"把Bean注册到ApplicationContext容器"。

在我们的理解中,容器应该是一个空间的概念,用于存放事物的东西。在spring中,存放的是Bean。而BeanFactory提供了这么一个空间用于存放Bean,所以BeanFactory才是Bean所在的主要容器,而不是我们一直说的ApplicationContext。

既然ApplicationContext不是容器,那它又是啥呢?我们称之为"上下文"。"上下文"的概念我们也许不见得那么熟,但是"场景","场所"这样的概念我们应该就比较熟悉了。比如说"拍摄场景","交易场所"等。它们的共同点都是事件发生的地方。所以ApplicationContext正是spring定义的应用程序的事件发生场所,也就是所谓的应用上下文。

上面,我了解了BeanFactory作为Bean容器,而ApplicationContext作为上下文。那么Bean容器和上下文之间是什么关系呢?我们可以看一个代码片段

// 通用的应用上下文实现
public class GenericApplicationContext extends AbstractApplicationContext implements BeanDefinitionRegistry {
// 默认BeanFactory的实现
private final DefaultListableBeanFactory beanFactory; // 省略
}

我们看到BeanFactory是被组合在ApplicationContext当中的,所以它们的其中一种关系就是组合关系。也就是说应用上下文中包含着Bean工厂。

接着,我们分别看看ApplicationContext的类图

我们看到ApplicationContext和BeanFactory还存在着继承关系,这意味着ApplicationContext可以对外被当做BeanFactory来使用,这也是为什么我们总是把ApplicationContext当做容器来看的主要原因,因为对外来看两者是一体的。

结合上面的组合关系,我们可以知道对内的话ApplicationContext的BeanFactory相关实现会由内部组合的BeanFactory的实现类来完成具体工作。

到这里,我们基本就明白了ApplicationContext和BeanFactory之间的关系有两种:组合、继承。

后面我们将称呼ApplicationContext为上下文,而BeanFactory为Bean容器,进行区分。

上下文组合Bean工厂

那么BeanFactory是什么时候被组合到ApplicationContext当中的呢?我们先看看ApplicationContext的实现类的类图

注意!springboot默认的servlet项目的ApplicationContext实现类是AnnotationCofnigServletWebServerApplicationContext,所以我们会以它作为实现类来看

我们自下而上,顺着继承链找到GenericApplicationContext我们就会看到之前出现过的代码片段

public class GenericApplicationContext extends AbstractApplicationContext implements BeanDefinitionRegistry {

    private final DefaultListableBeanFactory beanFactory;

    public GenericApplicationContext() {
this.beanFactory = new DefaultListableBeanFactory();
} // 省略
}

这里,在GenericApplicationContext的构造方法当中构建了一个DefaultListableBeanFactory的实例对象。DefaultListableBeanFactory也就是BeanFactory的默认实现,那么也就是说在构造ApplicationContext实例对象的时候创建并组合了一个BeanFactory的实例。

我们顺便也看看DefaultListableBeanFactory的继承关系吧

这个类图只保留了BeanFactory的东西,设计路线自BeanFactory到DefaultListableBeanFactory也很清晰。

refreshContext刷新过程

下面,我们将正式进行refreshContext方法的阅读。打开refreshContext方法

private void refreshContext(ConfigurableApplicationContext context) {
refresh(context);
if (this.registerShutdownHook) {
try {
context.registerShutdownHook();
} catch (AccessControlException ex) {
// Not allowed in some environments.
}
}
}

跟进refresh方法

protected void refresh(ApplicationContext applicationContext) {
Assert.isInstanceOf(AbstractApplicationContext.class, applicationContext);
((AbstractApplicationContext) applicationContext).refresh();
}

我们看到,这里调用的是AbstractApplicationContext的refresh方法,顺序AnnotationConfigServletWebServerApplicationContext的继承链向上可以找到AbstractApplicationContext。

我们继续跟进AbstractApplicationContext的refresh方法,refresh方法有点长

public void refresh() throws BeansException, IllegalStateException {
synchronized (this.startupShutdownMonitor) {
// 刷新前准备,设置flag、时间,初始化properties等
prepareRefresh(); // 获取ApplicationContext中组合的BeanFactory
ConfigurableListableBeanFactory beanFactory = obtainFreshBeanFactory(); // 设置类加载器,添加后置处理器等准备
prepareBeanFactory(beanFactory); try {
// 供子类实现的后置处理
postProcessBeanFactory(beanFactory); // 调用Bean工厂的后置处理器
invokeBeanFactoryPostProcessors(beanFactory); // 注册Bean的后置处理器
registerBeanPostProcessors(beanFactory); // 初始化消息源
initMessageSource(); // 初始化事件广播
initApplicationEventMulticaster(); // 供之类实现的,初始化特殊的Bean
onRefresh(); // 注册监听器
registerListeners(); // 实例化所有的(non-lazy-init)单例Bean
finishBeanFactoryInitialization(beanFactory); // 发布刷新完毕事件
finishRefresh();
} catch (BeansException ex) {
//
} finally {
//
}
}
}

上一篇文章中,我们提到了这么一个初始化过程:

annotation或者xml中Bean的配置 --> 内存中的BeanDefinition --> Bean

也就是实际的配置,转化成内存中的配置对象,再根据配置对象转化成具体的实例对象。说白了就是从元数据到实例的一个转化过程。

为什么会提及这么一个转化过程呢?因为我们的refresh过程主要包含的就是其中的一步,也就是从annotation或者xml的Bean配置 --> 内存中的BeanDefinition的过程。这个过程的实现在调用Bean工厂的后置处理器的时候完成,也就是invokeBeanFactoryPostProcessors方法

我们跟进invokeBeanFactoryPostProcessors方法

protected void invokeBeanFactoryPostProcessors(ConfigurableListableBeanFactory beanFactory) {
PostProcessorRegistrationDelegate.invokeBeanFactoryPostProcessors(beanFactory, getBeanFactoryPostProcessors());
//
}

这里先获取了所有后置处理器,然后调用处理。再跟进PostProcessorRegistrationDelegate的invokeBeanFactoryFactoryPostProcessors方法

该方法很长,我们删减掉大部分内容

public static void invokeBeanFactoryPostProcessors(
ConfigurableListableBeanFactory beanFactory,
List<BeanFactoryPostProcessor> beanFactoryPostProcessors
) {
//
if (beanFactory instanceof BeanDefinitionRegistry) {
//
while (reiterate) {
// 调用BeanDefinition注册的后置处理器
invokeBeanDefinitionRegistryPostProcessors(currentRegistryProcessors, registry);
//
}
//
} else {
//
}
//
}

可以看到,调用后置处理器的时候会调用到注册BeanDefinition的后置处理器。也就是从这里开始作为BeanDefinition的注册入口

跟进invokeBeanDefinitionRegistryPostProcessors

private static void invokeBeanDefinitionRegistryPostProcessors(
Collection<? extends BeanDefinitionRegistryPostProcessor> postProcessors,
BeanDefinitionRegistry registry
) {
for (BeanDefinitionRegistryPostProcessor postProcessor : postProcessors) {
postProcessor.postProcessBeanDefinitionRegistry(registry);
}
}

这里我们需要断点一下,看看有哪些后置处理器处理BeanDefinition注册

我们看到了ConfigurationClassPostProcessor也就是它完成BeanDefinition注册这项工作的

我们跟进ConfigurationClassPostProcessor的postProcessBeanDefinitionRegistry方法

public void postProcessBeanDefinitionRegistry(BeanDefinitionRegistry registry) {
// 省略
processConfigBeanDefinitions(registry);
}

继续跟进,我们看到processConfigBeanDefinitions方法挺长的,进行了大量的缩减

public void processConfigBeanDefinitions(BeanDefinitionRegistry registry) {
List<BeanDefinitionHolder> configCandidates = new ArrayList<>();
String[] candidateNames = registry.getBeanDefinitionNames(); for (String beanName : candidateNames) {
BeanDefinition beanDef = registry.getBeanDefinition(beanName);
if (ConfigurationClassUtils.isFullConfigurationClass(beanDef) ||
ConfigurationClassUtils.isLiteConfigurationClass(beanDef)) {
//
} else if (ConfigurationClassUtils.checkConfigurationClassCandidate(beanDef, this.metadataReaderFactory)) {
// 默认仅有主类被添加
configCandidates.add(new BeanDefinitionHolder(beanDef, beanName));
}
} // // 解析被 @Configuration 注解的类
ConfigurationClassParser parser = new ConfigurationClassParser(
this.metadataReaderFactory,
this.problemReporter,
this.environment,
this.resourceLoader,
this.componentScanBeanNameGenerator,
registry); Set<BeanDefinitionHolder> candidates = new LinkedHashSet<>(configCandidates);
//
do {
// 解析的核心方法
parser.parse(candidates);
parser.validate(); // candidates.clear();
//
} while (!candidates.isEmpty());
//
}

上一篇文章中,也就是在prepareContext方法的核心逻辑里,main方法所在的主类将会被作为BeanDefinition加载到BeanFactory当中。而在这里,该主类将被作为一个配置类被解析,解析器即ConfigurationClassParser。

我们跟进parse方法看看

public void parse(Set<BeanDefinitionHolder> configCandidates) {
for (BeanDefinitionHolder holder : configCandidates) {
BeanDefinition bd = holder.getBeanDefinition();
try {
if (bd instanceof AnnotatedBeanDefinition) {
// 主类的解析将从这里进入
parse(((AnnotatedBeanDefinition) bd).getMetadata(), holder.getBeanName());
} else if (bd instanceof AbstractBeanDefinition && ((AbstractBeanDefinition) bd).hasBeanClass()) {
parse(((AbstractBeanDefinition) bd).getBeanClass(), holder.getBeanName());
} else {
parse(bd.getBeanClassName(), holder.getBeanName());
}
} catch (BeanDefinitionStoreException ex) {}
catch (Throwable ex) {}
} this.deferredImportSelectorHandler.process();
}

继续跟进parse方法

protected final void parse(AnnotationMetadata metadata, String beanName) throws IOException {
processConfigurationClass(new ConfigurationClass(metadata, beanName));
}

可以看到主类作为配置类的解析过程将从processConfigurationClass这里开始

总结

到这里,ioc容器的refresh过程先做一个小结。我们知道了上下文和Bean容器是继承关系又是组合关系。refreshContext的核心就是为了加载BeanDefinition,而加载BeanDefinition将从main方法所在的主类开始,主类作为一个配置类将由ConfigurationClassParser解析器来完成解析的职责。下一篇文章,我们将会看到从主类中解析出BeanDefinition的主要逻辑。

springboot启动流程(七)ioc容器refresh过程(上篇)的更多相关文章

  1. springboot启动流程(八)ioc容器refresh过程(下篇)

    所有文章 https://www.cnblogs.com/lay2017/p/11478237.html 正文 上一篇文章,我们知道了解析过程将从解析main方法所在的主类开始.在文章的最后我们稍微看 ...

  2. springboot启动流程(目录)

    springboot出现有段时间了,不过却一直没有怎么去更多地了解它.一方面是工作的原因,另一方面是原来觉得是否有这个必要,但要持续做java似乎最终逃不开要去了解它的命运.于是考虑花一段时间去学习一 ...

  3. SpringBoot启动流程分析(四):IoC容器的初始化过程

    SpringBoot系列文章简介 SpringBoot源码阅读辅助篇: Spring IoC容器与应用上下文的设计与实现 SpringBoot启动流程源码分析: SpringBoot启动流程分析(一) ...

  4. SpringBoot启动流程分析(六):IoC容器依赖注入

    SpringBoot系列文章简介 SpringBoot源码阅读辅助篇: Spring IoC容器与应用上下文的设计与实现 SpringBoot启动流程源码分析: SpringBoot启动流程分析(一) ...

  5. SpringBoot启动流程分析(一):SpringApplication类初始化过程

    SpringBoot系列文章简介 SpringBoot源码阅读辅助篇: Spring IoC容器与应用上下文的设计与实现 SpringBoot启动流程源码分析: SpringBoot启动流程分析(一) ...

  6. SpringBoot启动流程分析(五):SpringBoot自动装配原理实现

    SpringBoot系列文章简介 SpringBoot源码阅读辅助篇: Spring IoC容器与应用上下文的设计与实现 SpringBoot启动流程源码分析: SpringBoot启动流程分析(一) ...

  7. SpringBoot启动流程分析(二):SpringApplication的run方法

    SpringBoot系列文章简介 SpringBoot源码阅读辅助篇: Spring IoC容器与应用上下文的设计与实现 SpringBoot启动流程源码分析: SpringBoot启动流程分析(一) ...

  8. SpringBoot启动流程分析(三):SpringApplication的run方法之prepareContext()方法

    SpringBoot系列文章简介 SpringBoot源码阅读辅助篇: Spring IoC容器与应用上下文的设计与实现 SpringBoot启动流程源码分析: SpringBoot启动流程分析(一) ...

  9. SpringBoot启动流程解析

    写在前面: 由于该系统是底层系统,以微服务形式对外暴露dubbo服务,所以本流程中SpringBoot不基于jetty或者tomcat等容器启动方式发布服务,而是以执行程序方式启动来发布(参考下图ke ...

随机推荐

  1. SQL语言Select经典语句

    -- 示例数据 Select * From Employee Select * From Department -- 返回工资最高的员工的信息 Select * From Employee where ...

  2. PAT 甲级 1043 Is It a Binary Search Tree (25 分)(链表建树前序后序遍历)*不会用链表建树 *看不懂题

    1043 Is It a Binary Search Tree (25 分)   A Binary Search Tree (BST) is recursively defined as a bina ...

  3. POPUP_GET_VALUES 金额字段不可编辑

    转自:https://blog.csdn.net/huanglin6/article/details/102733845 当在POPUP_GET_VALUES函数中参考的字段是个货币或者金额字段的话, ...

  4. 上交所跨市场ETF申购赎回实时回报

    申购赎回实时回报:1.二级市场过户记录(二级市场代码)2.沪市成分股过户记录(全部成分股)3.非沪市资金记录4.沪市资金记录5.ETF一级市场过户记录(一级市场代码)

  5. laravel容器类make方法解释

    容器类调用make方法时,如果没有已注册的key,那么会自动通过反射类实例化具体类 make /** * Resolve the given type from the container. * * ...

  6. Matlab批量获取子文件夹与文件名

    批量得到父文件夹下所有子文件夹的路径的MATLAB函数. function [SubFolders] = GetFolders(ParentFolder) %GetFolders % 函数功能为获取父 ...

  7. 数据结构与算法学习(二)——Master公式及其应用

    本篇文章涉及公式,由于博客园没有很好的支持,建议移步我的CSDN博客和简书进行阅读. 1. Master公式是什么? 我们在解决算法问题时,经常会用到递归.递归在较难理解的同时,其算法的复杂度也不是很 ...

  8. 机器学习笔记——k-近邻算法(一)(摘抄于《机器学习实战》)

    k-近邻算法 k-近邻算法(kNN),它的工作原理是:存在一个样本数 据集合,也称作训练样本集,并且样本集中每个数据都存在标签,即我们知道样本集中每一数据 与所属分类的对应关系.输入没有标签的新数据后 ...

  9. 分布式消息通信之RabbitMQ_Note

    目录 1. RabbitMQ 安装 2. RabbitMQ 应用场景,特性 3. 官网入门指引 4. RabbitMQ 工作模型 5. RabbitMQ 主要的几种交换机类型 6. Java API的 ...

  10. input文本框禁用历史选择

    这里常用的场景是日期控件使用时,下面这个就很难看了 在input中添加autocomplete="off"就可以了 <input type="text" ...