Spring IOC原理-Bean的生命周期-BeanDefinition阶段

从 0 开始深入学习 Spring 专栏目录总览

我们开始来研究 bean 完整生命周期的 BeanDefinition 阶段了,这一阶段主要发生了以下几件事情:

  • 加载配置文件、配置类
  • 解析配置文件、配置类并封装为 BeanDefinition
  • 编程式注入额外的 BeanDefinition
  • BeanDefinition 的后置处理

下面我们深入源码。由于小伙伴初次接触源码可能会晕头转向,小册会预先告诉小伙伴接下来的原理会涉及哪些类的哪些地方,小伙伴们可以提前预备好,不至于 “惊慌失措” 。

1. 加载xml配置文件

来,跟着小册来到 LifecycleSourceXmlApplication 的测试代码:

public static void main(String[] args) throws Exception {
    ClassPathXmlApplicationContext ctx = new ClassPathXmlApplicationContext();
    ctx.setConfigLocation("lifecycle/bean-source.xml");

1.1 保存配置文件路径

这里 xml 配置文件的加载会使用 ClassPathXmlApplicationContext 的 setConfigLocation 方法,点进去可以发现它只是在 AbstractRefreshableConfigApplicationContext 中,给 configLocations 设置了配置文件的路径存放而已。

通过源码,也能看出来最终是将传入的路径切分,并顺序存入 configLocations 中:(关键注释已标注在源码中)

public void setConfigLocation(String location) {
    // 切分配置文件路径
    setConfigLocations(StringUtils.tokenizeToStringArray(location, CONFIG_LOCATION_DELIMITERS));
}

public void setConfigLocations(@Nullable String... locations) {
    if (locations != null) {
        // assert ......
        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;
    }
}

Debug 时,也能发现,它最终把测试代码中设置的 xml 配置文件的路径都保存了。

Spring IOC原理-Bean的生命周期-BeanDefinition阶段

1.2 加载配置文件并解析

当执行 ApplicationContext 的 refresh 方法后,会开始刷新(初始化)IOC 容器,这里面有 13 个步骤,前面已经看过不少次了:

public void refresh() throws BeansException, IllegalStateException {
    synchronized (this.startupShutdownMonitor) {
        prepareRefresh();
        // 2. 初始化BeanFactory
        ConfigurableListableBeanFactory beanFactory = obtainFreshBeanFactory();
        prepareBeanFactory(beanFactory);
        
        // ......
    }
}

这里面我把第 2 步 obtainFreshBeanFactory 方法标注出来了,加载配置文件并解析的动作就在这里面,我们可以来研究一下。

protected ConfigurableListableBeanFactory obtainFreshBeanFactory() {
    refreshBeanFactory();
    return getBeanFactory();
}

这个方法只有两个动作:刷新 BeanFactory ,然后获取它。毫无疑问,刷新的动作中包含配置文件的加载和解析,我们继续往里看。

refreshBeanFactory 方法是 AbstractApplicationContext 定义的抽象方法,很明显这里又是模板方法模式的体现了。由于当前我们正在研究的是基于 xml 配置文件的 ApplicationContext ,所以要进入 AbstractRefreshableApplicationContext 中:

protected final void refreshBeanFactory() throws BeansException {
    // 存在BeanFactory则先销毁
    if (hasBeanFactory()) {
        destroyBeans();
        closeBeanFactory();
    }
    try {
        // 创建BeanFactory
        DefaultListableBeanFactory beanFactory = createBeanFactory();
        beanFactory.setSerializationId(getId());
        customizeBeanFactory(beanFactory);
        // 【1.3】加载配置文件
        loadBeanDefinitions(beanFactory);
        this.beanFactory = beanFactory;
    } // catch ......
}

看一下源码的大体流程,在前面 15 章中我们已经了解到,基于 xml 配置文件的 ApplicationContext 可以反复刷新加载 IOC 容器,所以此处有已经存在的判断:如果当前 ApplicationContext 中组合的 BeanFactory 已经存在,则销毁原来的 BeanFactory ,并重新创建。

关注重点,这里面加载配置文件的动作是 loadBeanDefinitions 。这个方法相当复杂且困难,小册会选取最重要的部分来解析。

1.3 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));

    initBeanDefinitionReader(beanDefinitionReader);
    // 使用xml解析器 解析xml配置文件
    loadBeanDefinitions(beanDefinitionReader);
}

