Spring源碼分析專題 —— IOC容器啟動過程（上篇）

聲明

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容器啟動過程（中篇）

消息：新部落格位址 blog.leapmie.com，以後的更新都會在新部落格首發，感謝支援~（園子視情況更新）