【原】SpringIOC源码解析（8）—— 注解配置的资源定位、加载、解析、注册全链路概览

在DefaultListableBeanFactory的registerBeanDefinition方法中的打上断点，Entrance程序入口换成：

AnnotationConfigApplicationContext applicationContext = new AnnotationConfigApplicationContext(Entrance.class);

源码：阅读Spring源码第一步：源码编译与创建调试入口

注解容器启动时会有一些系统自带的BeanDefinition注册到系统中。这次的调用栈比先前xml的调用栈要浅：

入口是调用了AnnotationConfigApplicationContext的构造函数：

public AnnotationConfigApplicationContext(Class<?>... componentClasses) {
   // 调用默认无参构造器，主要初始化AnnotatedBeanDefinitionReader以
   // 及路径扫描器ClassPathBeanDefinitionScanner
   this();
   // 把传入的Class进行注册，Class既可以有@Configuration注解，也可以没有@Configuration注解
   // 如何注册委托给了 org.springframework.context.annotation.AnnotatedBeanDefinitionReader.register方法
   // 包装传入的Class 生成 BeanDefinition，注册到BeanDefinitionRegistry
   register(componentClasses);
   refresh();
}

在this()的时候，系统自带的BeanDefinition实例已经开始往DefaultListableBeanFactory中注册了

前面xml方式是在refresh()的时候才会去做注册

进入到this()里：

public AnnotationConfigApplicationContext() {
   this.reader = new AnnotatedBeanDefinitionReader(this);
   this.scanner = new ClassPathBeanDefinitionScanner(this);
}

  在真正执行的构造函数里，会初始化两个成员变量reader和scanner，reader和前面的 XMLBeanDefinition 一样就是用来解析相应的配置资源，并解析出相应的 BeanDefinition 实例，再最终将这些实例注册到 DefaultListableBeanFactory 的容器里面。构造方法传入的参数this是AnnotationConfigApplicationContext实例本身；scanner就是对package进行扫描的扫描器。

  小括号里的this展开之后会发现有一个内置的beanFactory，这时已经创建出来了，它是DefaultListableBeanFactory实例，前面xml方式中它是在refresh()方法中才创建出来的实例，所以注解的内置容器是先于xml创建出来的，之所以要提前创建出来是因为注解容器启动时会有一些系统自带的BeanDefinition注册到系统中，所以要先创建出来DefaultListableBeanFactory实例以提供对这些系统BeanDefinition的注册。

  由于会注册系统BeanDefinition，所以DefaultListableBeanFactory的registerBeanDefinition方法肯定会多次执行，多Resume Problem几次就会发现出现了熟悉的我们自定义的entrance实例了

  由于Entrance是被@Configuration标记的，所以在执行

AnnotationConfigApplicationContext applicationContext = new AnnotationConfigApplicationContext(Entrance.class);

时也会被注册到容器里，再进一步会发现是通过register来将其注册到容器里

register主要就是注册被@Configuration标记的业务类，再往上查看栈：

@Override
public void register(Class<?>... componentClasses) {
   Assert.notEmpty(componentClasses, "At least one component class must be specified");
   this.reader.register(componentClasses);
}

---

这里的this.reader指的是AnnotationBeanDefinitionReader，进入这个类的源码会发现，它并不属于BeanDefinitionReader的体系，它是专门负责处理注解相关的BeanDefinition

  这样做是为了区分注解和其他配置的不同。它里面也有BeanDefinitionRegistry实例以委托其将AnnotationBeanDefinition实例给注册到容器里。

---

  继续通过调用栈前进，register方法在判空之后会去遍历被@Configuration标记的类，并一一去做注册处理

public void register(Class<?>... componentClasses) {
   for (Class<?> componentClass : componentClasses) {
      registerBean(componentClass);
   }
}

再往前一步就会发现do方法了：

public void registerBean(Class<?> beanClass) {
   doRegisterBean(beanClass, null, null, null, null);
}

进入到do方法里：
  首先就是用AnnotatedGenericBeanDefinition将对应的class对象给包装起来，之后就是处理定义在类上的其他注解，这些注解就和 bean 标签定义的属性一样

处理完注解之后：

// 用 BeanDefinitionHolder 包装 BeanDefinition
BeanDefinitionHolder definitionHolder = new BeanDefinitionHolder(abd, beanName);
// 此行代码与动态代理和scope注解有关，主要看看是否依照Spring的scope生成动态代理对象
// 但是在本案例中没有做任何操作，只是返回了传入的 definitionHolder
definitionHolder = AnnotationConfigUtils.applyScopedProxyMode(scopeMetadata, definitionHolder, this.registry);
// 向容器注册扫描到的Bean
BeanDefinitionReaderUtils.registerBeanDefinition(definitionHolder, this.registry);

之后就和xml一样，来到BeanDefinitionReaderUtils里面去调用registerBeanDefinition方法进行注册：

---

接下来看一下不是被@Configuration标记的类，比如WelcomeController就是被@Controller修饰的