注意这里面,它创建了一个 XmlBeanDefinitionReader ,小伙伴们一定不陌生吧,它在第 14 章就出现过,我们说它就是加载和解析 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 ,一个是处理指定好的配置文件资源路径。由于测试代码中并没有直接指定 Resource ,故此处主要研究第 8 行的 loadBeanDefinitions(configLocations) 。

Debug 至此处,同样也能发现 reader 与 configLocations 都准备好了:

Spring IOC原理-Bean的生命周期-BeanDefinition阶段

1.4 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 ,它才是真正干活的,所以看它就完事了。

1.5 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 ......
}

一上来又是一个 do 开头的方法,得了,我就看你。。。诶等一下,doLoadDocument 这很明显是解析文档吧,这我们也没必要看吧(也看不懂),重点是下面的那句 registerBeanDefinitions ,这才是我们最关心的吧!

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 方法(不再是 XmlBeanDefinitionReader 的方法了):

public void registerBeanDefinitions(Document doc, XmlReaderContext readerContext) {
    this.readerContext = readerContext;
    doRegisterBeanDefinitions(doc.getDocumentElement());
}

又又又是这个套路!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 就可以。

1.6 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 ,这才是我们要关注的。

这个方法一进来的时候,我们在此 Debug 停一下,可以发现它已经是解析并封装成 Element 的形式了,而且根节点是 <beans> ,它还有几个默认属性等等,我们都比较熟悉了:

Spring IOC原理-Bean的生命周期-BeanDefinition阶段

OK ,继续回到源码,源码中可以看到,每次循环出来的 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> 标签!

1.7 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 ......
        // Send registration event.
        getReaderContext().fireComponentRegistered(new BeanComponentDefinition(bdHolder));
    }
}

可以发现,整个动作一气呵成,其中第一个步骤会把 xml 元素封装为 BeanDefinitionHolder ,且不说 holder 是干嘛用,只从名字上就能知道,它内部肯定组合了一个 BeanDefinition 。

Debug 至此,可以发现,这个 Element 中已经包含了一个 <bean> 标签中定义的那些属性了:

Spring IOC原理-Bean的生命周期-BeanDefinition阶段

不过源码是如何将 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;
}

虽说源码篇幅比较长,但总体还是比较容易理解和接受的,而且每一步干的活也都容易看明白。不过看完这段源码之后,小伙伴们可能会疑惑:只有 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 (它的底层就是第 24 章提到的 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 了。

1.7.1 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 帮它持有。

1.8 小结

简单总结一下这个流程吧:首先 ClassPathXmlApplicationContext 在 refresh 之前,会指定传入的 xml 配置文件的路径,执行 refresh 方法时,会初始化 BeanFactory ,触发 xml 配置文件的读取、加载和解析。其中 xml 的读取需要借助 XmlBeanDefinitionReader ,解析 xml 配置文件则使用 DefaultBeanDefinitionDocumentReader ,最终解析 xml 中的元素,封装出 BeanDefinition ,最后注册到 BeanDefinitionRegistry 。


2. 加载注解配置类

相比较于 xml 配置文件,注解配置类的加载时机会晚一些,它用到了一个至关重要的 BeanDefinitionRegistryPostProcessor ,而且无论如何,这个后置处理器都是最最优先执行的,它就是 ConfigurationClassPostProcessor 。

下面我们还是通过实例来研究注解配置类的加载机制(注意此处要换用 LifecycleSourceAnnotationApplication 了哦)。

2.1 BeanDefinitionRegistryPostProcessor的调用时机

还是回到 AbstractApplicationContext 的 refresh 方法中,这次我们要看的是 BeanFactoryPostProcessor 和 BeanDefinitionRegistryPostProcessor 的执行时机,而它们的执行都在下面所示的第 5 步 invokeBeanFactoryPostProcessors 中执行:

public void refresh() throws BeansException, IllegalStateException {
    synchronized (this.startupShutdownMonitor) {
        // ......
        try {
            postProcessBeanFactory(beanFactory);
            // 5. 执行BeanFactoryPostProcessor
            invokeBeanFactoryPostProcessors(beanFactory);
            registerBeanPostProcessors(beanFactory);
            // ......
        }
        // catch finally .....
    }
}

进来这个方法,发现核心的方法就一句话:

protected void invokeBeanFactoryPostProcessors(ConfigurableListableBeanFactory beanFactory) {
    // 交给代理执行
    PostProcessorRegistrationDelegate.invokeBeanFactoryPostProcessors(beanFactory, getBeanFactoryPostProcessors());

    // 下面是支持AOP的部分(暂时不读)
}

好吧,它又是交给一个 Delegate 执行,那就进去看这个方法的实现吧。

2.2 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 ......
}

