javascript
【Spring源码分析】Bean加载流程概览
代碼入口
之前寫文章都會啰啰嗦嗦一大堆再開始,進入【Spring源碼分析】這個板塊就直接切入正題了。
很多朋友可能想看Spring源碼,但是不知道應當如何入手去看,這個可以理解:Java開發者通常從事的都是Java Web的工作,對于程序員來說,一個Web項目用到Spring,只是配置一下配置文件而已,Spring的加載過程相對是不太透明的,不太好去找加載的代碼入口。
下面有很簡單的一段代碼可以作為Spring代碼加載的入口:
1 ApplicationContext ac = new ClassPathXmlApplicationContext("spring.xml");2 ac.getBean(XXX.class);ClassPathXmlApplicationContext用于加載CLASSPATH下的Spring配置文件,可以看到,第二行就已經可以獲取到Bean的實例了,那么必然第一行就已經完成了對所有Bean實例的加載,因此可以通過ClassPathXmlApplicationContext作為入口。為了后面便于代碼閱讀,先給出一下ClassPathXmlApplicationContext這個類的繼承關系:
大致的繼承關系是如上圖所示的,由于版面的關系,沒有繼續畫下去了,左下角的ApplicationContext應當還有一層繼承關系,比較關鍵的一點是它是BeanFactory的子接口。
最后聲明一下,本文使用的Spring版本為3.0.7,比較老,使用這個版本純粹是因為公司使用而已。
?
ClassPathXmlApplicationContext存儲內容
為了更理解ApplicationContext,拿一個實例ClassPathXmlApplicationContext舉例,看一下里面存儲的內容,加深對ApplicationContext的認識,以表格形式展現:
| 對象名 | 類 ?型 | 作 ?用 | 歸屬類 |
| configResources | Resource[] | 配置文件資源對象數組 | ClassPathXmlApplicationContext |
| configLocations | String[] | 配置文件字符串數組,存儲配置文件路徑 | AbstractRefreshableConfigApplicationContext |
| beanFactory | DefaultListableBeanFactory | 上下文使用的Bean工廠 | AbstractRefreshableApplicationContext |
| beanFactoryMonitor | Object | Bean工廠使用的同步監視器 | AbstractRefreshableApplicationContext |
| id | String | 上下文使用的唯一Id,標識此ApplicationContext | AbstractApplicationContext |
| parent | ApplicationContext | 父級ApplicationContext | AbstractApplicationContext |
| beanFactoryPostProcessors | List<BeanFactoryPostProcessor> | 存儲BeanFactoryPostProcessor接口,Spring提供的一個擴展點 | AbstractApplicationContext |
| startupShutdownMonitor | Object | refresh方法和destory方法公用的一個監視器,避免兩個方法同時執行 | AbstractApplicationContext |
| shutdownHook | Thread | Spring提供的一個鉤子,JVM停止執行時會運行Thread里面的方法 | AbstractApplicationContext |
| resourcePatternResolver | ResourcePatternResolver | 上下文使用的資源格式解析器 | AbstractApplicationContext |
| lifecycleProcessor | LifecycleProcessor | 用于管理Bean生命周期的生命周期處理器接口 | AbstractApplicationContext |
| messageSource | MessageSource | 用于實現國際化的一個接口 | AbstractApplicationContext |
| applicationEventMulticaster | ApplicationEventMulticaster | Spring提供的事件管理機制中的事件多播器接口 | AbstractApplicationContext |
| applicationListeners | Set<ApplicationListener> | Spring提供的事件管理機制中的應用監聽器 | AbstractApplicationContext |
?
ClassPathXmlApplicationContext構造函數
看下ClassPathXmlApplicationContext的構造函數:
1 public ClassPathXmlApplicationContext(String configLocation) throws BeansException {2 this(new String[] {configLocation}, true, null);3 } 1 public ClassPathXmlApplicationContext(String[] configLocations, boolean refresh, ApplicationContext parent) 2 throws BeansException { 3 4 super(parent); 5 setConfigLocations(configLocations); 6 if (refresh) { 7 refresh(); 8 } 9 }從第二段代碼看,總共就做了三件事:
1、super(parent)
沒什么太大的作用,設置一下父級ApplicationContext,這里是null
2、setConfigLocations(configLocations)
代碼就不貼了,一看就知道,里面做了兩件事情:
(1)將指定的Spring配置文件的路徑存儲到本地
(2)解析Spring配置文件路徑中的${PlaceHolder}占位符,替換為系統變量中PlaceHolder對應的Value值,System本身就自帶一些系統變量比如class.path、os.name、user.dir等,也可以通過System.setProperty()方法設置自己需要的系統變量
3、refresh()
這個就是整個Spring Bean加載的核心了,它是ClassPathXmlApplicationContext的父類AbstractApplicationContext的一個方法,顧名思義,用于刷新整個Spring上下文信息,定義了整個Spring上下文加載的流程。
?
refresh方法
上面已經說了,refresh()方法是整個Spring Bean加載的核心,因此看一下整個refresh()方法的定義:
1 public void refresh() throws BeansException, IllegalStateException {2 synchronized (this.startupShutdownMonitor) {3 // Prepare this context for refreshing.4 prepareRefresh();5 6 // Tell the subclass to refresh the internal bean factory.7 ConfigurableListableBeanFactory beanFactory = obtainFreshBeanFactory();8 9 // Prepare the bean factory for use in this context. 10 prepareBeanFactory(beanFactory); 11 12 try { 13 // Allows post-processing of the bean factory in context subclasses. 14 postProcessBeanFactory(beanFactory); 15 16 // Invoke factory processors registered as beans in the context. 17 invokeBeanFactoryPostProcessors(beanFactory); 18 19 // Register bean processors that intercept bean creation. 20 registerBeanPostProcessors(beanFactory); 21 22 // Initialize message source for this context. 23 initMessageSource(); 24 25 // Initialize event multicaster for this context. 26 initApplicationEventMulticaster(); 27 28 // Initialize other special beans in specific context subclasses. 29 onRefresh(); 30 31 // Check for listener beans and register them. 32 registerListeners(); 33 34 // Instantiate all remaining (non-lazy-init) singletons. 35 finishBeanFactoryInitialization(beanFactory); 36 37 // Last step: publish corresponding event. 38 finishRefresh(); 39 } 40 41 catch (BeansException ex) { 42 // Destroy already created singletons to avoid dangling resources. 43 destroyBeans(); 44 45 // Reset 'active' flag. 46 cancelRefresh(ex); 47 48 // Propagate exception to caller. 49 throw ex; 50 } 51 } 52 }每個子方法的功能之后一點一點再分析,首先refresh()方法有幾點是值得我們學習的:
1、方法是加鎖的,這么做的原因是避免多線程同時刷新Spring上下文
2、盡管加鎖可以看到是針對整個方法體的,但是沒有在方法前加synchronized關鍵字,而使用了對象鎖startUpShutdownMonitor,這樣做有兩個好處:
(1)refresh()方法和close()方法都使用了startUpShutdownMonitor對象鎖加鎖,這就保證了在調用refresh()方法的時候無法調用close()方法,反之亦然,避免了沖突
(2)另外一個好處不在這個方法中體現,但是提一下,使用對象鎖可以減小了同步的范圍,只對不能并發的代碼塊進行加鎖,提高了整體代碼運行的效率
3、方法里面使用了每個子方法定義了整個refresh()方法的流程,使得整個方法流程清晰易懂。這點是非常值得學習的,一個方法里面幾十行甚至上百行代碼寫在一起,在我看來會有三個顯著的問題:
(1)擴展性降低。反過來講,假使把流程定義為方法,子類可以繼承父類,可以根據需要重寫方法
(2)代碼可讀性差。很簡單的道理,看代碼的人是愿意看一段500行的代碼,還是愿意看10段50行的代碼?
(3)代碼可維護性差。這點和上面的類似但又有不同,可維護性差的意思是,一段幾百行的代碼,功能點不明確,不易后人修改,可能會導致“牽一發而動全身”
?
prepareRefresh方法
下面挨個看refresh方法中的子方法,首先是prepareRefresh方法,看一下源碼:
1 /**2 * Prepare this context for refreshing, setting its startup date and3 * active flag.4 */5 protected void prepareRefresh() {6 this.startupDate = System.currentTimeMillis();7 synchronized (this.activeMonitor) {8 this.active = true;9 } 10 11 if (logger.isInfoEnabled()) { 12 logger.info("Refreshing " + this); 13 } 14 }這個方法功能比較簡單,顧名思義,準備刷新Spring上下文,其功能注釋上寫了:
1、設置一下刷新Spring上下文的開始時間
2、將active標識位設置為true
另外可以注意一下12行這句日志,這句日志打印了真正加載Spring上下文的Java類。
?
obtainFreshBeanFactory方法
obtainFreshBeanFactory方法的作用是獲取刷新Spring上下文的Bean工廠,其代碼實現為:
1 protected ConfigurableListableBeanFactory obtainFreshBeanFactory() { 2 refreshBeanFactory(); 3 ConfigurableListableBeanFactory beanFactory = getBeanFactory(); 4 if (logger.isDebugEnabled()) { 5 logger.debug("Bean factory for " + getDisplayName() + ": " + beanFactory); 6 } 7 return beanFactory; 8 }其核心是第二行的refreshBeanFactory方法,這是一個抽象方法,有AbstractRefreshableApplicationContext和GenericApplicationContext這兩個子類實現了這個方法,看一下上面ClassPathXmlApplicationContext的繼承關系圖即知,調用的應當是AbstractRefreshableApplicationContext中實現的refreshBeanFactory,其源碼為:
1 protected final void refreshBeanFactory() throws BeansException {2 if (hasBeanFactory()) {3 destroyBeans();4 closeBeanFactory();5 }6 try {7 DefaultListableBeanFactory beanFactory = createBeanFactory();8 beanFactory.setSerializationId(getId());9 customizeBeanFactory(beanFactory); 10 loadBeanDefinitions(beanFactory); 11 synchronized (this.beanFactoryMonitor) { 12 this.beanFactory = beanFactory; 13 } 14 } 15 catch (IOException ex) { 16 throw new ApplicationContextException("I/O error parsing bean definition source for " + getDisplayName(), ex); 17 } 18 }這段代碼的核心是第7行,這行點出了DefaultListableBeanFactory這個類,這個類是構造Bean的核心類,這個類的功能會在下一篇文章中詳細解讀,首先給出DefaultListableBeanFactory的繼承關系圖:
AbstractAutowireCapableBeanFactory這個類的繼承層次比較深,版面有限,就沒有繼續畫下去了,本圖基本上清楚地展示了DefaultListableBeanFactory的層次結構。
為了更清晰地說明DefaultListableBeanFactory的作用,列舉一下DefaultListableBeanFactory中存儲的一些重要對象及對象中的內容,DefaultListableBeanFactory基本就是操作這些對象,以表格形式說明:
| ?對象名 | 類 ?型 | ?作 ? ?用 | 歸屬類 |
| ?aliasMap | Map<String, String> | 存儲Bean名稱->Bean別名映射關系? | ?SimpleAliasRegistry |
| singletonObjects? | Map<String, Object> | ?存儲單例Bean名稱->單例Bean實現映射關系 | DefaultSingletonBeanRegistry? |
| ?singletonFactories | ?Map<String, ObjectFactory> | 存儲Bean名稱->ObjectFactory實現映射關系? | DefaultSingletonBeanRegistry? |
| earlySingletonObjects? | ?Map<String, Object> | 存儲Bean名稱->預加載Bean實現映射關系?? | ?DefaultSingletonBeanRegistry? |
| registeredSingletons? | Set<String>? | 存儲注冊過的Bean名 | ?DefaultSingletonBeanRegistry? |
| singletonsCurrentlyInCreation? | Set<String> | 存儲當前正在創建的Bean名? | ? DefaultSingletonBeanRegistry?? |
| ?disposableBeans | ?Map<String, Object> | 存儲Bean名稱->Disposable接口實現Bean實現映射關系 ? | ? ?DefaultSingletonBeanRegistry??? |
| ?factoryBeanObjectCache | ?Map<String, Object> | 存儲Bean名稱->FactoryBean接口Bean實現映射關系 | FactoryBeanRegistrySupport? |
| propertyEditorRegistrars? | ?Set<PropertyEditorRegistrar> | 存儲PropertyEditorRegistrar接口實現集合 | AbstractBeanFactory? |
| ?embeddedValueResolvers | List<StringValueResolver>? | 存儲StringValueResolver(字符串解析器)接口實現列表 | AbstractBeanFactory? |
| beanPostProcessors? | List<BeanPostProcessor>? | 存儲?BeanPostProcessor接口實現列表 | AbstractBeanFactory |
| mergedBeanDefinitions? | Map<String, RootBeanDefinition>? | 存儲Bean名稱->合并過的根Bean定義映射關系? | AbstractBeanFactory? |
| ?alreadyCreated | Set<String>? | 存儲至少被創建過一次的Bean名集合? | ?AbstractBeanFactory?? |
| ignoredDependencyInterfaces? | Set<Class>? | 存儲不自動裝配的接口Class對象集合? | AbstractAutowireCapableBeanFactory? |
| ?resolvableDependencies | Map<Class, Object>? | 存儲修正過的依賴映射關系? | DefaultListableBeanFactory? |
| beanDefinitionMap? | Map<String, BeanDefinition>? | 存儲Bean名稱-->Bean定義映射關系? | DefaultListableBeanFactory?? |
| beanDefinitionNames | List<String> | 存儲Bean定義名稱列表? | ?DefaultListableBeanFactory?? |
轉載于:https://www.cnblogs.com/moxiaowenxin/p/11169548.html
總結
以上是生活随笔為你收集整理的【Spring源码分析】Bean加载流程概览的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: Redis入门(二)安装和基本操作
- 下一篇: 简单的jQuery扩展函数-让函数缓冲执