一步一步手绘Spring IOC运行时序图一（Spring 核心容器 IOC初始化过程）

相关内容：
架构师系列内容：架构师学习笔记（持续更新）
一步一步手绘Spring IOC运行时序图一（Spring 核心容器 IOC初始化过程）
一步一步手绘Spring IOC运行时序图二（基于XML的IOC容器初始化）
一步一步手绘Spring IOC运行时序图三（基于Annotation的IOC容器初始化）
一步一步手绘Spring DI运行时序图（Spring 自动装配之依赖注入）
一步一步手绘Spring AOP运行时序图（Spring AOP 源码分析）
一步一步手绘Spring MVC运行时序图（Spring MVC原理）

1、Spring 核心之 IOC 容器初体验

IOC 与 DI

IOC（Inversion of Control ）控制反转：所谓控制反转，就是把原先我们代码里面需要实现的对象创建，依赖的代码，反转给容器来帮忙实现。 那么必然的我们需要创建一个容器 ，同时需要一种描述来让容器知道需要创建的对象与对象的关系。这个描述最具体表现就是我们所看到的配置文件。
DI（Dependency Injection）依赖注入： 就是指对象是被动接受依赖类而不是自己主动去找，换句话说就是指对象不是从容器中查找它依赖的类而是在容器实例化对象的时候主动将它依赖的类注入给它。

先从我们自己设计这样一个视角来考虑：
1、对象和对象的关系怎么表示？
可以用 xml，properties 文件等语义化配置文件表示。

2、描述对象关系的文件存放在哪里？
可能是 classpath，filesystem，或者是 URL 网络资源，servletContext 等。

3、不同的配置文件对对象的描述不一样，如标准的，自定义声明式的，如何统一？
在内部需要有一个统一的关于对象的定义，所有外部的描述都必须转化成统一的描述定义。

4、如何对不同的配置文件进行解析？
需要对不同的配置文件语法，采用不同的解析器。

2、 Spring 核心容器类图

BeanFactory

Spring Bean 的创建是典型的工厂模式，这一系列的 Bean 工厂，也即 IOC 容器为开发者管理对象间的依赖关系提供了很多便利和基础服务，在 Spring 中有许多的 IOC 容器的实现供用户选择和使用，其相互关系如下：

其中 BeanFactory 作为最顶层的一个接口类，它定义了 IOC 容器的基本功能规范，BeanFactory 有三个重要的子类：ListableBeanFactory、HierarchicalBeanFactory 和 AutowireCapableBeanFactory。

但是从类图中我们可以发现最终的默认实现类是 DefaultListableBeanFactory，它实现了所有的接口。 那为何要定义这么多层次的接口呢？查阅这些接口的源码和说明发现，每个接口都有它使用的场合，它主要是为了区分在 Spring 内部在操作过程中对象的传递和转化过程时，对对象的数据访问所做的限制。例如 ListableBeanFactory 接口表示这些 Bean 是可列表化的，而 HierarchicalBeanFactory 表示的是这些 Bean 是有继承关系的，也就是每个 Bean 有可能有父 Bean。AutowireCapableBeanFactory 接口定义 Bean 的自动装配规则。这三个接口共同定义了 Bean 的集合、Bean 之间的关系、以及 Bean 行为。最基本的 IOC 容器接口 BeanFactory，来看一下它的源码：

public interface BeanFactory {

   //对FactoryBean的转义定义，因为如果使用bean的名字检索FactoryBean得到的对象是工厂生成的对象，
   //如果需要得到工厂本身，需要转义
   String FACTORY_BEAN_PREFIX = "&";
   //根据bean的名字，获取在IOC容器中得到bean实例
   Object getBean(String name) throws BeansException;
   //根据bean的名字和Class类型来得到bean实例，增加了类型安全验证机制。
   <T> T getBean(String name, @Nullable Class<T> requiredType) throws BeansException;
   Object getBean(String name, Object... args) throws BeansException;
   <T> T getBean(Class<T> requiredType) throws BeansException;
   <T> T getBean(Class<T> requiredType, Object... args) throws BeansException;
   //提供对bean的检索，看看是否在IOC容器有这个名字的bean
   boolean containsBean(String name);
   //根据bean名字得到bean实例，并同时判断这个bean是不是单例
   boolean isSingleton(String name) throws NoSuchBeanDefinitionException;
   boolean isPrototype(String name) throws NoSuchBeanDefinitionException;
   boolean isTypeMatch(String name, ResolvableType typeToMatch) throws NoSuchBeanDefinitionException;
   boolean isTypeMatch(String name, @Nullable Class<?> typeToMatch) throws NoSuchBeanDefinitionException;

