-- 以下内容均基于2.1.8.RELEASE版本
在《SpringBoot启动过程的分析》系列文章中简要的对SpringBoot整体的启动流程作了梳理，但并未针对诸多细节进行分析。前面的篇章中介绍了从SpringBoot应用程序入口开始执行，一直到上下文刷新完成。期间它加载了所有的类，但是并未直接指出它是在哪个环节加载的类，在加载的过程中如何处理的，以及我们在程序入口所使用的各种注解是如何解析的。本文将对这一疑惑进行解答。
要分析SpringBoot加载类的过程，就必须清晰的知道我们的类到底在哪个环节被加载的。也就是需要定位到加载类的入口，如何来确定这个入口呢？通过阅读可以得知我们可以从ApplicationContext中来通过getBean()方法来获取Bean。那么通过这个入口就能找到存放Bean的地方，找到存放Bean的地方就可以通过调试得知它在什么时候被加载进来，进而确定Bean加载的入口。
找到Bean存放位置这里通过一个简单示例来展示如何寻找Bean存放位置
public static void main(String[] args) { SpringApplication application = new SpringApplication(Example.class); ConfigurableApplicationContext context = application.run(args); // 从容器中获取一个Bean Example2 example2 = context.getBean(Example2.class); }上述代码是一个非常常见的获取Bean的代码，跟踪context.getBean()方法就能找到它存放的位置。
// AbstractApplicationContext.class public <T> T getBean(Class<T> requiredType) throws BeansException { assertBeanFactoryActive(); // 从BeanFactory获取Bean return getBeanFactory().getBean(requiredType); } // DefaultListableBeanFactory.class public <T> T getBean(Class<T> requiredType) throws BeansException { return getBean(requiredType, (Object[]) null); } public <T> T getBean(Class<T> requiredType, @Nullable Object... args) throws BeansException { Assert.notNull(requiredType, "Required type must not be null"); // 可以看到Object对象是这里获取的 Object resolved = resolveBean(ResolvableType.forRawClass(requiredType), args, false); if (resolved == null) { throw new NoSuchBeanDefinitionException(requiredType); } return (T) resolved; } // ...中间省略部分代码 private String[] doGetBeanNamesForType(ResolvableType type, boolean includeNonSingletons, boolean allowEagerInit) { List<String> result = new ArrayList<>(); // ① Check all bean definitions. for (String beanName : this.beanDefinitionNames) { // ...中间省略部分代码 } return StringUtils.toStringArray(result); }① - 一路跟踪下来，可以看到所有的Bean都是在BeanFactory的beanDefinitionNames里面存放。因此关注这个属性何时被赋值就可以找到Bean加载的入口。
确定Bean在哪个环节被加载当得知Bean存放于BeanFactory的beanDefinitionNames属性中，在启动阶段关注这个属性值的变化即可确定它在哪个阶段被赋值，可以肯定的是，它一定是在上下文容器创建完毕之后才会加载，因为容器都没有怎么存放。下图就展示了在创建完毕之后的上下文中Bean的初始化数量。
图: 创建完毕上下文容器
图中所展示的几个Bean是SpringBoot内置的处理器，在SpringBoot启动过程的分析-创建应用程序上下文一文中已经介绍过此处不再次解读。在创建完毕上下文之后有两个重要操作：预处理上下文、刷新上下文。那么初始化类必然就在这两个步骤中间了。首先在刷新上下文处打断点，看看在预处理上下文时是否初始化了其他的Bean。
图：预处理上下文完毕
此处可以发现它多了一个"Example"的类，单并未出现其他新的类，Example类是笔者调试程序的入口，在前面文章中也已经介绍过。因此可以断定，其他的类肯定在刷新上下文容器的时候被加载。快速确定方法就是在刷新上下文容器下方打断点，查看beanDefinitionNames的内容变化。在确定了是刷新容器时加载所有类之后，进入刷新容器的代码，可以看到它也清晰的划分了多个步骤，和上面一样，以每个方法为界，观察bean的加载情况。
public void refresh() throws BeansException, IllegalStateException { synchronized (this.startupShutdownMonitor) { // Prepare this context for refreshing. prepareRefresh(); // Tell the subclass to refresh the internal bean factory. ConfigurableListableBeanFactory beanFactory = obtainFreshBeanFactory(); // Prepare the bean factory for use in this context. prepareBeanFactory(beanFactory); try { // Allows post-processing of the bean factory in context subclasses. postProcessBeanFactory(beanFactory); // Invoke factory processors registered as beans in the context. invokeBeanFactoryPostProcessors(beanFactory); // Register bean processors that intercept bean creation. registerBeanPostProcessors(beanFactory); // Initialize message source for this context. initMessageSource(); // Initialize event multicaster for this context. initApplicationEventMulticaster(); // Initialize other special beans in specific context subclasses. onRefresh(); // Check for listener beans and register them. registerListeners(); // Instantiate all remaining (non-lazy-init) singletons. finishBeanFactoryInitialization(beanFactory); // Last step: publish corresponding event. finishRefresh(); } //...省略部分代码 } }