在DefaultListableBeanFactory的registerBeanDefinition方法中的打上断点，Entrance程序入口换成
AnnotationConfigApplicationContext applicationContext = new AnnotationConfigApplicationContext(Entrance.class);
注解容器启动时会有一些系统自带的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到容器里。
