Spring5源码 - 04 invokeBeanFactoryPostProcessors 源码解读

---

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.   
			prepareRefresh();

			// Tell the subclass to refresh the internal bean factory.
			ConfigurableListableBeanFactory beanFactory = obtainFreshBeanFactory();

			// Prepare the bean factory for use in this context.
			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.
				invokeBeanFactoryPostProcessors(beanFactory);

				// Register bean processors that intercept bean creation.
				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.
				onRefresh();

				// Check for listener beans and register them.
				registerListeners();

				// Instantiate all remaining (non-lazy-init) singletons.
				finishBeanFactoryInitialization(beanFactory);

				// Last step: publish corresponding event.
				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的几个比较核心的子类和实现类

主要干的两个活

1. 执行直接实现了BeanFactoryPostProcessor
2. 执行实现了BeanDefinitionRegistryPostProcessor

举个例子 ，假设我们有个自己的类 ，实现了 子类BeanDefinitionRegistryPostProcessor接口

ArtisanTest02 implements BeanDefinitionRegistryPostProcessor

那么你不仅要把BeanDefinitionRegistryPostProcessor的接口实现，还要实现其父类BeanFactoryPostProcessor接口的方法，那么在调用invokeBeanFactoryPostProcessors的时候 ，这两个方法都会被执行 。

假设还有一个类 ，ArtisanTest03 实现了 BeanFactoryPostProcessor 接口

 ArtisanTest03  implements BeanFactoryPostProcessor 

来运行看下效果

---

源码解读