用简单的语言概括,这个方法的执行机制如下:

  1. 执行 BeanDefinitionRegistryPostProcessor 的 postProcessBeanDefinitionRegistry 方法
    1. 执行实现了 PriorityOrdered 接口的 BeanDefinitionRegistryPostProcessor
    2. 执行实现了 Ordered 接口的 BeanDefinitionRegistryPostProcessor
    3. 执行普通的 BeanDefinitionRegistryPostProcessor
  2. 执行 BeanDefinitionRegistryPostProcessor 的 postProcessBeanFactory 方法

    ​ 同上

  3. 执行BeanFactoryPostProcessor 的 postProcessBeanFactory 方法

    ​ 同上

这个方法的更详细解读,可参考《SpringBoot 小册》第 12 章 5.1 节,那里面解释的更加详细呦。

在这个长长的方法中,第一个环节它会执行所有实现了 PriorityOrdered 接口的 BeanDefinitionRegistryPostProcessor ,这里面第一个执行的处理器就是 ConfigurationClassPostProcessor ,咱跟过去看一看。

2.3 ConfigurationClassPostProcessor的处理

直接定位到 postProcessBeanDefinitionRegistry 方法吧:

public void postProcessBeanDefinitionRegistry(BeanDefinitionRegistry registry) {
    int registryId = System.identityHashCode(registry);
    // check throw ex ......
    this.registriesPostProcessed.add(registryId);

    // 【解析配置类】
    processConfigBeanDefinitions(registry);
}

可以发现,在这个方法的最后一行,就是解析配置类中定义的 bean ,并封装为 BeanDefinition 。

进入超难领域前的 “按摩” 提醒:processConfigBeanDefinitions 方法的内容超级复杂哦(不亚于上面的 xml 配置文件加载),考虑到前面的 SpringBoot 小册中对该部分流程没有全部剖析( boot 的小册中对于 IOC 更注重整体应用和容器的生命周期),所以我们在这里完整的研究一遍配置类的加载原理

进入 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());

    // 一些额外的处理 ......
}

其实如果小伙伴从上往下看的话,应该可以意识到,其实也没那么难吧(当然没那么难,难的在 parse 和 loadBeanDefinitions 里头)。不过这里面的前置动作还是要注意一下,它初始化了一个 ConfigurationClassParser ,这个家伙是用来解析注解配置类的核心 API 。

一大堆前戏都做足了,下面就可以进入 ConfigurationClassParser 的 parse 方法了。

2.4 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 方法,这个东西我们完全没见过,这里有必要说明一下。

2.4.1 ImportSelector的扩展

在 SpringFramework 4.0 中,ImportSelector 多了一个子接口:DeferredImportSelector ,它的执行时机比 ImportSelector 更晚,它会在注解配置类的所有解析工作完成后才执行(其实上面的源码就已经解释了这个原理)。

一般情况下,DeferredImportSelector 会跟 @Conditional 注解配合使用,完成条件装配

2.4.2 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 条件装配的处理也会更有利,所以这个设计还是不错的。

2.5 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 方法了,那就废话不多说,直接莽进去就完事了。

2.6 doProcessConfigurationClass – 解析配置类

又高能!这个方法又是好长呀!不过这里面的部分几乎都有大用途哦,我们分解着来看吧。

2.6.1 处理@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 递归解析哦。那好吧,这里面的逻辑也不复杂,扫一眼过去就得了,不要浪费太多时间。

2.6.2 处理@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 的部分,整体逻辑也是比较简单的,咱就不深入研究咯(主要关注 bean 相关的东西哈)。

2.6.3 处理@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));
}

顺序走下来,大概这个方法只干了三件事情:

  1. 构造 ClassPathBeanDefinitionScanner ,并封装 @ComponentScan 注解中的属性
  2. 整理要进行包扫描的 basePackages ,以及 include 和 exclude 的过滤器
  3. 执行包扫描的动作

前面两个步骤都是准备动作,真正的包扫描那还得看 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 的处理也就结束了。