此时的调用栈也更深，说明做了更多的处理：

这一类的bean是在AnnotationConfigApplicationContext构造方法的refresh()方法调用时才被注册进来：

和xml一样，调用的是AbstractApplicationContext中的refresh()方法，只不过xml调用的是

ConfigurableListableBeanFactory beanFactory = obtainFreshBeanFactory();

这里调用的是

invokeBeanFactoryPostProcessors(beanFactory);

也就是容器调用其后置处理器时触发对普通的BeanDefinition的注册。

再进一步：

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

   // Detect a LoadTimeWeaver and prepare for weaving, if found in the meantime
   // (e.g. through an @Bean method registered by ConfigurationClassPostProcessor)
   if (beanFactory.getTempClassLoader() == null && beanFactory.containsBean(LOAD_TIME_WEAVER_BEAN_NAME)) {
      beanFactory.addBeanPostProcessor(new LoadTimeWeaverAwareProcessor(beanFactory));
      beanFactory.setTempClassLoader(new ContextTypeMatchClassLoader(beanFactory.getBeanClassLoader()));
   }
}

  发现注册源自于PostProcessorRegistrationDelegate调用其静态方法invokeBeanFactoryPostProcessors，同时传入的参数beanFactory是DefaultListableBeanFactory实例，这个实例在上面AnnotationConfigApplicationContext的构造函数中调用this()时就创建了，PostProcessorRegistrationDelegate会对BeanFactoryPostProcessor这些容器级别的后置处理器进行调用。

进一步进入到invokeBeanFactoryPostProcessors方法中，发现该方法非常长，除了处理参数中传入的容器级别的后置处理器列表之外，还会尝试从beanFactory中获取已经注册的后置处理器，然后将他们merge到一起并做统一的处理：

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

并且容器级别的BeanFactoryPostProcessor分为两类：BeanDefinitionRegistryPostProcessor和BeanFactoryPostProcessor，前者是继承自后者的并且会被优先处理。

  对于同一个类型的BeanDefinitionRegistryPostProcessor，会优先执行实现了PriorityOrdered接口的，将这些实现了该接口的PostProcessor按照优先级依次进行调用；之后再针对实现了Ordered接口的，也是按照Order的优先级进行调用；最后才是去调用没有实现接口的PostProcessor。

  执行BeanDefinitionRegistryPostProcessor时， 会调用

invokeBeanDefinitionRegistryPostProcessors(currentRegistryProcessors, registry);

之后才会调用

invokeBeanFactoryPostProcessors(registryProcessors, beanFactory);

根据调用栈，这里主要是调用了：

再往前深入一层：

private static void invokeBeanDefinitionRegistryPostProcessors(
      Collection<? extends BeanDefinitionRegistryPostProcessor> postProcessors, BeanDefinitionRegistry registry) {

   for (BeanDefinitionRegistryPostProcessor postProcessor : postProcessors) {
      postProcessor.postProcessBeanDefinitionRegistry(registry);
   }
}

这里会调用每一个BeanDefinitionRegistryPostProcessor 的 postProcessBeanDefinitionRegistry 方法：

@Override
public void postProcessBeanDefinitionRegistry(BeanDefinitionRegistry registry) {
   int registryId = System.identityHashCode(registry);
   if (this.registriesPostProcessed.contains(registryId)) {
      throw new IllegalStateException(
            "postProcessBeanDefinitionRegistry already called on this post-processor against " + registry);
   }
   if (this.factoriesPostProcessed.contains(registryId)) {
      throw new IllegalStateException(
            "postProcessBeanFactory already called on this post-processor against " + registry);
   }
   this.registriesPostProcessed.add(registryId);

   processConfigBeanDefinitions(registry);
}

首先为每一个registry对象生成一个id，和内存中的id进行比对，避免同一个后置处理器调用了两次同样的registry实例里面的注册方法。

再往前一层，这里执行到ConfigurationClassPostProcessor的processConfigBeanDefinitions方法：

方法主要是生成parser类来解析BeanDefinition，并且它解析的是被@Configure标记的entrance类

进入到下一个方法里，此时调用的是ConfigurationClassParser的parse方法：


解析的正是被@Configure标记的Eentrance类

再往前进几步，会调用到ConfigurationClassParser的doProcessConfigurationClass方法

这个方法会轮询AnnotationAttributes实例componentScan，componentScan中存储的正是我们要扫描的package

  这个方法会去解析Entrance的注解标签属性，这里主要就是解析Entrance的@ComponentScan("com.wjw")，然后根据basepackage去扫描package路径里被Controller、Service、Repository、Component等修饰的类，然后解析这些类注解里的属性。

---

  ClassPathBeanDefinitionScanner的doScan就是去扫描的，将class对象都扫描出来以后就会解析出一个个的BeanDefinition，并最终调用DefaultListableBeanFactory的registerBeanDefinition方法，注册BeanDefinition到容器里。