前言
了解完 Bean 完整的生命周期,现在来研究 bean 完整生命周期的 BeanDefinition 阶段了,这一阶段主要发生了以下几件事情:
- 加载配置文件、配置类
- 解析配置文件、配置类并封装为 BeanDefinition
- 编程式注入额外的 BeanDefinition
- 执行 BeanDefinition 的后置处理器
加载xml配置文件
public static void main(String[] args) throws Exception {
ClassPathXmlApplicationContext ctx = new ClassPathXmlApplicationContext();
ctx.setConfigLocation("lifecycle/bean-source.xml");
}
保存配置文件路径
这里 xml 配置文件的加载会使用 ClassPathXmlApplicationContext
的 setConfigLocation
方法,可以发现这个方法在 AbstractRefreshableConfigApplicationContext
中,只给 configLocations
设置了配置文件的路径存放而已。
public void setConfigLocation(String location) {
// 切分配置文件路径
setConfigLocations(StringUtils.tokenizeToStringArray(location, CONFIG_LOCATION_DELIMITERS));
}
public void setConfigLocations(@Nullable String... locations) {
if (locations != null) {
Assert.noNullElements(locations, "Config locations must not be null");
this.configLocations = new String[locations.length];
for (int i = 0; i < locations.length; i++) {
// 切分的配置文件路径存入ApplicationContext中
this.configLocations[i] = resolvePath(locations[i]).trim();
}
}
else {
this.configLocations = null;
}
}
加载配置文件并解析
ApplicationContext 的 refresh 方法后,会开始刷新(初始化)IOC 容器,这里面有 13 个步骤
public void refresh() throws BeansException, IllegalStateException {
synchronized (this.startupShutdownMonitor) {
prepareRefresh();
// 2. 初始化BeanFactory
ConfigurableListableBeanFactory beanFactory = obtainFreshBeanFactory();
prepareBeanFactory(beanFactory);
// ......
}
}
这里的第二步 obtainFreshBeanFactory()
方法,就是加载配置文件并解析的动作
protected ConfigurableListableBeanFactory obtainFreshBeanFactory() {
refreshBeanFactory();
return getBeanFactory();
}
这个方法只有两个动作,:刷新 BeanFactory,然后再获取它。刷新的动作中包含配置文件的加载和解析
refreshBeanFactory() 方法是 AbstractApplicationContext
定义的抽象方法,很明显这里又是模板方法模式的体现了。由于当前我们正在研究的是基于 xml 配置文件的 pplicationContext
,所以要进入 AbstractRefreshableApplicationContext
中:
protected final void refreshBeanFactory() throws BeansException {
// 如果存在 BeanFactory 则先销毁
if (hasBeanFactory()) {
// 销毁 BeanFactory 中的所有 Bean
destroyBeans();
// 清空 BeanFactory
closeBeanFactory();
}
try {
// 创建 BeanFactory
DefaultListableBeanFactory beanFactory = createBeanFactory();
// 设置序列化 ID
beanFactory.setSerializationId(getId());
customizeBeanFactory(beanFactory);
// 加载配置文件
loadBeanDefinitions(beanFactory);
this.beanFactory = beanFactory;
}
catch (IOException ex) {
throw new ApplicationContextException("I/O error parsing bean definition source for " + getDisplayName(), ex);
}
}
通过看源码的大体流程可以了解到:基于 xml 配置文件的 ApplicationContext
可以反复刷新加载 IOC 容器,所以此处有已经存在的判断:如果当前 ApplicationContext
中组合的 BeanFactory 已经存在,则销毁原来的 BeanFactory ,并重新创建。
这里面加载配置文件的动作是 loadBeanDefinitions
loadBeanDefinitions
loadBeanDefinitions 又是一个抽象方法,在 AbstractXmlApplicationContext
中可以找到对应的实现:
protected void loadBeanDefinitions(DefaultListableBeanFactory beanFactory) throws BeansException, IOException {
// xml配置文件由XmlBeanDefinitionReader解析
XmlBeanDefinitionReader beanDefinitionReader = new XmlBeanDefinitionReader(beanFactory);
// 配置上下文环境、资源加载器等
beanDefinitionReader.setEnvironment(this.getEnvironment());
beanDefinitionReader.setResourceLoader(this);
beanDefinitionReader.setEntityResolver(new ResourceEntityResolver(this));
// 初始化BeanDefinitionReader,后加载BeanDefinition
initBeanDefinitionReader(beanDefinitionReader);
// 使用xml解析器 解析xml配置文件
loadBeanDefinitions(beanDefinitionReader);
}
这里创建了一个 XmlBeanDefinitionReader
,它就是加载和解析 xml 配置文件的核心 API。它把这个 XmlBeanDefinitionReader 作为参数传入重载的 loadBeanDefinitions 方法:
protected void loadBeanDefinitions(XmlBeanDefinitionReader reader) throws BeansException, IOException {
Resource[] configResources = getConfigResources();
if (configResources != null) {
reader.loadBeanDefinitions(configResources);
}
String[] configLocations = getConfigLocations();
if (configLocations != null) {
// 【1.4】加载配置文件资源路径的xml配置文件
reader.loadBeanDefinitions(configLocations);
}
}
此处逻辑分为两个部分:一个是处理已经加载好的现成的 Resource;一个是处理指定好的配置文件资源路径。
XmlBeanDefinitionReader加载配置文件
public int loadBeanDefinitions(String... locations) throws BeanDefinitionStoreException {
// assert ......
int count = 0;
for (String location : locations) {
count += loadBeanDefinitions(location);
}
return count;
}
发现它传入的是一组配置文件,那自然就会循环一个个的加载。循环自然不是重点,我们进入内部的 loadBeanDefinitions(location) 中:
public int loadBeanDefinitions(String location) throws BeanDefinitionStoreException {
return loadBeanDefinitions(location, null);
}
public int loadBeanDefinitions(String location, @Nullable Set<Resource> actualResources) throws BeanDefinitionStoreException {
ResourceLoader resourceLoader = getResourceLoader();
if (resourceLoader == null) {
// throw ex ......
}
if (resourceLoader instanceof ResourcePatternResolver) {
try {
// 根据传入的路径规则,匹配所有符合的xml配置文件
Resource[] resources = ((ResourcePatternResolver) resourceLoader).getResources(location);
int count = loadBeanDefinitions(resources);
if (actualResources != null) {
Collections.addAll(actualResources, resources);
}
// logger ......
return count;
} // catch ......
}
else {
// 每次只能解析一个xml配置文件
Resource resource = resourceLoader.getResource(location);
// 【解析】
int count = loadBeanDefinitions(resource);
if (actualResources != null) {
actualResources.add(resource);
}
// logger ......
return count;
}
}
可以发现这里的核心逻辑只有两个动作:1)根据传入的资源路径,获取 xml 配置文件;2)解析xml配置文件。其它的逻辑都是保证程序正常执行。
核心实现方法 loadBeanDefinitions
:
public int loadBeanDefinitions(Resource resource) throws BeanDefinitionStoreException {
return loadBeanDefinitions(new EncodedResource(resource));
}
这一步给原有的 xml 配置文件的 Resource 封装包装了一层编码,继续往下看
public int loadBeanDefinitions(EncodedResource encodedResource) throws BeanDefinitionStoreException {
// assert logger ......
Set<EncodedResource> currentResources = this.resourcesCurrentlyBeingLoaded.get();
if (!currentResources.add(encodedResource)) {
// throw ex ......
}
try (InputStream inputStream = encodedResource.getResource().getInputStream()) {
InputSource inputSource = new InputSource(inputStream);
if (encodedResource.getEncoding() != null) {
inputSource.setEncoding(encodedResource.getEncoding());
}
// 【真正干活的】
return doLoadBeanDefinitions(inputSource, encodedResource.getResource());
} // catch ......
finally {
currentResources.remove(encodedResource);
if (currentResources.isEmpty()) {
this.resourcesCurrentlyBeingLoaded.remove();
}
}
}
这个方法中存在有do开头的方法 doLoadBeanDefinitions
,它才是真正实现解析的
doLoadBeanDefinitions - 读取配置文件
protected int doLoadBeanDefinitions(InputSource inputSource, Resource resource)
throws BeanDefinitionStoreException {
try {
Document doc = doLoadDocument(inputSource, resource);
int count = registerBeanDefinitions(doc, resource);
// logger ......
return count;
} // catch ......
}
doLoadDocument 这很明显是解析文档的(ps:这是看不懂的,不要去强行看;会打击自信心)
registerBeanDefinitions ,这才是我们最关心的!
//注册包含在给定DOM文档中的bean定义。由{@code loadBeanDefinitions}调用。创建解析器类的新实例并调用
public int registerBeanDefinitions(Document doc, Resource resource) throws BeanDefinitionStoreException {
BeanDefinitionDocumentReader documentReader = createBeanDefinitionDocumentReader();
int countBefore = getRegistry().getBeanDefinitionCount();
// 【解析】
documentReader.registerBeanDefinitions(doc, createReaderContext(resource));
return getRegistry().getBeanDefinitionCount() - countBefore;
}
此处构造了一个 DefaultBeanDefinitionDocumentReader ,然后调用它的 registerBeanDefinitions 方法(这是 DefaultBeanDefinitionDocumentReader
的方法):
public void registerBeanDefinitions(Document doc, XmlReaderContext readerContext) {
this.readerContext = readerContext;
doRegisterBeanDefinitions(doc.getDocumentElement());
}
可以发现 spring 传统套路 xxx 方法最终调 doXxx 方法干活:
protected void doRegisterBeanDefinitions(Element root) {
BeanDefinitionParserDelegate parent = this.delegate;
this.delegate = createDelegate(getReaderContext(), root, parent);
if (this.delegate.isDefaultNamespace(root)) {
// 取<beans>上的profile属性
String profileSpec = root.getAttribute(PROFILE_ATTRIBUTE);
if (StringUtils.hasText(profileSpec)) {
String[] specifiedProfiles = StringUtils.tokenizeToStringArray(
profileSpec, BeanDefinitionParserDelegate.MULTI_VALUE_ATTRIBUTE_DELIMITERS);
if (!getReaderContext().getEnvironment().acceptsProfiles(specifiedProfiles)) {
// logger ......
return;
}
}
}
preProcessXml(root);
// 【解析xml】
parseBeanDefinitions(root, this.delegate);
postProcessXml(root);
this.delegate = parent;
}
上面这段源码首先会把 xml 配置文件中声明的 profile 取出来,并根据 Environment 中配置好的 profile 觉得是否继续解析(profile的过滤)。
接下来就是解析 xml 的动作了,在这里有一个预处理和后处理动作,这两个动作都没有默认实现,只适合模板方法;所以我们只需要看 parseBeanDefinitions 就可以。
parseBeanDefinitions - 解析xml
protected void parseBeanDefinitions(Element root, BeanDefinitionParserDelegate delegate) {
if (delegate.isDefaultNamespace(root)) {
NodeList nl = root.getChildNodes();
for (int i = 0; i < nl.getLength(); i++) {
Node node = nl.item(i);
if (node instanceof Element) {
Element ele = (Element) node;
// 解析<beans>中的元素
if (delegate.isDefaultNamespace(ele)) {
parseDefaultElement(ele, delegate);
}
else {
// 解析其它命名空间中的元素
delegate.parseCustomElement(ele);
}
}
}
}
else {
delegate.parseCustomElement(root);
}
}
spring是如何解析 xml 的我们不要关心,但是如何从解析完的xml中获取关键信息,以及如何封装成 BeanDefinition ,这才是我们重点关心的
源码中可以看到,每次循环出来的 Node 都会尝试着转成 Element 去解析,而解析的动作主要是 parseDefaultElement ,它会解析 <beans>
标签下的 xml 元素。马上就要水落石出了,我们点进去看:
private void parseDefaultElement(Element ele, BeanDefinitionParserDelegate delegate) {
if (delegate.nodeNameEquals(ele, IMPORT_ELEMENT)) {
importBeanDefinitionResource(ele);
}
else if (delegate.nodeNameEquals(ele, ALIAS_ELEMENT)) {
processAliasRegistration(ele);
}
else if (delegate.nodeNameEquals(ele, BEAN_ELEMENT)) {
processBeanDefinition(ele, delegate);
}
else if (delegate.nodeNameEquals(ele, NESTED_BEANS_ELEMENT)) {
// recurse
doRegisterBeanDefinitions(ele);
}
}
终于看到真实的面貌了!!!这里它会解析 <import>
标签、<alias>
标签、<bean>
标签,以及递归解析嵌套的 <beans>
标签!
processBeanDefinition - 解析 <bean>
标签
既然我们还是在研究 BeanDefinition ,那我们就研究 processBeanDefinition 方法啦,翻开源码,可以发现逻辑还是比较简单的:
protected void processBeanDefinition(Element ele, BeanDefinitionParserDelegate delegate) {
// 解析 xml 元素为 BeanDefinition
BeanDefinitionHolder bdHolder = delegate.parseBeanDefinitionElement(ele);
if (bdHolder != null) {
// 解析<bean>中嵌套的自定义标签
bdHolder = delegate.decorateBeanDefinitionIfRequired(ele, bdHolder);
try {
// BeanDefinition 注册到 BeanDefinitionRegistry
BeanDefinitionReaderUtils.registerBeanDefinition(bdHolder, getReaderContext().getRegistry());
}
catch (BeanDefinitionStoreException ex) {
getReaderContext().error("Failed to register bean definition with name '" +
bdHolder.getBeanName() + "'", ele, ex);
}
// Send registration event.
getReaderContext().fireComponentRegistered(new BeanComponentDefinition(bdHolder));
}
}
可以发现整合动作一气呵成,其中第一个步骤会把 xml 元素封装成 BeanDefinitionHolder
;从名字上就能知道,它内部肯定组合了一个 BeanDefinition 。
进入 parseBeanDefinitionElement() 方法看看如何将 xml 元素封装为 BeanDefinitionHolder
的
public BeanDefinitionHolder parseBeanDefinitionElement(Element ele) {
return parseBeanDefinitionElement(ele, null);
}
public BeanDefinitionHolder parseBeanDefinitionElement(Element ele, @Nullable BeanDefinition containingBean) {
// 取出bean的id
String id = ele.getAttribute(ID_ATTRIBUTE);
// 取出bean的name
String nameAttr = ele.getAttribute(NAME_ATTRIBUTE);
// 取出bean的alias
List<String> aliases = new ArrayList<>();
if (StringUtils.hasLength(nameAttr)) {
String[] nameArr = StringUtils.tokenizeToStringArray(nameAttr, MULTI_VALUE_ATTRIBUTE_DELIMITERS);
aliases.addAll(Arrays.asList(nameArr));
}
// 如果没有给bean赋name,则第一个alias视为name
String beanName = id;
if (!StringUtils.hasText(beanName) && !aliases.isEmpty()) {
beanName = aliases.remove(0);
// logger ......
}
// 检查bean的name是否有重复
if (containingBean == null) {
checkNameUniqueness(beanName, aliases, ele);
}
// 解析其余的bean标签元素属性
AbstractBeanDefinition beanDefinition = parseBeanDefinitionElement(ele, beanName, containingBean);
if (beanDefinition != null) {
// 如果没有给bean赋name,且没有alias,则生成默认的name
if (!StringUtils.hasText(beanName)) {
try {
if (containingBean != null) {
beanName = BeanDefinitionReaderUtils.generateBeanName(
beanDefinition, this.readerContext.getRegistry(), true);
} else {
beanName = this.readerContext.generateBeanName(beanDefinition);
String beanClassName = beanDefinition.getBeanClassName();
if (beanClassName != null &&
beanName.startsWith(beanClassName) && beanName.length() > beanClassName.length() &&
!this.readerContext.getRegistry().isBeanNameInUse(beanClassName)) {
aliases.add(beanClassName);
}
}
// logger ......
} // catch ......
}
String[] aliasesArray = StringUtils.toStringArray(aliases);
return new BeanDefinitionHolder(beanDefinition, beanName, aliasesArray);
}
return null;
}
在此方法中会解析<bean>
标签中的 id 和 name,具体的 class、scope、lazy-init 都在 parseBeanDefinitionElement
方法中处理
public AbstractBeanDefinition parseBeanDefinitionElement(
Element ele, String beanName, @Nullable BeanDefinition containingBean) {
this.parseState.push(new BeanEntry(beanName));
// 解析class的全限定名
String className = null;
if (ele.hasAttribute(CLASS_ATTRIBUTE)) {
className = ele.getAttribute(CLASS_ATTRIBUTE).trim();
}
// 解析parent的definition名称
String parent = null;
if (ele.hasAttribute(PARENT_ATTRIBUTE)) {
parent = ele.getAttribute(PARENT_ATTRIBUTE);
}
try {
// 构造BeanDefinition
AbstractBeanDefinition bd = createBeanDefinition(className, parent);
// 解析其余的<bean>标签属性
parseBeanDefinitionAttributes(ele, beanName, containingBean, bd);
bd.setDescription(DomUtils.getChildElementValueByTagName(ele, DESCRIPTION_ELEMENT));
// 解析property属性
parseMetaElements(ele, bd);
// 解析其它的属性 ......
bd.setResource(this.readerContext.getResource());
bd.setSource(extractSource(ele));
return bd;
} // catch finally ......
return null;
}
在此方法中我们终于看到了最最最底层的操作:调用 createBeanDefinition() 方法创建了一个 BeanDefinition,其底层使用到了 BeanDefinitionReaderUtils.createBeanDefinition() 方法;,之后把 <bean>
标签中的其它属性、<bean>
的子标签的内容都封装起来,而封装 <bean>
其它属性的 parseBeanDefinitionAttributes() 方法中,已经把这些内容都解析到位了:
public AbstractBeanDefinition parseBeanDefinitionAttributes(Element ele, String beanName,
@Nullable BeanDefinition containingBean, AbstractBeanDefinition bd) {
// 解析scope
if (ele.hasAttribute(SINGLETON_ATTRIBUTE)) {
error("Old 1.x 'singleton' attribute in use - upgrade to 'scope' declaration", ele);
} else if (ele.hasAttribute(SCOPE_ATTRIBUTE)) {
bd.setScope(ele.getAttribute(SCOPE_ATTRIBUTE));
} else if (containingBean != null) {
// Take default from containing bean in case of an inner bean definition.
bd.setScope(containingBean.getScope());
}
// 解析abstract属性
if (ele.hasAttribute(ABSTRACT_ATTRIBUTE)) {
bd.setAbstract(TRUE_VALUE.equals(ele.getAttribute(ABSTRACT_ATTRIBUTE)));
}
// 省略部分相似的封装属性的动作 ......
return bd;
}
到这里,xml 配置文件中的 <bean>
标签就可以转换为 BeanDefinition 了。
BeanDefinitionHolder的意义
BeanDefinitionHolder
,我们说它是持有 BeanDefinition
的一个包装而已,不过它除了持有之外,还包含了另外的重要信息:bean 的名称。
翻看 BeanDefinitionHolder 的源码结构,可以发现这里面还组合了 bean 的 name 和 alias :
public class BeanDefinitionHolder implements BeanMetadataElement {
private final BeanDefinition beanDefinition;
private final String beanName;
@Nullable
private final String[] aliases;
}
BeanDefinition 的结构中是没有 name 的!所以才需要这样一个 holder 帮它持有。
加载 xml 配置文件小结
一、ClasspathXmApplicationContext
在 refresh
方法之前,会指定传入的 xml 配置文件的路径
二、执行 refresh
方法时,会初始化 BeanFactory
,触发 xml 配置文件的读取、加载和解析。其中 xml 的读取需要借助 XmlBeanDefinitionReader
;解析 xml 文件则使用 DefaultBeanDefinitionDocumentReader
,最终解析出 xml 中的元素,使用 BeanDefinitionHolder
封装出 BeanDefinition
,最后注册到 BeanDefinitionRegistry
加载注解配置类
相比较 Xml 配置文件,注解配置类的加载时机会晚一些,他用到了一个非常重要的 BeanDefinitionRegistryPostProcessor
,无论如何这个后置处理器的优先级都是最高(最优先执行)的,它就是 ConfigurationClassPostProcessor 。
BeanDefinitionRegistryPostProcessor的调用时机
回到 AbstractApplicationContext.refresh()
方法中,这次我们要看的是 BeanFactoryPostProcessor
和 BeanDefinitionRegistryPostProcessor
的执行时机,而它们在 refresh 方法的第五步执行:
public void refresh() throws BeansException, IllegalStateException {
synchronized (this.startupShutdownMonitor) {
// ......
try {
postProcessBeanFactory(beanFactory);
// 5. 执行BeanFactoryPostProcessor
invokeBeanFactoryPostProcessors(beanFactory);
registerBeanPostProcessors(beanFactory);
// ......
}
// catch finally .....
}
}
```这个方法就一个核心逻辑
```java
protected void invokeBeanFactoryPostProcessors(ConfigurableListableBeanFactory beanFactory) {
// 交给代理执行
PostProcessorRegistrationDelegate.invokeBeanFactoryPostProcessors(beanFactory, getBeanFactoryPostProcessors());
// 下面是支持AOP的部分(暂时不读)
}
它又交给一个 Delegate 执行
PostProcessorRegistrationDelegate的实现
invokeBeanFactoryPostProcessors 方法的篇幅实在太长了,这里只截取关键部分
public static void invokeBeanFactoryPostProcessors(
ConfigurableListableBeanFactory beanFactory, List<BeanFactoryPostProcessor> beanFactoryPostProcessors) {
Set<String> processedBeans = new HashSet<>();
if (beanFactory instanceof BeanDefinitionRegistry) {
BeanDefinitionRegistry registry = (BeanDefinitionRegistry) beanFactory;
List<BeanFactoryPostProcessor> regularPostProcessors = new ArrayList<>();
List<BeanDefinitionRegistryPostProcessor> registryProcessors = new ArrayList<>();
// 该部分会将BeanFactoryPostProcessor与BeanDefinitionRegistryPostProcessor分离开
for (BeanFactoryPostProcessor postProcessor : beanFactoryPostProcessors) {
if (postProcessor instanceof BeanDefinitionRegistryPostProcessor) {
BeanDefinitionRegistryPostProcessor registryProcessor =
(BeanDefinitionRegistryPostProcessor) postProcessor;
registryProcessor.postProcessBeanDefinitionRegistry(registry);
registryProcessors.add(registryProcessor);
}
else {
regularPostProcessors.add(postProcessor);
}
}
List<BeanDefinitionRegistryPostProcessor> currentRegistryProcessors = new ArrayList<>();
// 首先,执行实现了PriorityOrdered接口的BeanDefinitionRegistryPostProcessors
String[] postProcessorNames =
beanFactory.getBeanNamesForType(BeanDefinitionRegistryPostProcessor.class, true, false);
for (String ppName : postProcessorNames) {
if (beanFactory.isTypeMatch(ppName, PriorityOrdered.class)) {
currentRegistryProcessors.add(beanFactory.getBean(ppName, BeanDefinitionRegistryPostProcessor.class));
processedBeans.add(ppName);
}
}
sortPostProcessors(currentRegistryProcessors, beanFactory);
registryProcessors.addAll(currentRegistryProcessors);
invokeBeanDefinitionRegistryPostProcessors(currentRegistryProcessors, registry);
currentRegistryProcessors.clear();
// 接下来,执行实现了Ordered接口的BeanDefinitionRegistryPostProcessors
postProcessorNames = beanFactory.getBeanNamesForType(BeanDefinitionRegistryPostProcessor.class, true, false);
for (String ppName : postProcessorNames) {
if (!processedBeans.contains(ppName) && beanFactory.isTypeMatch(ppName, Ordered.class)) {
currentRegistryProcessors.add(beanFactory.getBean(ppName, BeanDefinitionRegistryPostProcessor.class));
processedBeans.add(ppName);
}
}
sortPostProcessors(currentRegistryProcessors, beanFactory);
registryProcessors.addAll(currentRegistryProcessors);
invokeBeanDefinitionRegistryPostProcessors(currentRegistryProcessors, registry);
currentRegistryProcessors.clear();
// 最后,执行所有其他BeanDefinitionRegistryPostProcessor
boolean reiterate = true;
while (reiterate) {
reiterate = false;
postProcessorNames = beanFactory.getBeanNamesForType(BeanDefinitionRegistryPostProcessor.class, true, false);
for (String ppName : postProcessorNames) {
if (!processedBeans.contains(ppName)) {
currentRegistryProcessors.add(beanFactory.getBean(ppName, BeanDefinitionRegistryPostProcessor.class));
processedBeans.add(ppName);
reiterate = true;
}
}
sortPostProcessors(currentRegistryProcessors, beanFactory);
registryProcessors.addAll(currentRegistryProcessors);
invokeBeanDefinitionRegistryPostProcessors(currentRegistryProcessors, registry);
currentRegistryProcessors.clear();
}
invokeBeanFactoryPostProcessors(registryProcessors, beanFactory);
invokeBeanFactoryPostProcessors(regularPostProcessors, beanFactory);
}
else {
invokeBeanFactoryPostProcessors(beanFactoryPostProcessors, beanFactory);
}
// 执行BeanFactoryPostProcessor ......
}
概括一下这段代码做了哪些事
- 执行
BeanDefinitionRegistryPostProcessor
的 PostProcessorBeanDefinitionRegistry 方法- 执行实现了
PriorityOrdered
接口的BeanDefinitionRegistryPostProcessor
- 执行实现了
Ordered
接口的BeanDefinitionRegistryPostProcessor
- 执行普通的
BeanDefinitionRegistryPostProcessor
- 执行实现了
- 执行
BeanDefinitionRegistryPostProcessor
的 postProcessorBeanFactory 方法
在这个长长的方法中,第一个环节它会执行所有实现了 PriorityOrdered
接口的 BeanDefinitionRegistryPostProcessor
,这里面第一个执行的处理器就是 ConfigurationClassPostProcessor
,咱跟过去看一看。
ConfigurationClassPostProcessor的处理
这个方法在 ConfigurationClassPostProcessor
子类中
public void postProcessBeanDefinitionRegistry(BeanDefinitionRegistry registry) {
int registryId = System.identityHashCode(registry);
// check throw ex ......
this.registriesPostProcessed.add(registryId);
// 【解析配置类】
processConfigBeanDefinitions(registry);
}
在这个方法的最后一行,就是解析配置类中定义的 bean ,并封装为 BeanDefinition
进入 processConfigBeanDefinitions 方法
public void processConfigBeanDefinitions(BeanDefinitionRegistry registry) {
List<BeanDefinitionHolder> configCandidates = new ArrayList<>();
String[] candidateNames = registry.getBeanDefinitionNames();
// 筛选出所有的配置类
for (String beanName : candidateNames) {
BeanDefinition beanDef = registry.getBeanDefinition(beanName);
// full configuration的解释可参考boot小册12章5.2.1.1节
if (ConfigurationClassUtils.isFullConfigurationClass(beanDef) ||
ConfigurationClassUtils.isLiteConfigurationClass(beanDef)) {
// logger ......
} else if (ConfigurationClassUtils.checkConfigurationClassCandidate(beanDef, this.metadataReaderFactory)) {
configCandidates.add(new BeanDefinitionHolder(beanDef, beanName));
}
}
// Return immediately if no @Configuration classes were found
if (configCandidates.isEmpty()) {
return;
}
// 配置类排序
configCandidates.sort((bd1, bd2) -> {
int i1 = ConfigurationClassUtils.getOrder(bd1.getBeanDefinition());
int i2 = ConfigurationClassUtils.getOrder(bd2.getBeanDefinition());
return Integer.compare(i1, i2);
});
// 构造默认的BeanNameGenerator bean的名称生成器
SingletonBeanRegistry sbr = null;
if (registry instanceof SingletonBeanRegistry) {
sbr = (SingletonBeanRegistry) registry;
if (!this.localBeanNameGeneratorSet) {
BeanNameGenerator generator = (BeanNameGenerator) sbr.getSingleton(CONFIGURATION_BEAN_NAME_GENERATOR);
if (generator != null) {
this.componentScanBeanNameGenerator = generator;
this.importBeanNameGenerator = generator;
}
}
}
if (this.environment == null) {
this.environment = new StandardEnvironment();
}
// 真正解析配置类的组件:ConfigurationClassParser
ConfigurationClassParser parser = new ConfigurationClassParser(
this.metadataReaderFactory, this.problemReporter, this.environment,
this.resourceLoader, this.componentScanBeanNameGenerator, registry);
Set<BeanDefinitionHolder> candidates = new LinkedHashSet<>(configCandidates);
Set<ConfigurationClass> alreadyParsed = new HashSet<>(configCandidates.size());
do {
// 【解析配置类】
parser.parse(candidates);
parser.validate();
Set<ConfigurationClass> configClasses = new LinkedHashSet<>(parser.getConfigurationClasses());
configClasses.removeAll(alreadyParsed);
if (this.reader == null) {
this.reader = new ConfigurationClassBeanDefinitionReader(
registry, this.sourceExtractor, this.resourceLoader, this.environment,
this.importBeanNameGenerator, parser.getImportRegistry());
}
// 【加载配置类的内容】
this.reader.loadBeanDefinitions(configClasses);
alreadyParsed.addAll(configClasses);
// 一些额外的处理动作
}
while (!candidates.isEmpty());
// 一些额外的处理 ......
}
这里面的前置动作初始化了一个 ConfigurationClassParser
,这是用来解析注解配置类的核心 API 。
下面就可以进入 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 ......
}
// 回调特殊的ImportSelector
this.deferredImportSelectorHandler.process();
}
整体看一下这个方法的内容哈。上面的 for 循环中,它会把配置类的全限定名拿出来,扔进重载的 parse 方法中(注意无论是执行 if-else-if 的哪个分支,最终都是执行重载的 parse 方法);for 循环调用完成后,最底下会让 deferredImportSelectorHandler 执行 process 方法,这个东西我们完全没见过,这里有必要说明一下。
ImportSelector的扩展
在 SpringFramework 4.0 中,ImportSelector 多了一个子接口:DeferredImportSelector
,它的执行时机比 ImportSelector 更晚,它会在注解配置类的所有解析工作完成后才执行
一般情况下,DeferredImportSelector
会跟 @Conditional
注解配合使用,完成条件装配。
deferredImportSelectorHandler的处理逻辑
进入 DeferredImportSelectorHandler
的 process 方法:
public void process() {
List<DeferredImportSelectorHolder> deferredImports = this.deferredImportSelectors;
this.deferredImportSelectors = null;
try {
if (deferredImports != null) {
DeferredImportSelectorGroupingHandler handler = new DeferredImportSelectorGroupingHandler();
deferredImports.sort(DEFERRED_IMPORT_COMPARATOR);
deferredImports.forEach(handler::register);
handler.processGroupImports();
}
}
finally {
this.deferredImportSelectors = new ArrayList<>();
}
}
这个方法的处理逻辑还是很简单的,它会取出所有解析中存储好的 DeferredImportSelector ,并依次执行。由于 DeferredImportSelector 的执行时机比较晚,对于 @Conditional 条件装配的处理也会更有利
parse解析配置类
上面的 ConfigurationClassParser
中最终都会把配置类传入重载的 parse 方法中,参数类型注意是 ConfigurationClass
:
protected final void parse(AnnotationMetadata metadata, String beanName) throws IOException {
processConfigurationClass(new ConfigurationClass(metadata, beanName));
}
protected void processConfigurationClass(ConfigurationClass configClass) throws IOException {
if (this.conditionEvaluator.shouldSkip(configClass.getMetadata(), ConfigurationPhase.PARSE_CONFIGURATION)) {
return;
}
ConfigurationClass existingClass = this.configurationClasses.get(configClass);
if (existingClass != null) {
// 如果配置类已经被@Import过了,则跳过
if (configClass.isImported()) {
if (existingClass.isImported()) {
existingClass.mergeImportedBy(configClass);
}
return;
}
else {
this.configurationClasses.remove(configClass);
this.knownSuperclasses.values().removeIf(configClass::equals);
}
}
SourceClass sourceClass = asSourceClass(configClass);
do {
// 【真正干活的】
sourceClass = doProcessConfigurationClass(configClass, sourceClass);
}
while (sourceClass != null);
this.configurationClasses.put(configClass, configClass);
}
底下又是调 doXXX 方法了
doProcessConfigurationClass - 解析配置类
这个方法非常的长,我们分开解释
处理@Component注解
protected final SourceClass doProcessConfigurationClass(ConfigurationClass configClass, SourceClass sourceClass)
throws IOException {
if (configClass.getMetadata().isAnnotated(Component.class.getName())) {
processMemberClasses(configClass, sourceClass);
}
// .............
一上来,它就会判断这个类是否有标注 @Component 注解。因为所有的 @Configuration 类必定是 @Component ,所以该逻辑必进。而内部执行的 processMemberClasses 方法如下:
private void processMemberClasses(ConfigurationClass configClass, SourceClass sourceClass,
Predicate<String> filter) throws IOException {
// 获取配置类中的所有内部类
Collection<SourceClass> memberClasses = sourceClass.getMemberClasses();
if (!memberClasses.isEmpty()) {
List<SourceClass> candidates = new ArrayList<>(memberClasses.size());
// 循环解析内部类
for (SourceClass memberClass : memberClasses) {
// 如果内部类也是配置类,则它们也会被解析
if (ConfigurationClassUtils.isConfigurationCandidate(memberClass.getMetadata()) &&
!memberClass.getMetadata().getClassName().equals(configClass.getMetadata().getClassName())) {
candidates.add(memberClass);
}
}
OrderComparator.sort(candidates);
for (SourceClass candidate : candidates) {
// 防止循环@Import的处理:如果两个配置类互相@Import,则视为错误
if (this.importStack.contains(configClass)) {
this.problemReporter.error(new CircularImportProblem(configClass, this.importStack));
} else {
this.importStack.push(configClass);
try {
// 递归解析内部的配置类
processConfigurationClass(candidate.asConfigClass(configClass), filter);
}
finally {
this.importStack.pop();
}
}
}
}
}
这个方法是处理内部类的,而且还是递归处理,这个套路很像上面 <beans>
的 xml 递归解析。
处理@PropertySource注解
// ............
// Process any @PropertySource annotations
for (AnnotationAttributes propertySource : AnnotationConfigUtils.attributesForRepeatable(
sourceClass.getMetadata(), PropertySources.class,
org.springframework.context.annotation.PropertySource.class)) {
if (this.environment instanceof ConfigurableEnvironment) {
processPropertySource(propertySource);
}
// else logger ......
}
// ............
接下来是处理 @PropertySource 注解了,可以发现借助 AnnotationConfigUtils
可以很容易的取出配置类上标注的所有注解信息,然后筛选出指定的注解属性即可。而内部的 processPropertySource 方法就在真正的封装 PropertySource 导入的资源文件:
private void processPropertySource(AnnotationAttributes propertySource) throws IOException {
// 解析@PropertySource注解的属性
String name = propertySource.getString("name");
if (!StringUtils.hasLength(name)) {
name = null;
}
String encoding = propertySource.getString("encoding");
if (!StringUtils.hasLength(encoding)) {
encoding = null;
}
String[] locations = propertySource.getStringArray("value");
// ......
for (String location : locations) {
try {
// 处理路径,加载资源文件,并添加进Environment中
String resolvedLocation = this.environment.resolveRequiredPlaceholders(location);
Resource resource = this.resourceLoader.getResource(resolvedLocation);
addPropertySource(factory.createPropertySource(name, new EncodedResource(resource, encoding)));
} // catch ......
}
}
前面的一大堆操作都是拿 @PropertySource 的一些属性等等,最后的 for 循环中才是封装资源文件,存放进 Environment 的部分。
处理@ComponentScan注解
// ............
// Process any @ComponentScan annotations
Set<AnnotationAttributes> componentScans = AnnotationConfigUtils.attributesForRepeatable(
sourceClass.getMetadata(), ComponentScans.class, ComponentScan.class);
if (!componentScans.isEmpty() &&
!this.conditionEvaluator.shouldSkip(sourceClass.getMetadata(), ConfigurationPhase.REGISTER_BEAN)) {
// 如果有@ComponentScans,则要取出里面所有的@ComponentScan依次扫描
for (AnnotationAttributes componentScan : componentScans) {
// 【复杂】借助ComponentScanAnnotationParser扫描
Set<BeanDefinitionHolder> scannedBeanDefinitions =
this.componentScanParser.parse(componentScan, sourceClass.getMetadata().getClassName());
// 是否扫描到了其它的注解配置类
for (BeanDefinitionHolder holder : scannedBeanDefinitions) {
BeanDefinition bdCand = holder.getBeanDefinition().getOriginatingBeanDefinition();
if (bdCand == null) {
bdCand = holder.getBeanDefinition();
}
if (ConfigurationClassUtils.checkConfigurationClassCandidate(bdCand, this.metadataReaderFactory)) {
// 如果扫描到了,递归解析
parse(bdCand.getBeanClassName(), holder.getBeanName());
}
}
}
}
// ............
接下来的部分是处理 @ComponentScan 注解了,整个流程也不复杂。注意一点:@ComponentScan 可以标注多个,并且 Spring 4.3 后多了一个 @ComponentScans 注解,它可以组合多个 @ComponentScan 注解,所以这里是 for 循环解析 @ComponentScan 。
中间的部分,它使用 ComponentScanAnnotationParser
来委托处理包扫描的工作,可能会有小伙伴产生疑惑:不是包扫描的组件是 ClassPathBeanDefinitionScanner
吗?它是谁?先别着急,我们进到 ComponentScanAnnotationParser
的 parse 方法中,看一看内部的实现:(嗯,第一行就把 ClassPathBeanDefinitionScanner
创建出来了 ~ )
public Set<BeanDefinitionHolder> parse(AnnotationAttributes componentScan, final String declaringClass) {
// 构造ClassPathBeanDefinitionScanner
ClassPathBeanDefinitionScanner scanner = new ClassPathBeanDefinitionScanner(this.registry,
componentScan.getBoolean("useDefaultFilters"), this.environment, this.resourceLoader);
// 解析@ComponentScan中的属性 ......
Class<? extends BeanNameGenerator> generatorClass = componentScan.getClass("nameGenerator");
// 整理要扫描的basePackages
Set<String> basePackages = new LinkedHashSet<>();
String[] basePackagesArray = componentScan.getStringArray("basePackages");
for (String pkg : basePackagesArray) {
String[] tokenized = StringUtils.tokenizeToStringArray(this.environment.resolvePlaceholders(pkg),
ConfigurableApplicationContext.CONFIG_LOCATION_DELIMITERS);
Collections.addAll(basePackages, tokenized);
}
for (Class<?> clazz : componentScan.getClassArray("basePackageClasses")) {
basePackages.add(ClassUtils.getPackageName(clazz));
}
// 没有声明basePackages,则当前配置类所在的包即为根包
if (basePackages.isEmpty()) {
basePackages.add(ClassUtils.getPackageName(declaringClass));
}
// ......
// 【扫描】执行包扫描动作
return scanner.doScan(StringUtils.toStringArray(basePackages));
}
这个方法大概干了三件事:
- 构建
ClassPathBeanDefinitionScanner
,并封装@ComponentScan
注解中的属性 - 整理要进行包扫描的 baskPackages,以及 include 和 exclude 的过滤器
- 执行包扫描动作
前面两个步骤都是准备动作,真正的包扫描那还得看 ClassPathBeanDefinitionScanner
,来吧,咱直接进到最底下的 doScan 方法中:
protected Set<BeanDefinitionHolder> doScan(String... basePackages) {
// assert ......
Set<BeanDefinitionHolder> beanDefinitions = new LinkedHashSet<>();
for (String basePackage : basePackages) {
// 【真正的包扫描动作在这里】
Set<BeanDefinition> candidates = findCandidateComponents(basePackage);
for (BeanDefinition candidate : candidates) {
// 处理scope(默认情况下是singleton)
ScopeMetadata scopeMetadata = this.scopeMetadataResolver.resolveScopeMetadata(candidate);
candidate.setScope(scopeMetadata.getScopeName());
// 生成bean的名称
String beanName = this.beanNameGenerator.generateBeanName(candidate, this.registry);
if (candidate instanceof AbstractBeanDefinition) {
postProcessBeanDefinition((AbstractBeanDefinition) candidate, beanName);
}
// 处理bean中的@Lazy、@Primary等注解
if (candidate instanceof AnnotatedBeanDefinition) {
AnnotationConfigUtils.processCommonDefinitionAnnotations((AnnotatedBeanDefinition) candidate);
}
if (checkCandidate(beanName, candidate)) {
BeanDefinitionHolder definitionHolder = new BeanDefinitionHolder(candidate, beanName);
// 设置AOP相关的属性(如果支持的话)
definitionHolder = AnnotationConfigUtils.applyScopedProxyMode(scopeMetadata, definitionHolder, this.registry);
beanDefinitions.add(definitionHolder);
// 注册进BeanDefinitionRegistry
registerBeanDefinition(definitionHolder, this.registry);
}
}
}
return beanDefinitions;
}
从上往下的逻辑条理还是很清晰的,只要扫描到了符合的类(默认被 @Component 注解标注的类),就会包装为 BeanDefinition ,然后对这些 BeanDefinition 进行一些额外的处理,最终注册进 BeanDefinitionRegistry。不过核心的扫描方法还是封装方法了,咱进入 for 循环的第一句 findCandidateComponents 方法中:
public Set<BeanDefinition> findCandidateComponents(String basePackage) {
if (this.componentsIndex != null && indexSupportsIncludeFilters()) {
return addCandidateComponentsFromIndex(this.componentsIndex, basePackage);
} else {
return scanCandidateComponents(basePackage);
}
}
private Set<BeanDefinition> scanCandidateComponents(String basePackage) {
Set<BeanDefinition> candidates = new LinkedHashSet<>();
try {
// 此处可处理 [/**/service/*Service.class] 这样的表达式
String packageSearchPath = ResourcePatternResolver.CLASSPATH_ALL_URL_PREFIX +
resolveBasePackage(basePackage) + '/' + this.resourcePattern;
Resource[] resources = getResourcePatternResolver().getResources(packageSearchPath);
for (Resource resource : resources) {
if (resource.isReadable()) {
try {
// 加载.class字节码
MetadataReader metadataReader = getMetadataReaderFactory().getMetadataReader(resource);
// 如果符合匹配规则,则封装为ScannedGenericBeanDefinition
if (isCandidateComponent(metadataReader)) {
ScannedGenericBeanDefinition sbd = new ScannedGenericBeanDefinition(metadataReader);
sbd.setSource(resource);
if (isCandidateComponent(sbd)) {
candidates.add(sbd);
}
}
} // catch .......
}
}
} // catch ......
return candidates;
}
整体逻辑还是简单的很:它会将带有通配符的 Ant 风格(诸如 /xxx/**/*.class )
的路径解析出来,并加载到对应的类,封装为 ScannedGenericBeanDefinition
,完事。
到这里,包扫描的处理就完成了,@ComponentScan 的处理也就结束了。
处理@Import注解
// ............
// Process any @Import annotations
processImports(configClass, sourceClass, getImports(sourceClass), true);
// ............
private void processImports(ConfigurationClass configClass, SourceClass currentSourceClass,
Collection<SourceClass> importCandidates, Predicate<String> exclusionFilter,
boolean checkForCircularImports) {
if (importCandidates.isEmpty()) {
return;
}
// 防止循环@Import导入
if (checkForCircularImports && isChainedImportOnStack(configClass)) {
this.problemReporter.error(new CircularImportProblem(configClass, this.importStack));
}
else {
this.importStack.push(configClass);
try {
for (SourceClass candidate : importCandidates) {
// 处理ImportSelector
if (candidate.isAssignable(ImportSelector.class)) {
Class<?> candidateClass = candidate.loadClass();
ImportSelector selector = ParserStrategyUtils.instantiateClass(candidateClass, ImportSelector.class,
this.environment, this.resourceLoader, this.registry);
Predicate<String> selectorFilter = selector.getExclusionFilter();
if (selectorFilter != null) {
exclusionFilter = exclusionFilter.or(selectorFilter);
}
// DeferredImportSelector的执行时机后延
if (selector instanceof DeferredImportSelector) {
this.deferredImportSelectorHandler.handle(configClass, (DeferredImportSelector) selector);
} else {
// 执行ImportSelector的selectImports方法,并注册导入的类
String[] importClassNames = selector.selectImports(currentSourceClass.getMetadata());
Collection<SourceClass> importSourceClasses = asSourceClasses(importClassNames, exclusionFilter);
processImports(configClass, currentSourceClass, importSourceClasses, exclusionFilter, false);
}
}
// 处理ImportBeanDefinitionRegistrar
else if (candidate.isAssignable(ImportBeanDefinitionRegistrar.class)) {
Class<?> candidateClass = candidate.loadClass();
ImportBeanDefinitionRegistrar registrar =
ParserStrategyUtils.instantiateClass(candidateClass, ImportBeanDefinitionRegistrar.class,
this.environment, this.resourceLoader, this.registry);
configClass.addImportBeanDefinitionRegistrar(registrar, currentSourceClass.getMetadata());
}
else {
// 导入普通类 / 配置类
this.importStack.registerImport(
currentSourceClass.getMetadata(), candidate.getMetadata().getClassName());
processConfigurationClass(candidate.asConfigClass(configClass), exclusionFilter);
}
}
} // catch ......
finally {
this.importStack.pop();
}
}
}
整体逻辑非常有序,它分别对 ImportSelector 、ImportBeanDefinitionRegistrar 、普通类 / 配置类都做了处理,整体逻辑非常有序,它分别对 ImportSelector 、ImportBeanDefinitionRegistrar 、普通类 / 配置类都做了处理,并递归解析其中存在的配置类
处理@ImportResource注解
// ............
// Process any @ImportResource annotations
AnnotationAttributes importResource =
AnnotationConfigUtils.attributesFor(sourceClass.getMetadata(), ImportResource.class);
if (importResource != null) {
String[] resources = importResource.getStringArray("locations");
Class<? extends BeanDefinitionReader> readerClass = importResource.getClass("reader");
for (String resource : resources) {
String resolvedResource = this.environment.resolveRequiredPlaceholders(resource);
configClass.addImportedResource(resolvedResource, readerClass);
}
}
// ............
在注解配置类上标注 @ImportResource 可以导入 xml 配置文件,而解析这些 @ImportResource 的逻辑就在这里。不过看源码的中,是把配置文件的路径放入了 configClass 中而已;具体的解析在之前看 ConfigurationClassPostProcessor
的后置处理 processConfigBeanDefinitions 方法中,在 parse 方法下面的 loadBeanDefinitions 方法中。
处理@Bean注解
// ............
// Process individual @Bean methods
Set<MethodMetadata> beanMethods = retrieveBeanMethodMetadata(sourceClass);
for (MethodMetadata methodMetadata : beanMethods) {
configClass.addBeanMethod(new BeanMethod(methodMetadata, configClass));
}
// ............
合着 @Bean 的处理也只是存起来呗?那它啥时候处理啊?不会跟上面的 @ImportResource 放在一块处理吧?哎,想法可以保留,过会我们往下看到了自然就揭晓了。不过它是如何把这些 @Bean 方法都拿出来的,我们还得去看看 retrieveBeanMethodMetadata 方法:
private Set<MethodMetadata> retrieveBeanMethodMetadata(SourceClass sourceClass) {
AnnotationMetadata original = sourceClass.getMetadata();
// 获取被@Bean注解标注的方法
Set<MethodMetadata> beanMethods = original.getAnnotatedMethods(Bean.class.getName());
if (beanMethods.size() > 1 && original instanceof StandardAnnotationMetadata) {
try {
AnnotationMetadata asm =
this.metadataReaderFactory.getMetadataReader(original.getClassName()).getAnnotationMetadata();
Set<MethodMetadata> asmMethods = asm.getAnnotatedMethods(Bean.class.getName());
if (asmMethods.size() >= beanMethods.size()) {
Set<MethodMetadata> selectedMethods = new LinkedHashSet<>(asmMethods.size());
// 筛选每个方法
for (MethodMetadata asmMethod : asmMethods) {
for (MethodMetadata beanMethod : beanMethods) {
if (beanMethod.getMethodName().equals(asmMethod.getMethodName())) {
selectedMethods.add(beanMethod);
break;
}
}
}
if (selectedMethods.size() == beanMethods.size()) {
beanMethods = selectedMethods;
}
}
} // catch ......
}
return beanMethods;
}
一上来我们就看到 @Bean 注解的方法过滤了,经过这个过滤之后,就只会得到配置类中被 @Bean 注解标注的方法。
JVM 的标准反射不保证方法列表返回的顺序一致。所以,想要保证程序在任何 JVM 上、任何应用中,加载同一个 .class 文件的方法列表都返回相同的顺序,那就只能读取字节码了,而读取字节码的技术,Spring 选择了 ASM 。 Spring 使用 ASM 读取字节码的目的,是为了保证加载配置类中 @Bean 方法的从上到下的顺序与源文件 .java 中一致。
处理父接口
// ............
// Process default methods on interfaces
processInterfaces(configClass, sourceClass);
// ............
private void processInterfaces(ConfigurationClass configClass, SourceClass sourceClass) throws IOException {
for (SourceClass ifc : sourceClass.getInterfaces()) {
// 寻找接口中标注了@Bean的方法
Set<MethodMetadata> beanMethods = retrieveBeanMethodMetadata(ifc);
for (MethodMetadata methodMetadata : beanMethods) {
if (!methodMetadata.isAbstract()) {
configClass.addBeanMethod(new BeanMethod(methodMetadata, configClass));
}
}
processInterfaces(configClass, ifc);
}
}
这段逻辑,它会把配置类实现的所有接口都拿出来,并且遍历所有标注了 @Bean 的方法,并添加到 bean 的注册信息中。跟上面一样,它只是存起来,并没有封装为 BeanDefinition ,所以这里只是解析动作而已。
父类的返回
// ............
// Process superclass, if any
if (sourceClass.getMetadata().hasSuperClass()) {
String superclass = sourceClass.getMetadata().getSuperClassName();
if (superclass != null && !superclass.startsWith("java") &&
!this.knownSuperclasses.containsKey(superclass)) {
this.knownSuperclasses.put(superclass, configClass);
return sourceClass.getSuperClass();
}
}
return null;
}
这段代码的逻辑是:如果配置类存在父类的话,父类也应该一起加载,所以这里会取到配置类的父类,并继续递归处理。
loadBeanDefinitions - 加载BeanDefinition
到这里,配置类的解析就完成了,回到 ConfigurationClassPostProcessor 中,解析完那些 @Bean 后还要注册为 BeanDefinition 呢,而这个方法的核心在 loadBeanDefinitions 中,我们也来研究。
this.reader.loadBeanDefinitions(configClasses);
的执行会来到 ConfigurationClassBeanDefinitionReader
中:
public void loadBeanDefinitions(Set<ConfigurationClass> configurationModel) {
TrackedConditionEvaluator trackedConditionEvaluator = new TrackedConditionEvaluator();
for (ConfigurationClass configClass : configurationModel) {
loadBeanDefinitionsForConfigurationClass(configClass, trackedConditionEvaluator);
}
}
循环,直接进到 loadBeanDefinitionsForConfigurationClass 中:
private void loadBeanDefinitionsForConfigurationClass(
ConfigurationClass configClass, TrackedConditionEvaluator trackedConditionEvaluator) {
// 与条件装配有关
if (trackedConditionEvaluator.shouldSkip(configClass)) {
String beanName = configClass.getBeanName();
if (StringUtils.hasLength(beanName) && this.registry.containsBeanDefinition(beanName)) {
this.registry.removeBeanDefinition(beanName);
}
this.importRegistry.removeImportingClass(configClass.getMetadata().getClassName());
return;
}
// 如果当前配置类是被@Import的,要把自己注册进BeanFactory
if (configClass.isImported()) {
registerBeanDefinitionForImportedConfigurationClass(configClass);
}
// 注册@Bean注解方法
for (BeanMethod beanMethod : configClass.getBeanMethods()) {
loadBeanDefinitionsForBeanMethod(beanMethod);
}
// 注册来自xml配置文件的bean
loadBeanDefinitionsFromImportedResources(configClass.getImportedResources());
// 注册来自ImportBeanDefinitionRegistrar的bean
loadBeanDefinitionsFromRegistrars(configClass.getImportBeanDefinitionRegistrars());
}
这里的逻辑分为 4 个部分:
一、registerBeanDefinitionForImportedConfigurationClass
将配置类自身注册进
BeanFactory
。按照扫描包的原则来看,只要是@Configuration
,那久必然是@Component
,就应该一起注册到BeanFactory
中。如果这个配置类是通过@Import
的方式导入的,那就不会自动注入进BeanFactory
,所以在这里需要将那些被@Import
进去的配置类,也全部注册到BeanFactory
这个方法就是一个普通的 BeanDefinition
注册,没有其他花里胡哨的操作
private void registerBeanDefinitionForImportedConfigurationClass(ConfigurationClass configClass) {
AnnotationMetadata metadata = configClass.getMetadata();
// 构造BeanDefinition
AnnotatedGenericBeanDefinition configBeanDef = new AnnotatedGenericBeanDefinition(metadata);
ScopeMetadata scopeMetadata = scopeMetadataResolver.resolveScopeMetadata(configBeanDef);
configBeanDef.setScope(scopeMetadata.getScopeName());
String configBeanName = this.importBeanNameGenerator.generateBeanName(configBeanDef, this.registry);
AnnotationConfigUtils.processCommonDefinitionAnnotations(configBeanDef, metadata);
// 包装BeanDefinitionHolder
BeanDefinitionHolder definitionHolder = new BeanDefinitionHolder(configBeanDef, configBeanName);
definitionHolder = AnnotationConfigUtils.applyScopedProxyMode(scopeMetadata, definitionHolder, this.registry);
// 注册进BeanDefinitionRegistry
this.registry.registerBeanDefinition(definitionHolder.getBeanName(), definitionHolder.getBeanDefinition());
configClass.setBeanName(configBeanName);
// logger ......
}
二、loadBeanDefinitionsForBeanMethod
这个方法就是加载刚才处理过的那些 @Bean
方法了
private void loadBeanDefinitionsForBeanMethod(BeanMethod beanMethod) {
ConfigurationClass configClass = beanMethod.getConfigurationClass();
MethodMetadata metadata = beanMethod.getMetadata();
String methodName = metadata.getMethodName();
// 如果条件装配将其跳过,则该@Bean标注的方法,对应的BeanDefinition不会注册进BeanDefinitionRegistry
if (this.conditionEvaluator.shouldSkip(metadata, ConfigurationPhase.REGISTER_BEAN)) {
configClass.skippedBeanMethods.add(methodName);
return;
}
if (configClass.skippedBeanMethods.contains(methodName)) {
return;
}
// 检查方法上真的有@Bean注解吗
AnnotationAttributes bean = AnnotationConfigUtils.attributesFor(metadata, Bean.class);
// assert ......
// 如果bean指定了多个name,则第1个为唯一标识,其余的都是alias别名
List<String> names = new ArrayList<>(Arrays.asList(bean.getStringArray("name")));
String beanName = (!names.isEmpty() ? names.remove(0) : methodName);
// Register aliases even when overridden
for (String alias : names) {
this.registry.registerAlias(beanName, alias);
}
// 注解中配置了@Bean,与xml中的bean撞车了,会抛出异常
if (isOverriddenByExistingDefinition(beanMethod, beanName)) {
if (beanName.equals(beanMethod.getConfigurationClass().getBeanName())) {
// throw ex ......
}
return;
}
// 构造BeanDefinition
ConfigurationClassBeanDefinition beanDef = new ConfigurationClassBeanDefinition(configClass, metadata);
beanDef.setSource(this.sourceExtractor.extractSource(metadata, configClass.getResource()));
// 【复杂】解析@Bean所在方法的修饰符
if (metadata.isStatic()) {
// static @Bean method
if (configClass.getMetadata() instanceof StandardAnnotationMetadata) {
beanDef.setBeanClass(((StandardAnnotationMetadata) configClass.getMetadata()).getIntrospectedClass());
} else {
beanDef.setBeanClassName(configClass.getMetadata().getClassName());
}
beanDef.setUniqueFactoryMethodName(methodName);
}
else {
// instance @Bean method
beanDef.setFactoryBeanName(configClass.getBeanName());
beanDef.setUniqueFactoryMethodName(methodName);
}
// 处理@Bean的属性(name、initMethod等)、额外的注解(@Lazy、@DependsOn等) ......
// 注册进BeanDefinitionRegistry
this.registry.registerBeanDefinition(beanName, beanDefToRegister);
}
标准的套路:检查 → 构造 BeanDefinition
→ 封装信息 → 注册进 eanDefinitionRegistry
metadata.isStatic() 判断逻辑下面,会给 BeanDefinition 封装两个属性:setBeanClassName / setFactoryBeanName 、setUniqueFactoryMethodName ,它们俩分别指定了当前 @Bean 方法所在的配置类,以及方法名。
@Component 注解标注的类形成的 BeanDefinition ,以及 xml 配置文件转换出来的 BeanDefinition 有个什么特点?它们都指定了 bean 的全限定名、属性注入等,而且最终创建的对象一定是通过反射创建。而在注解配置类中的 @Bean 方法是有实际的代码执行,属于编程式创建,无法使用(也不适合用)反射创建 bean 对象,所以为了在后面能正常创建出 bean 对象,此处就需要记录该 bean 的定义源(包含注解配置类和方法名),以保证在创建 bean 对象时,能够使用反射调用该注解配置类的方法,生成 bean 对象并返回。
三、loadBeanDefinitionsFromImportedResources
这部分是解析从注解配置类上取到的 xml 配置文件的路径
private void loadBeanDefinitionsFromImportedResources(
Map<String, Class<? extends BeanDefinitionReader>> importedResources) {
Map<Class<?>, BeanDefinitionReader> readerInstanceCache = new HashMap<>();
importedResources.forEach((resource, readerClass) -> {
if (BeanDefinitionReader.class == readerClass) {
if (StringUtils.endsWithIgnoreCase(resource, ".groovy")) {
readerClass = GroovyBeanDefinitionReader.class;
}
else {
// 创建XmlBeanDefinitionReader,以备下面的解析
readerClass = XmlBeanDefinitionReader.class;
}
}
BeanDefinitionReader reader = readerInstanceCache.get(readerClass);
// reader的缓存等等
// 调用XmlBeanDefinitionReader解析资源文件
reader.loadBeanDefinitions(resource);
});
}
四、loadBeanDefinitionsFromRegistrars
最后一部分是执行 ImportBeanDefinitionRegistrar ,这个就更简单了,既然是接口,那执行它们的话,只需要调用 registerBeanDefinitions 方法就可以吧,进到方法内部,发现真就是这么简单:
private void loadBeanDefinitionsFromRegistrars(Map<ImportBeanDefinitionRegistrar, AnnotationMetadata> registrars) {
registrars.forEach((registrar, metadata) ->
registrar.registerBeanDefinitions(metadata, this.registry, this.importBeanNameGenerator));
}
加载注解配置类小结
总结一下注解配置类的加载与解析过程:
- 注解配置类的解析发生在
BeanDefinitionRegistryPostProcessor
的执行阶段,对应的核心后置处理器是:ConfigurationClassPostProcessor
,它主要负责两个步骤三件事情;两个步骤:解析配置类、注册BeanDefinition
。三件事情:1) 解析@ComponentScan
并进行包扫描,实际包扫描的组件是ClassPathBeanDefinitionScanner
;2) 解析配置类中的注解(如果是@Import
、@ImportResource
、@PropertySource
等) 并处理,工作核心组件是ConfigurationClassParser
;3) 解析配置类中的@Bean
并封装BeanDefinition
,实际解析的组件是ConfigurationClassBeanDefinitionReader
。
BeanDefinition的后置处理
执行完 ConfigurationClassPathPostProcessor
之后,在 xml 和配置类中定义的 BeanDefinition
就都解析和准备好了,但是还没加载进 BeanDefinitionRegistry
中。下面还有 BeanDefinitionRegistryPostProcessor
和 BeanFactoryPostProcessor
的执行,而它们的执行时机在上面的 PostProcessorRegistrationDelegate#invokeBeanFactoryPostProcessors
方法中。
面试如何回答BeanDefinition部分的生命周期
Bean 的生命周期分为 BeanDefinition
阶段和 bean
实例阶段
BeanDefinition
阶段分为加载 xml 配置文件、解析注解配置类、编程式构造 BeanDefinition
、BeanDefinition
的后置处理器,一共四个部分
-
加载 xml 配置文件:发生在基于 xml 配置文件的
ApplicationContext
中 refresh 方法的BeanFactory
初始化阶段,此时BeanFactory
刚刚构建完成,它会借助xmlBeanDefinitionReader
来加载 xml 配置文件,并使用efaultBeanDefinitionDocumentReader
解析 xml 配置文件,封装声明的<bean>
标签内容并转换为BeanDefinition
。 -
解析注解配置类:发生在基于注解配置的
ApplicationContext
中 refresh 方法的BeanDefinitionRegistryPostProcessor
执行阶段,该阶段会首先执行ConfigurationClassPostProcessor
的 postProcessorBeanDefinitionRegistry 方法。ConfigurationClassPostProcessor
中会找出所有的配置类,排序后依次解析,并借助ClassPathBeanDefinitionScanner
实现包扫描的BeanDefinition
封装,借助onfigurationClassBeanDefinitionReader
实现@Bean
注解方法的BeanDefinition
解析和封装 -
编程式构造:
BeanDefinition
也是发生在ApplicationContext
中 refresh 方法的BeanDefinitionRegistryPostProcessor
执行阶段,由于BeanDefinitionRegistryPostProcessor
会执行ImportBeanDefinitionRegistrar
逻辑,从而达到编程式构造BeanDefinition
并注入到BeanDefinitionRegistry
的目的;另外,实现了BeanDefinitionRegistryPostProcessor
的类也可以编程式构造BeanDefinition
,注入到BeanDefinitionRegistry