2.6.4 处理@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 、普通类 / 配置类都做了处理,并递归解析其中存在的配置类,整体并不复杂,小伙伴们看一看有个印象即可,重要的是记住它们处理的位置,以便日后出现问题时排错定位。

2.6.5 处理@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 方法嘛,过会我们看看它就知道了。

2.6.6 处理@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 注解标注的方法。

Debug 到这里,可以发现此处确实把配置类中的 person() 方法取了出来:

Spring IOC原理-Bean的生命周期-BeanDefinition阶段

不过这里可能会有小伙伴产生疑惑:明明反射就可以拿到这些被 @Bean 注解标注的方法,但是中间的读取部分都把 ASM (读取字节码的技术)搬出来了,为什么要如此的大动干戈呢?哎,这里我们要多解释一个点了:**使用 JVM 的标准反射,在不同的 JVM 、或者同一个 JVM 上的不同应用中,返回的方法列表顺序可能是不同的。**简言之,JVM 的标准反射不保证方法列表返回的顺序一致。所以,想要保证程序在任何 JVM 上、任何应用中,加载同一个 .class 文件的方法列表都返回相同的顺序,那就只能读取字节码了,而读取字节码的技术,Spring 选择了 ASM 。

所以,这里 Spring 使用 ASM 读取字节码的目的,是为了保证加载配置类中 @Bean 方法的从上到下的顺序与源文件 .java 中一致

2.6.7 处理父接口

    // ............
    // 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 ,所以这里只是解析动作而已。

2.6.8 父类的返回

    // ............
    // 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;
}

终于看到最后一部分了,因为上面的解析处理逻辑都看完了,还剩下最后一个部分。如果配置类存在父类的话,父类也应该一起加载,所以这里会取到配置类的父类,并继续递归处理。逻辑相对的不算复杂,咱就不深入研究了。

2.7 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 个部分,咱还是分别来看。

2.7.1 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 ......
}

2.7.2 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 → 封装信息 → 注册进 BeanDefinitionRegistry 。最下面的部分,那些处理 @Bean 的属性、额外的注解解析都比较简单了,小伙伴们可以自行借助 IDE 去看看,小册就不展开解释了。

不过这里面有一个还蛮关键的部分,要给小伙伴们解释一下,就是上面的这个 metadata.isStatic() ,它的判断逻辑下面,会给 BeanDefinition 封装两个属性:setBeanClassName / setFactoryBeanName 、setUniqueFactoryMethodName ,它们俩分别指定了当前 @Bean 方法所在的配置类,以及方法名。小伙伴们可以先猜想一下,封装它的作用是什么呢?

回想一下前面 @Component 注解标注的类形成的 BeanDefinition ,以及 xml 配置文件转换出来的 BeanDefinition 有个什么特点?它们都指定了 bean 的全限定名、属性注入等,而且最终创建的对象一定是通过反射创建。而在注解配置类中的 @Bean 方法是有实际的代码执行,属于编程式创建,无法使用(也不适合用)反射创建 bean 对象,所以为了在后面能正常创建出 bean 对象,此处就需要记录该 bean 的定义源(包含注解配置类和方法名),以保证在创建 bean 对象时,能够使用反射调用该注解配置类的方法,生成 bean 对象并返回

2.7.3 loadBeanDefinitionsFromImportedResources

这部分是解析从注解配置类上取到的 xml 配置文件的路径,有了前面的分析,我们马上就能猜到,它又要用 XmlBeanDefinitionReader 那一套来搞了,点开源码,发现果然如此:

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);
    });
}

很容易理解了吧,里面的套路想必不用小册多解释,小伙伴们自己就已经有很清楚的认识了吧。

2.7.4 loadBeanDefinitionsFromRegistrars

最后一部分是执行 ImportBeanDefinitionRegistrar ,这个就更简单了,既然是接口,那执行它们的话,只需要调用 registerBeanDefinitions 方法就可以吧,进到方法内部,发现真就是这么简单:

private void loadBeanDefinitionsFromRegistrars(Map<ImportBeanDefinitionRegistrar, AnnotationMetadata> registrars) {
    registrars.forEach((registrar, metadata) ->
            registrar.registerBeanDefinitions(metadata, this.registry, this.importBeanNameGenerator));
}

OK ,那到此为止,注解配置类中 BeanDefinition 的注册也就全部理清楚了,顺便我们把整个注解配置类的解析流程和逻辑也都研究了一遍,小伙伴们要做好笔记呀。