   //得到bean实例的Class类型
   @Nullable
   Class<?> getType(String name) throws NoSuchBeanDefinitionException;

   //得到bean的别名，如果根据别名检索，那么其原名也会被检索出来
   String[] getAliases(String name);

}

在BeanFactory 里只对 IOC 容器的基本行为作了定义，根本不关心你的 Bean 是如何定义怎样加载的。
正如我们只关心工厂里得到什么的产品对象，至于工厂是怎么生产这些对象的，这个基本的接口不关心。
而要知道工厂是如何产生对象的，我们需要看具体的IOC 容器实现，Spring提供了许多IOC容器的实现 。 比如GenericApplicationContext ， ClasspathXmlApplicationContext 等 。
ApplicationContext 是Spring提供的一个高级的IOC容器，也是继承了BeanFactory，它除了能够提供 IOC 容器的基本功能外，还为用户提供了以下的附加服务。从 ApplicationContext 接口的实现，我们看出其特点：
1、支持信息源，可以实现国际化。（实现 MessageSource 接口）
2、访问资源。(实现 ResourcePatternResolver 接口)
3、支持应用事件。(实现 ApplicationEventPublisher 接口)

BeanDefinition

SpringIOC 容器管理了我们定义的各种 Bean 对象及其相互的关系，Bean 对象在 Spring 实现中是以 BeanDefinition 来描述的。 BeanDefinition 主要是用来描述 Bean，其存储了 Bean 的相关信息，Spring 实例化 Bean 时需读取该 Bean 对应的 BeanDefinition。BeanDefinition 整体可以分为两类，一类是描述通用的 Bean，还有一类是描述注解形式的 Bean。一般前者在 XML 时期定义 <bean‘> 标签以及在 Spring 内部使用较多，而现今我们大都使用后者，通过注解形式加载 Bean。
其继承体系如下：

BeanDefinitionReader

Bean 的解析过程非常复杂，功能被分的很细，因为这里需要被扩展的地方很多，必须保证有足够的灵活性，以应对可能的变化。Bean 的解析主要就是对 Spring 配置文件的解析。这个解析过程主要通过BeanDefintionReader 来完成，最后看看 Spring 中 BeanDefintionReader 的类结构图：

通过 BeanFactory，BeanDefinition，BeanDefinitionReader 完成了IOC的初始化。

3、 Web IOC 容器

从大家最熟悉的 DispatcherServlet 开始，我们最先想到的还是 DispatcherServlet 的 init()方法。在 DispatherServlet 中并没有找到 init()方法。往上追索在其父类HttpServletBean 中找到了我们想要的 init()方法，如下：

@Override
public final void init() throws ServletException {
   if (logger.isDebugEnabled()) {
      logger.debug("Initializing servlet '" + getServletName() + "'");
   }


   // Set bean properties from init parameters.
   PropertyValues pvs = new ServletConfigPropertyValues(getServletConfig(), this.requiredProperties);
   if (!pvs.isEmpty()) {
      try {
         //定位资源
         BeanWrapper bw = PropertyAccessorFactory.forBeanPropertyAccess(this);
         //加载配置信息
         ResourceLoader resourceLoader = new ServletContextResourceLoader(getServletContext());
         bw.registerCustomEditor(Resource.class, new ResourceEditor(resourceLoader, getEnvironment()));
         initBeanWrapper(bw);
         bw.setPropertyValues(pvs, true);
      }
      catch (BeansException ex) {
         if (logger.isErrorEnabled()) {
            logger.error("Failed to set bean properties on servlet '" + getServletName() + "'", ex);
         }
         throw ex;
      }
   }


   // Let subclasses do whatever initialization they like.
   initServletBean();


   if (logger.isDebugEnabled()) {
      logger.debug("Servlet '" + getServletName() + "' configured successfully");
   }
}

在init()方法中，真正完成初始化容器动作的逻辑其实在 initServletBean()方法中，继续跟进initServletBean()中的代码在 FrameworkServlet 类中：

