Spring源码分析专题 —— IOC容器启动过程(上篇) 2019-07-15

声明1.建议先阅读《Spring源码分析专题 —— 阅读指引》2.强烈建议阅读过程中要参照调用过程图,每篇都有其对应的调用过程图3.写文不易,转载请标明出处

前言

关于 IOC 容器启动的内容很多,我将分上中下三篇讲解,其中上篇相对简单,中篇最为复杂,请大家耐心阅读。

上篇 - 主要是相关基础说明和找到分析入口中篇 - 讲解定位、加载、注册的过程(实例化在依赖注入的章节再讲)下篇 - 细节补充

调用过程图

由于篇幅问题,此处我只放个缩略图,高清大图请点击链接☞ IOC容器启动调用过程图.jpg请务必一边对照图片一边阅读文章。

先放结论

此处先放结论,大家稍微记一记,后边将展开详解

Spring 的启动流程主要是定位 -> 加载 -> 注册 -> 实例化定位 - 获取配置文件路径加载 - 把配置文件读取成 BeanDefinition注册 - 存储 BeanDefinition实例化 - 根据 BeanDefinition 创建实例所谓的IOC容器其实就是 BeanFactory , BeanFactory 是一个接口,有很多对应的实现类IOC容器的关键入口方法是 refresh()Web 应用中使用的容器是 XmlWebApplicationContext ,其类图如下,可以看出最终是一个实现了 BeanFactory 的类

IOC容器源码的入口

我们知道 Spring 框架不仅仅是面向 Web 应用,所以 Spring 中对应不同场景有许多 IOC 容器的实现类,其中有简单的也有复杂的,在此我们跳过简单容器的讲解,直接以我们最熟悉、也是最感兴趣的 Java Web 项目下手,寻找其对应的 IOC 容器实现类,同时一口气寻找到 IOC 容器的关键入口方法 refresh() 。

1. 寻找IOC容器实现类

以下是我们熟知的 SpringMVC 项目中 web.xml 的基础配置,其关键是要配置一个 ContextLoaderListener 和一个 DispatcherServlet

<web-app> <context-param> <param-name>contextConfigLocation</param-name> <param-value>classpath:spring.xml</param-value> </context-param> <!-- ContextLoaderListener --> <listener> <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class> </listener> <!-- DispatcherServlet --> <servlet> <description>spring mvc servlet</description> <servlet-name>springMvc</servlet-name> <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class> <init-param> <description>spring mvc</description> <param-name>contextConfigLocation</param-name> <param-value>classpath:spring-mvc.xml</param-value> </init-param> <load-on-startup>1</load-on-startup> </servlet> <servlet-mapping> <servlet-name>springMvc</servlet-name> <url-pattern>*.do</url-pattern> </servlet-mapping></web-app>

我们知道在 Java Web 容器中相关组件的启动顺序是 ServletContext -> listener -> filter -> servlet , listener 是优于 servlet 启动的,所以我们先看一看 ContextLoaderListener 的内容

public class ContextLoaderListener extends ContextLoader implements ServletContextListener { public ContextLoaderListener() { } public ContextLoaderListener(WebApplicationContext context) { super(context); } public void contextInitialized(ServletContextEvent event) { this.initWebApplicationContext(event.getServletContext()); } public void contextDestroyed(ServletContextEvent event) { this.closeWebApplicationContext(event.getServletContext()); ContextCleanupListener.cleanupAttributes(event.getServletContext()); }}

根据 Java Web 容器的规范可知,当 Listener 启动时会调用 contextInitialized 方法,而 ContextLoaderListener 中该方法的内容是继续调用 initWebApplicationContext 方法,于是我们再跟踪 initWebApplicationContext( ContextLoaderListener 是 ContextLoader 的子类,所以其实是调用了父类的 initWebApplicationContext 方法)

