Pre
接上文 Spring5源码 - 03 普通对象对应的BeanDefinition是如何存入DefaultListableBeanFactory#beanDefinitionMap 源码分析
refresh()
这里我们只粗略的看一下其中的逻辑，真的很复杂
@Override public void refresh() throws BeansException, IllegalStateException { synchronized (this.startupShutdownMonitor) { StartupStep contextRefresh = this.applicationStartup.start("spring.context.refresh"); // Prepare this context for refreshing. 1:准备刷新上下文环境 prepareRefresh(); // Tell the subclass to refresh the internal bean factory. 2:获取告诉子类初始化Bean工厂 ConfigurableListableBeanFactory beanFactory = obtainFreshBeanFactory(); // Prepare the bean factory for use in this context. 3:对bean工厂进行填充属性 prepareBeanFactory(beanFactory); try { // Allows post-processing of the bean factory in context subclasses. 第四:留给子类去实现该接口 postProcessBeanFactory(beanFactory); StartupStep beanPostProcess = this.applicationStartup.start("spring.context.beans.post-process"); // Invoke factory processors registered as beans in the context. 调用bean工厂的后置处理器. invokeBeanFactoryPostProcessors(beanFactory); // Register bean processors that intercept bean creation. 调用bean的后置处理器 registerBeanPostProcessors(beanFactory); beanPostProcess.end(); // Initialize message source for this context. 初始化国际化资源处理器. initMessageSource(); // Initialize event multicaster for this context. 创建事件多播器 initApplicationEventMulticaster(); // Initialize other special beans in specific context subclasses. 这个方法同样也是留给子类实现的 springboot也是从这个方法进行启动tomat的. onRefresh(); // Check for listener beans and register them. 把我们的事件监听器注册到多播器上 registerListeners(); // Instantiate all remaining (non-lazy-init) singletons. 实例化我们剩余的单实例bean. finishBeanFactoryInitialization(beanFactory); // Last step: publish corresponding event. 最后容器刷新 发布刷新事件(Spring cloud也是从这里启动的) finishRefresh(); } catch (BeansException ex) { if (logger.isWarnEnabled()) { logger.warn("Exception encountered during context initialization - " + "cancelling refresh attempt: " + ex); } // Destroy already created singletons to avoid dangling resources. destroyBeans(); // Reset 'active' flag. cancelRefresh(ex); // Propagate exception to caller. throw ex; } finally { // Reset common introspection caches in Spring's core, since we // might not ever need metadata for singleton beans anymore... resetCommonCaches(); contextRefresh.end(); } } }
Spring的设计
我们接着来看 spring 是在哪一个方法调用中完成扫描的 即什么时候初始化BeanDefinition, 并且把这个BeanDefinition放到bdMap集合中。
通过debug分析可以得出
invokeBeanFactoryPostProcessors(beanFactory);
主要工作
执行所有的需要被执行的BeanFactoryPostProcessor
1.1 执行Spring内置的BeanFactoryPostProcessor （完成Bean的扫描） 【其实就是ConfigurationClassPostProcessor】
1.2 执行开发人员提供的BeanFactoryPostProcessor
源码验证
再细说一下主要的设计思想
看方法名 invokeBeanFactoryPostProcessors 也能猜到 主要是执行 BeanFactoryPostProcessors
既然是 BeanFactoryPostProcessors , 那就说明有很多 BeanFactoryPostProcessor
BeanFactoryPostProcessor是个接口，spring实现了一部分，当然开发人员也可以实现BeanFactoryPostProcessor接口。
那Spring该如何决定这些接口实现类的先后顺序呢？ 这就是Spring IOC 核心的地方。
先说说Spring的几个比较核心的子类和实现类
主要干的两个活
- 执行直接实现了BeanFactoryPostProcessor
- 执行实现了BeanDefinitionRegistryPostProcessor
举个例子 ，假设我们有个自己的类 ，实现了 子类BeanDefinitionRegistryPostProcessor接口
ArtisanTest02 implements BeanDefinitionRegistryPostProcessor
那么你不仅要把BeanDefinitionRegistryPostProcessor的接口实现，还要实现其父类BeanFactoryPostProcessor接口的方法，那么在调用invokeBeanFactoryPostProcessors的时候 ，这两个方法都会被执行 。
假设还有一个类 ，ArtisanTest03 实现了 BeanFactoryPostProcessor 接口
ArtisanTest03 implements BeanFactoryPostProcessor
来运行看下效果