@Override
protected final void initServletBean() throws ServletException {
   getServletContext().log("Initializing Spring FrameworkServlet '" + getServletName() + "'");
   if (this.logger.isInfoEnabled()) {
      this.logger.info("FrameworkServlet '" + getServletName() + "': initialization started");
   }
   long startTime = System.currentTimeMillis();


   try {


      this.webApplicationContext = initWebApplicationContext();
      initFrameworkServlet();
   }
   catch (ServletException ex) {
      this.logger.error("Context initialization failed", ex);
      throw ex;
   }
   catch (RuntimeException ex) {
      this.logger.error("Context initialization failed", ex);
      throw ex;
   }


   if (this.logger.isInfoEnabled()) {
      long elapsedTime = System.currentTimeMillis() - startTime;
      this.logger.info("FrameworkServlet '" + getServletName() + "': initialization completed in " +
            elapsedTime + " ms");
   }
}

在上面的代码中终于看到了我们似曾相识的代码 initWebAppplicationContext()，继续跟进：

protected WebApplicationContext initWebApplicationContext() {


   //先从ServletContext中获得父容器WebApplicationContext
   WebApplicationContext rootContext =
         WebApplicationContextUtils.getWebApplicationContext(getServletContext());
   //声明子容器
   WebApplicationContext wac = null;


   //建立父、子容器之间的关联关系
   if (this.webApplicationContext != null) {
      // A context instance was injected at construction time -> use it
      wac = this.webApplicationContext;
      if (wac instanceof ConfigurableWebApplicationContext) {
         ConfigurableWebApplicationContext cwac = (ConfigurableWebApplicationContext) wac;
         if (!cwac.isActive()) {
            // The context has not yet been refreshed -> provide services such as
            // setting the parent context, setting the application context id, etc
            if (cwac.getParent() == null) {
               // The context instance was injected without an explicit parent -> set
               // the root application context (if any; may be null) as the parent
               cwac.setParent(rootContext);
            }
            //这个方法里面调用了AbstractApplicationContext的refresh()方法
            //模板方法，规定IOC初始化基本流程
            configureAndRefreshWebApplicationContext(cwac);
         }
      }
   }
   //先去ServletContext中查找Web容器的引用是否存在，并创建好默认的空IOC容器
   if (wac == null) {
      // No context instance was injected at construction time -> see if one
      // has been registered in the servlet context. If one exists, it is assumed
      // that the parent context (if any) has already been set and that the
      // user has performed any initialization such as setting the context id
      wac = findWebApplicationContext();
   }
   //给上一步创建好的IOC容器赋值
   if (wac == null) {
      // No context instance is defined for this servlet -> create a local one
      wac = createWebApplicationContext(rootContext);
   }


   //触发onRefresh方法
   if (!this.refreshEventReceived) {
      // Either the context is not a ConfigurableApplicationContext with refresh
      // support or the context injected at construction time had already been
      // refreshed -> trigger initial onRefresh manually here.
      onRefresh(wac);
   }


   if (this.publishContext) {
      // Publish the context as a servlet context attribute.
      String attrName = getServletContextAttributeName();
      getServletContext().setAttribute(attrName, wac);
      if (this.logger.isDebugEnabled()) {
         this.logger.debug("Published WebApplicationContext of servlet '" + getServletName() +
               "' as ServletContext attribute with name [" + attrName + "]");
      }
   }


   return wac;
}

protected void configureAndRefreshWebApplicationContext(ConfigurableWebApplicationContext wac) {
   if (ObjectUtils.identityToString(wac).equals(wac.getId())) {
      // The application context id is still set to its original default value
      // -> assign a more useful id based on available information
      if (this.contextId != null) {
         wac.setId(this.contextId);
      }
      else {
         // Generate default id...
         wac.setId(ConfigurableWebApplicationContext.APPLICATION_CONTEXT_ID_PREFIX +
               ObjectUtils.getDisplayString(getServletContext().getContextPath()) + '/' + getServletName());
      }
   }


   wac.setServletContext(getServletContext());
   wac.setServletConfig(getServletConfig());
   wac.setNamespace(getNamespace());
   wac.addApplicationListener(new SourceFilteringListener(wac, new ContextRefreshListener()));


   // The wac environment's #initPropertySources will be called in any case when the context
   // is refreshed; do it eagerly here to ensure servlet property sources are in place for
   // use in any post-processing or initialization that occurs below prior to #refresh
   ConfigurableEnvironment env = wac.getEnvironment();
   if (env instanceof ConfigurableWebEnvironment) {
      ((ConfigurableWebEnvironment) env).initPropertySources(getServletContext(), getServletConfig());
   }


   postProcessWebApplicationContext(wac);
   applyInitializers(wac);
   wac.refresh();
}