public WebApplicationContext initWebApplicationContext(ServletContext servletContext) { if (servletContext.getAttribute(WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE) != null) { throw new IllegalStateException( "Cannot initialize context because there is already " + "a root application context present - check whether " + "you have multiple ContextLoader* definitions in your web.xml!"); } else { Log logger = LogFactory.getLog(ContextLoader.class); servletContext.log("Initializing Spring root WebApplicationContext"); if (logger.isInfoEnabled()) { logger.info("Root WebApplicationContext: initialization started"); } long startTime = System.currentTimeMillis(); try { if (this.context == null) { this.context = this.createWebApplicationContext(servletContext); } . . .}

此处我们关心的是 createWebApplicationContext 方法

protected WebApplicationContext createWebApplicationContext(ServletContext sc) { /** [note-by-leapmie] determineContextClass方法中获取contextClass **/ Class<?> contextClass = determineContextClass(sc); if (!ConfigurableWebApplicationContext.class.isAssignableFrom(contextClass)) { throw new ApplicationContextException("Custom context class [" + contextClass.getName() + "] is not of type [" + ConfigurableWebApplicationContext.class.getName() + "]"); } /** [note-by-leapmie] 根据contextClass返回实例 */ return (ConfigurableWebApplicationContext) BeanUtils.instantiateClass(contextClass);}

从代码可知,方法中的逻辑主要是调用 determineContextClass 获取 contextClass ,然后根据 contextClass 创建 IOC 容器实例。所以, contextClass 的值将是关键。

protected Class<?> determineContextClass(ServletContext servletContext) { String contextClassName = servletContext.getInitParameter(CONTEXT_CLASS_PARAM); if (contextClassName != null) { . . . } else { /** * [note-by-leapmie] * defaultStrategies的值是在本类中的static方法中注入的 * 即该类加载过程中defaultStrategies已经被赋值 * 本类的开始部分有static代码块 * **/ contextClassName = defaultStrategies.getProperty(WebApplicationContext.class.getName()); try { return ClassUtils.forName(contextClassName, ContextLoader.class.getClassLoader()); } catch (ClassNotFoundException ex) { throw new ApplicationContextException( "Failed to load default context class [" + contextClassName + "]", ex); } }}

可以看到, contextClassName 是从 defaultStrategies 中获取的,而关于 defaultStrategies 的赋值需要追溯到 ContextLoader 类中的静态代码块

static { try { /** * [note-by-leapmie] * DEFAULT_STRATEGIES_PATH的值是ContextLoader.properties */ ClassPathResource resource = new ClassPathResource(DEFAULT_STRATEGIES_PATH, ContextLoader.class); defaultStrategies = PropertiesLoaderUtils.loadProperties(resource); } catch (IOException ex) { throw new IllegalStateException("Could not load "ContextLoader.properties": " + ex.getMessage()); }}

defaultStrategies 是从 resource 中获取的参数,而 resource 又是从 DEFAULT_STRATEGIES_PATH 中获取,查看可知 DEFAULT_STRATEGIES_PATH 的值是 ContextLoader.properties ,通过全局查找到ContextLoader.properties文件,其中内容如下

org.springframework.web.context.WebApplicationContext=org.springframework.web.context.support.XmlWebApplicationContext

由此可知, SpringMVC 项目中使用到的 IOC 容器类型是 XmlWebApplicationContext。

2. 寻找关键入口方法refresh()

我们回到 ContextLoader 的 initWebApplicationContext 方法,前边我们说到调用 createWebApplicationContext 方法创建容器,容器创建后我们关注的下一个方法是 configureAndRefreshWebApplicationContext

public WebApplicationContext initWebApplicationContext(ServletContext servletContext) { . . . try { // Store context in local instance variable, to guarantee that // it is available on ServletContext shutdown. if (this.context == null) { /** [note-by-leapmie] 获取SpringIOC容器类型 **/ this.context = createWebApplicationContext(servletContext); } if (this.context instanceof ConfigurableWebApplicationContext) { ConfigurableWebApplicationContext cwac = (ConfigurableWebApplicationContext) this.context; 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 -> // determine parent for root web application context, if any. ApplicationContext parent = loadParentContext(servletContext); cwac.setParent(parent); } /** [note-by-leapmie] 配置和刷新容器 **/ configureAndRefreshWebApplicationContext(cwac, servletContext); } } . . .}

configureAndRefreshWebApplicationContext的代码如下

protected void configureAndRefreshWebApplicationContext(ConfigurableWebApplicationContext wac, ServletContext sc) { 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 String idParam = sc.getInitParameter(CONTEXT_ID_PARAM); if (idParam != null) { wac.setId(idParam); } else { // Generate default id... wac.setId(ConfigurableWebApplicationContext.APPLICATION_CONTEXT_ID_PREFIX + ObjectUtils.getDisplayString(sc.getContextPath())); } } wac.setServletContext(sc); String configLocationParam = sc.getInitParameter(CONFIG_LOCATION_PARAM); if (configLocationParam != null) { wac.setConfigLocation(configLocationParam); } // 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(sc, null); } customizeContext(sc, wac); /** [note-by-leapmie] 调用容器的refresh()方法,此处wac对应的类是XmlWebApplicationContext **/ wac.refresh();}

在这里我们要关注的是最后一行 wac.refresh() ,意思是调用容器的 refresh() 方法,此处我们的容器是XmlWebApplicationContext,对应的 refresh() 在其父类 AbstractApplicationContext

@Override/** 核心过程 **/public void refresh() throws BeansException, IllegalStateException { synchronized (this.startupShutdownMonitor) { // Prepare this context for refreshing. prepareRefresh(); // Tell the subclass to refresh the internal bean factory. /** * obtainFreshBeanFactory方法中会调用loadBeanDefinition方法,用于加载bean的定义 */ 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. /** 初始化所有非lazy-init的bean **/ finishBeanFactoryInitialization(beanFactory); // Last step: publish corresponding event. finishRefresh(); } catch (BeansException ex) { if (logger.isWarnEnabled()) { logger.warn("Exception encountered during context initialization - " + "cancelling refresh attempt: " + ex); } // Destroy already created singletons to avoid dangling resources. destroyBeans(); // Reset "active" flag. cancelRefresh(ex); // Propagate exception to caller. throw ex; } finally { // Reset common introspection caches in Spring"s core, since we // might not ever need metadata for singleton beans anymore... resetCommonCaches(); } }}

至此我们已经找到了关键的入口 refresh() ,我们看一下在调用过程图中我们所处的位置

refresh 方法是 Spring IOC 容器启动过程的核心方法,方法中按顺序调用了好几个命名清晰的方法,其对应的都是 IOC 容器启动过程的关键步骤,更多的细节我们将在下一节继续讲解。

话痨一下大家可能会觉得,在源码分析过程中一个方法中调用了很多方法,例如先执行方法 a() ,再执行方法 b() ,为什么我们直接看方法 b() 而跳过了方法 a() ?在这里我想说的是,Spring的源码量很庞大,如果每个细节都去了解可能一年过去了都看不完,我们应该先关注大流程,其他的细枝末节可以在了解了大流程后再慢慢深入了解。至于为什么是看方法 b() 而跳过方法 a() ,这些都是前人总结的经验与心血,在学习过程中我也是跟着别人的步伐在源码中探索,中间有些缺失的路线我也花费大量时间去踩坑,最后绘制了每一份调用过程图。在本专题中我能确保的是,只要跟着我的步伐,你们不会在源码分析的路上迷路。


本文首发地址:https://blog.leapmie.com/archives/390/

[目录][上一篇]Spring源码分析专题 —— 阅读指引[下一篇]Spring源码分析专题 —— IOC容器启动过程(中篇)


, 1, 0, 9);

Copyright © 2019 ope体育滚球 All Rights Reserved
林峰
地址:海南省海口市龙昆南路89号
全国统一热线:15314499551