2.8 小结

同样总结一下注解配置类的加载与解析过程:注解配置类的解析发生在 BeanDefinitionRegistryPostProcessor 的执行阶段,它对应的核心后置处理器是 ConfigurationClassPostProcessor ,它主要负责两个步骤三件事情:解析配置类、注册 BeanDefinition 。三件事情包括:1) 解析 @ComponentScan 并进行包扫描,实际进行包扫描的组件是 ClassPathBeanDefinitionScanner ;2) 解析配置类中的注解(如 @Import 、@ImportResource 、@PropertySource 等)并处理,工作的核心组件是 ConfigurationClassParser ;3) 解析配置类中的 @Bean 并封装 BeanDefinition ,实际解析的组件是 ConfigurationClassBeanDefinitionReader 。

3. BeanDefinition的后置处理

执行完 ConfigurationClassPostProcessor 之后,在 xml 和配置类中定义的 BeanDefinition 就都解析和准备好了,但是还没有加载进 BeanDefinitionRegistry 中。下面还会有 BeanDefinitionRegistryPostProcessor 和 BeanFactoryPostProcessor 的执行,而它们的执行时机还是上面的 PostProcessorRegistrationDelegate#invokeBeanFactoryPostProcessors 方法中(嗯,还是那个死老长的方法)。

至于这些处理的机制,咱在前面的 28 章 BeanFactoryPostProcessor 章节都讲解过了,如果忘记的小伙伴们记得回去复习哦。

执行完这些后置处理器之后,BeanDefinition 的后置处理也就算结束了。


面试如何回答BeanDefinition部分的生命周期

以下答案仅供参考,可根据个人理解进行实际调整:

首先,bean 的生命周期分为 BeanDefinition 阶段和 bean 实例阶段。

这里多提醒一句,能在 bean 的生命周期中回答出 BeanDefinition 相当重要且关键!

BeanDefinition 阶段分为加载 xml 配置文件、解析注解配置类、编程式构造 BeanDefinition 、BeanDefinition 的后置处理,一共四个部分。

  1. 加载 xml 配置文件 发生在基于 xml 配置文件的 ApplicationContext 中 refresh 方法的 BeanFactory 初始化阶段,此时 BeanFactory 刚刚构建完成,它会借助 XmlBeanDefinitionReader 来加载 xml 配置文件,并使用 DefaultBeanDefinitionDocumentReader 解析 xml 配置文件,封装声明的 <bean> 标签内容并转换为 BeanDefinition 。
  2. 解析注解配置类 发生在 ApplicationContext 中 refresh 方法的 BeanDefinitionRegistryPostProcessor 执行阶段,该阶段首先会执行 ConfigurationClassPostProcessor 的 postProcessBeanDefinitionRegistry 方法。ConfigurationClassPostProcessor 中会找出所有的配置类,排序后依次解析,并借助 ClassPathBeanDefinitionScanner 实现包扫描的 BeanDefinition 封装,借助 ConfigurationClassBeanDefinitionReader 实现 @Bean 注解方法的 BeanDefinition 解析和封装。
  3. 编程式构造 BeanDefinition 也是发生在 ApplicationContext 中 refresh 方法的 BeanDefinitionRegistryPostProcessor 执行阶段,由于 BeanDefinitionRegistryPostProcessor 中包含 ConfigurationClassPostProcessor ,而 ConfigurationClassPostProcessor 会执行 ImportBeanDefinitionRegistrar 的逻辑,从而达到编程式构造 BeanDefinition 并注入到 BeanDefinitionRegistry 的目的;另外,实现了 BeanDefinitionRegistryPostProcessor 的类也可以编程式构造 BeanDefinition ,注入 BeanDefinitionRegistry 。
免责声明:
1.本站所有内容由本站原创、网络转载、消息撰写、网友投稿等几部分组成。
2.本站原创文字内容若未经特别声明,则遵循协议CC3.0共享协议,转载请务必注明原文链接。
3.本站部分来源于网络转载的文章信息是出于传递更多信息之目的,不意味着赞同其观点。
4.本站所有源码与软件均为原作者提供,仅供学习和研究使用。
5.如您对本网站的相关版权有任何异议,或者认为侵犯了您的合法权益,请及时通知我们处理。
火焰兔 » Spring IOC原理-Bean的生命周期-BeanDefinition阶段