从上面的代码中可以看出，在 configAndRefreshWebApplicationContext()方法中，调用AbstractApplicationContext的 refresh()方法，这个是真正启动 IOC 容器的入口。IOC 容器初始化以后，最后调用了DispatcherServlet 的 onRefresh()方法，在 onRefresh()方法中又是直接调用 initStrategies()方法初始化 SpringMVC 的九大组件：

@Override
protected void onRefresh(ApplicationContext context) {
   initStrategies(context);
}


/**
* Initialize the strategy objects that this servlet uses.
* <p>May be overridden in subclasses in order to initialize further strategy objects.
*/
//初始化策略
protected void initStrategies(ApplicationContext context) {
   //多文件上传的组件
   initMultipartResolver(context);
   //初始化本地语言环境
   initLocaleResolver(context);
   //初始化模板处理器
   initThemeResolver(context);
   //handlerMapping
   initHandlerMappings(context);
   //初始化参数适配器
   initHandlerAdapters(context);
   //初始化异常拦截器
   initHandlerExceptionResolvers(context);
   //初始化视图预处理器
   initRequestToViewNameTranslator(context);
   //初始化视图转换器
   initViewResolvers(context);
   //
   initFlashMapManager(context);
}

Spring IOC容器初始化三部曲

基于XML的IOC容器初始化（定位、加载和注册）

步骤： 一步一步手绘Spring IOC运行时序图（基于XML的IOC容器初始化）

基于Annotation 的IOC容器初始化（定位、加载和注册）

步骤： 一步一步手绘Spring IOC运行时序图三（基于Annotation的IOC容器初始化）

4、IOC 容器初始化小结

通过上面的代码，总结一下 IOC 容器初始化的基本步骤：
1、初始化的入口在容器实现中的 refresh()调用来完成。
2、对 Bean 定义载入 IOC 容器使用的方法是 loadBeanDefinition()。
其中的大致过程如下：通过 ResourceLoader 来完成资源文件位置的定位，DefaultResourceLoader是默认的实现，同时上下文本身就给出了 ResourceLoader 的实现，可以从类路径，文件系统,URL 等方式来定为资源位置。如果是 XmlBeanFactory 作为 IOC 容器，那么需要为它指定 Bean 定义的资源，也就是说 Bean 定义文件 时通过抽象成 Resource 来被 IOC 容器处理的 ， 容器通过BeanDefinitionReader 来完成定义信息的解析和 Bean 信息的注册, 往往使用的是 XmlBeanDefinitionReader 来解析 Bean 的 XML 定义文件 - 实际的处理过程是委托给BeanDefinitionParserDelegate 来完成的，从而得到 bean 的定义信息，这些信息在 Spring 中使用
BeanDefinition对象来表示-这个名字可以让我们想到loadBeanDefinition(),registerBeanDefinition()这些相关方法。它们都是为处理 BeanDefinitin 服务的，容器解析得到 BeanDefinition 以后，需要把它在 IOC 容器中注册，这由 IOC 实现 BeanDefinitionRegistry 接口来实现。注册过程就是在 IOC 容器内部维护的一个 HashMap 来保存得到的 BeanDefinition 的过程。这个 HashMap 是 IOC 容器持有Bean 信息的场所，以后对 Bean 的操作都是围绕这个 HashMap 来实现的。
然后我们就可以通过 BeanFactory 和 ApplicationContext 来享受到 Spring IOC 的服务了,在使用 IOC容器的时候，我们注意到除了少量粘合代码，绝大多数以正确 IOC 风格编写的应用程序代码完全不用关心如何到达工厂，因为容器将把这些对象与容器管理的其他对象钩在一起。基本的策略是把工厂放到已知的地方，最好是放在对预期使用的上下文有意义的地方，以及代码将实际需要访问工厂的地方。Spring本身提供了对声明式载入 web 应用程序用法的应用程序上下文,并将其存储在 ServletContext 中的框架实现。

以下是容器初始化全过程的时序图：