摘要:這篇文章是我學習分析其源碼時總結的,其目的并非是完全理解源碼信息,但是根據容器如何從文件到的實例初始化進行了一個流程的梳理,希望可以對大家理解源碼有一定的幫助。
這篇文章是我學習spring IoC 分析其源碼時總結的,其目的并非是完全理解源碼信息,但是根據spring IoC 容器如何從xml文件到bean的實例初始化進行了一個流程的梳理,希望可以對大家理解源碼有一定的幫助。話不多少,我們直接來看。
這里,我是用ApplicationContext來進行介紹,畢竟項目中大部分還是使用的這個容器。容器啟動的入口我們可以從AbstractApplicationContext類的refresh方法看起。
Spring IoC容器對Bean定義資源的載入是從refresh()函數開始的,refresh()是一個模板方法,refresh()方法的作用是:在創建IoC容器前,如果已經有容器存在,則需要把已有的容器銷毀和關閉,以保證在refresh之后使用的是新建立起來的IoC容器。refresh的作用類似于對IoC容器的重啟,在新建立好的容器中對容器進行初始化,對Bean定義資源進行載入。
refresh
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(); } catch (BeansException ex) { // Destroy already created singletons to avoid dangling resources. destroyBeans(); // Reset "active" flag. cancelRefresh(ex); // Propagate exception to caller. throw ex; } } }
上邊有兩個很重要的方法:
ConfigurableListableBeanFactory beanFactory = obtainFreshBeanFactory();
這個方法就是根據Xml配置文件解析Bean的信息生成BeanDifinition,然后注冊到BeanDefinitionRegistry中,即bean信息的裝載注冊階段
beanFactory.preInstantiateSingletons();
這個方法看其注釋我們就可以理解,它是實例化所有非懶加載的單例bean。
AbstractApplicationContext的obtainFreshBeanFactory()方法調用子類容器的refreshBeanFactory()方法,啟動容器載入Bean定義資源文件的過程,代碼如下:
protected ConfigurableListableBeanFactory obtainFreshBeanFactory() { //這里使用了委派設計模式,父類定義了抽象的refreshBeanFactory()方法,具體實現調用子類容器的refreshBeanFactory()方法 refreshBeanFactory(); ConfigurableListableBeanFactory beanFactory = getBeanFactory(); if (logger.isDebugEnabled()) { logger.debug("Bean factory for " + getDisplayName() + ": " + beanFactory); } return beanFactory; }
AbstractApplicationContext類中只抽象定義了refreshBeanFactory()方法,容器真正調用的是其子類AbstractRefreshableApplicationContext實現的 refreshBeanFactory()方法。代碼如下:
protected final void refreshBeanFactory() throws BeansException { if (hasBeanFactory()) { destroyBeans(); closeBeanFactory(); } try { DefaultListableBeanFactory beanFactory = createBeanFactory(); beanFactory.setSerializationId(getId()); customizeBeanFactory(beanFactory); loadBeanDefinitions(beanFactory); synchronized (this.beanFactoryMonitor) { this.beanFactory = beanFactory; } } catch (IOException ex) { throw new ApplicationContextException("I/O error parsing bean definition source for " + getDisplayName(), ex); } }
在這個方法中,先判斷BeanFactory是否存在,如果存在則先銷毀beans并關閉beanFactory,接著創建DefaultListableBeanFactory,并調用loadBeanDefinitions(beanFactory)裝載bean定義。
我們在其子類AbstractXmlApplicationContext最終可以看到下面這個方法,此方法就是真正從XML文件中讀取并解析Bean的信息,放在對應的BeanDefinition中
protected void loadBeanDefinitions(DefaultListableBeanFactory beanFactory) throws BeansException, IOException { // Create a new XmlBeanDefinitionReader for the given BeanFactory. XmlBeanDefinitionReader beanDefinitionReader = new XmlBeanDefinitionReader(beanFactory); // Configure the bean definition reader with this context"s // resource loading environment. beanDefinitionReader.setEnvironment(this.getEnvironment()); beanDefinitionReader.setResourceLoader(this); beanDefinitionReader.setEntityResolver(new ResourceEntityResolver(this)); // Allow a subclass to provide custom initialization of the reader, // then proceed with actually loading the bean definitions. initBeanDefinitionReader(beanDefinitionReader); loadBeanDefinitions(beanDefinitionReader); }
再看preInstantiateSingletons()
public void preInstantiateSingletons() throws BeansException { if (this.logger.isInfoEnabled()) { this.logger.info("Pre-instantiating singletons in " + this); } ListbeanNames; synchronized (this.beanDefinitionMap) { // Iterate over a copy to allow for init methods which in turn register new bean definitions. // While this may not be part of the regular factory bootstrap, it does otherwise work fine. beanNames = new ArrayList (this.beanDefinitionNames); } for (String beanName : beanNames) { RootBeanDefinition bd = getMergedLocalBeanDefinition(beanName); if (!bd.isAbstract() && bd.isSingleton() && !bd.isLazyInit()) { if (isFactoryBean(beanName)) { final FactoryBean> factory = (FactoryBean>) getBean(FACTORY_BEAN_PREFIX + beanName); boolean isEagerInit; if (System.getSecurityManager() != null && factory instanceof SmartFactoryBean) { isEagerInit = AccessController.doPrivileged(new PrivilegedAction () { public Boolean run() { return ((SmartFactoryBean>) factory).isEagerInit(); } }, getAccessControlContext()); } else { isEagerInit = (factory instanceof SmartFactoryBean && ((SmartFactoryBean>) factory).isEagerInit()); } if (isEagerInit) { getBean(beanName); } } else { getBean(beanName); } } } }
其中我們需要關注getBean(beanName)這個方法,此方法中進行了bean的實例化和初始化;我們可以進入這個方法中,看到doGetBean() 這個方法
protectedT doGetBean( final String name, final Class requiredType, final Object[] args, boolean typeCheckOnly) throws BeansException { ... ... //這一部分是先從緩存中獲取對應的bean;如果有的話,返回緩存中的單例bean; Object sharedInstance = getSingleton(beanName); if (sharedInstance != null && args == null) { if (logger.isDebugEnabled()) { if (isSingletonCurrentlyInCreation(beanName)) { logger.debug("Returning eagerly cached instance of singleton bean "" + beanName + "" that is not fully initialized yet - a consequence of a circular reference"); } else { logger.debug("Returning cached instance of singleton bean "" + beanName + """); } } bean = getObjectForBeanInstance(sharedInstance, name, beanName, null); } else { ... ... /** * Return a merged RootBeanDefinition, traversing the parent bean definition * if the specified bean corresponds to a child bean definition. */ final RootBeanDefinition mbd = getMergedLocalBeanDefinition(beanName); checkMergedBeanDefinition(mbd, beanName, args); // Guarantee initialization of beans that the current bean depends on. String[] dependsOn = mbd.getDependsOn(); if (dependsOn != null) { for (String dependsOnBean : dependsOn) { getBean(dependsOnBean); registerDependentBean(dependsOnBean, beanName); } } // Create bean instance. if (mbd.isSingleton()) { sharedInstance = getSingleton(beanName, new ObjectFactory
上邊的代碼中,我們需要關心的是
final RootBeanDefinition mbd = getMergedLocalBeanDefinition(beanName);
獲取到對應beanName的BeanDefinition,這里顯然是做了些包裝(RootBeanDefinition);
由于在項目中,絕大部分bean都是單例的,所以我們只關心單例類型的bean的創建
if (mbd.isSingleton()) { sharedInstance = getSingleton(beanName, new ObjectFactory
注意,這里重新 實現了ObjectFactory中的getObject()方法,這個對下面的理解有很大幫助。我們先進入getSingleton()方法中
public Object getSingleton(String beanName, ObjectFactory singletonFactory) { Assert.notNull(beanName, ""beanName" must not be null"); synchronized (this.singletonObjects) { //從緩存中獲取對應的bean Object singletonObject = this.singletonObjects.get(beanName); if (singletonObject == null) { if (this.singletonsCurrentlyInDestruction) { throw new BeanCreationNotAllowedException(beanName, "Singleton bean creation not allowed while the singletons of this factory are in destruction " + "(Do not request a bean from a BeanFactory in a destroy method implementation!)"); } if (logger.isDebugEnabled()) { logger.debug("Creating shared instance of singleton bean "" + beanName + """); } beforeSingletonCreation(beanName); boolean recordSuppressedExceptions = (this.suppressedExceptions == null); if (recordSuppressedExceptions) { this.suppressedExceptions = new LinkedHashSet(); } try { singletonObject = singletonFactory.getObject(); } catch (BeanCreationException ex) { if (recordSuppressedExceptions) { for (Exception suppressedException : this.suppressedExceptions) { ex.addRelatedCause(suppressedException); } } throw ex; } finally { if (recordSuppressedExceptions) { this.suppressedExceptions = null; } afterSingletonCreation(beanName); } //在這里將實例化的bean放入容器中; addSingleton(beanName, singletonObject); } return (singletonObject != NULL_OBJECT ? singletonObject : null); } }
這里邊我們需要關注的有
beforeSingletonCreation(beanName);
從名稱我們大概可以猜出來這個方法的一些作用:在單例bean創建之前所要做的事;
singletonObject = singletonFactory.getObject();
看到這里,你會想到什么?前面所說的在上一層重新實現了次方法,所以這一塊得注意,它執行的是重新實現后的方法,等下具體分析。
afterSingletonCreation(beanName);
對應beforeSingletonCreation,這個就是在單例bean創建之后所要做的事;
接下來,我們回頭看一下重新實現的singletonFactory.getObject()里調用了createBean(beanName, mbd, args);
我們進入createBean(beanName, mbd, args)
protected Object createBean(final String beanName, final RootBeanDefinition mbd, final Object[] args) throws BeanCreationException { if (logger.isDebugEnabled()) { logger.debug("Creating instance of bean "" + beanName + """); } // Make sure bean class is actually resolved at this point. resolveBeanClass(mbd, beanName); // Prepare method overrides. try { mbd.prepareMethodOverrides(); } catch (BeanDefinitionValidationException ex) { throw new BeanDefinitionStoreException(mbd.getResourceDescription(), beanName, "Validation of method overrides failed", ex); } try { // Give BeanPostProcessors a chance to return a proxy instead of the target bean instance. Object bean = resolveBeforeInstantiation(beanName, mbd); if (bean != null) { return bean; } } catch (Throwable ex) { throw new BeanCreationException(mbd.getResourceDescription(), beanName, "BeanPostProcessor before instantiation of bean failed", ex); } Object beanInstance = doCreateBean(beanName, mbd, args); if (logger.isDebugEnabled()) { logger.debug("Finished creating instance of bean "" + beanName + """); } return beanInstance; }
在這里,我們可以看到
Object beanInstance = doCreateBean(beanName, mbd, args);
在這個方法中進行備案的實例化(有人這時候會說,怎么這么就還沒有看到真正的bean實例化,沒辦法,spring自己還要實現自己的一些東西,這些我們不關注,但是不代表沒有必要,所以耐心看下去吧)
protected Object doCreateBean(final String beanName, final RootBeanDefinition mbd, final Object[] args) { // Instantiate the bean. //這個類將作為最終的bean單例放入容器中 BeanWrapper instanceWrapper = null; if (mbd.isSingleton()) { instanceWrapper = this.factoryBeanInstanceCache.remove(beanName); } if (instanceWrapper == null) { instanceWrapper = createBeanInstance(beanName, mbd, args); } final Object bean = (instanceWrapper != null ? instanceWrapper.getWrappedInstance() : null); Class> beanType = (instanceWrapper != null ? instanceWrapper.getWrappedClass() : null); // Allow post-processors to modify the merged bean definition. synchronized (mbd.postProcessingLock) { if (!mbd.postProcessed) { applyMergedBeanDefinitionPostProcessors(mbd, beanType, beanName); mbd.postProcessed = true; } } // Eagerly cache singletons to be able to resolve circular references // even when triggered by lifecycle interfaces like BeanFactoryAware. //處理循環依賴的問題 boolean earlySingletonExposure = (mbd.isSingleton() && this.allowCircularReferences && isSingletonCurrentlyInCreation(beanName)); if (earlySingletonExposure) { if (logger.isDebugEnabled()) { logger.debug("Eagerly caching bean "" + beanName + "" to allow for resolving potential circular references"); } addSingletonFactory(beanName, new ObjectFactory() { public Object getObject() throws BeansException { return getEarlyBeanReference(beanName, mbd, bean); } }); } // Initialize the bean instance. Object exposedObject = bean; try { populateBean(beanName, mbd, instanceWrapper); if (exposedObject != null) { exposedObject = initializeBean(beanName, exposedObject, mbd); } } catch (Throwable ex) { if (ex instanceof BeanCreationException && beanName.equals(((BeanCreationException) ex).getBeanName())) { throw (BeanCreationException) ex; } else { throw new BeanCreationException(mbd.getResourceDescription(), beanName, "Initialization of bean failed", ex); } } ... ... }
此方法較長,我們只需要關心我們需要關心的。
BeanWrapper instanceWrapper = null;
此類將作為最終的單例bean放入容器中,這個類將會是對應bean的一個封裝;
applyMergedBeanDefinitionPostProcessors(mbd, beanType, beanName);
允許其他修改beanDefinition,這主要是允許其他組件提供xml不能提供的信息。如使用Annotation增強Bean定義等。這通過類ergedBeanDefinitionPostProcessor來完成,如果容器中提供了此類實現,則會調用進行bean增強。
populateBean(beanName, mbd, instanceWrapper);
此方法里是利用InstantiationAwareBeanPostProcessor將bean進行填充,以及autowire標簽的處理
exposedObject = initializeBean(beanName, exposedObject, mbd);
重頭戲來了,這個才是我們最要關心的,在里邊會進行bean的實例化和初始化
進入initializeBean
protected Object initializeBean(final String beanName, final Object bean, RootBeanDefinition mbd) { if (System.getSecurityManager() != null) { AccessController.doPrivileged(new PrivilegedAction
這里邊有三個重要的方法
invokeAwareMethods(beanName, bean);
查看該bean是否實現了相關的Aware接口,如果有,將其進行裝配;
wrappedBean = applyBeanPostProcessorsBeforeInitialization(wrappedBean, beanName);
invokeInitMethods(beanName, wrappedBean, mbd);
這里利用Java反射機制將bean對應的beanDefinition信息進行設置;
wrappedBean = applyBeanPostProcessorsAfterInitialization(wrappedBean, beanName);
spring提供了一個接口類-BeanPostProcessor,我們叫他:bean的加工器,應該是在bean的實例化過程中對bean做一些包裝處理,里邊提供兩個方法applyBeanPostProcessorsBeforeInitialization和applyBeanPostProcessorsAfterInitialization。
根據以上代碼,我們得知,在invokeInitMethods的執行前后,spring會分別調用所有的BeanPostProcessor,執行其中的方法,那么invokeInitMethods的具體內容我們仍需要看下,發現此方法主要作用有兩個:
判斷bean是否繼承了InitializingBean,如果繼承接口,執行afterPropertiesSet()方法
獲得是否設置了init-method屬性,如果設置了,就執行設置的方法
這里幾個典型的應用場景如:
解析bean的注解,將注解中的字段轉化為屬性
統一將屬性在執行前,注入bean中,如數據庫訪問的sqlMap,如嚴重服務,這樣不需要每個bean都配置屬性
打印日志,記錄時間等。
詳細了解BeanPostProcessor的使用可以參考這里BeanPostProcessor的使用
protected void invokeInitMethods(String beanName, final Object bean, RootBeanDefinition mbd) throws Throwable { boolean isInitializingBean = (bean instanceof InitializingBean); if (isInitializingBean && (mbd == null || !mbd.isExternallyManagedInitMethod("afterPropertiesSet"))) { if (logger.isDebugEnabled()) { logger.debug("Invoking afterPropertiesSet() on bean with name "" + beanName + """); } if (System.getSecurityManager() != null) { try { AccessController.doPrivileged(new PrivilegedExceptionAction
到了這里,spring才真正地實例化并初始化bean。 所以在進入initializeBean方法里,我們大概可以總結出bean的初始化順序:
XXAware接口的實現->postProcessBeforeInitialization->InitializingBean的afterPropertiesSet -> custom Init方法->postProcessAfterInitialization
如有錯誤,歡迎指正。如果對你有幫助的話,順便點個贊哈!
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/67555.html
摘要:在上文中,我實現了一個很簡單的和容器。比如,我們所熟悉的就是在這里將切面邏輯織入相關中的。初始化的工作算是結束了,此時處于就緒狀態,等待外部程序的調用。其中動態代理只能代理實現了接口的對象,而動態代理則無此限制。 1. 背景 本文承接上文,來繼續說說 IOC 和 AOP 的仿寫。在上文中,我實現了一個很簡單的 IOC 和 AOP 容器。上文實現的 IOC 和 AOP 功能很單一,且 I...
摘要:實例化時,發現又依賴于。一些緩存的介紹在進行源碼分析前,我們先來看一組緩存的定義??墒强赐暝创a后,我們似乎仍然不知道這些源碼是如何解決循環依賴問題的。 1. 簡介 本文,我們來看一下 Spring 是如何解決循環依賴問題的。在本篇文章中,我會首先向大家介紹一下什么是循環依賴。然后,進入源碼分析階段。為了更好的說明 Spring 解決循環依賴的辦法,我將會從獲取 bean 的方法getB...
摘要:源碼分析源碼一覽本節,我們先來看一下填充屬性的方法,即。所有的屬性值是在方法中統一被注入到對象中的。檢測是否存在與相關的或。這樣可以在很大程度上降低源碼分析的難度。若候選項是非類型,則表明已經完成了實例化,此時直接返回即可。 1. 簡介 本篇文章,我們來一起了解一下 Spring 是如何將配置文件中的屬性值填充到 bean 對象中的。我在前面幾篇文章中介紹過 Spring 創建 bea...
摘要:你也會了解到構造對象的兩種策略。構造方法參數數量低于配置的參數數量,則忽略當前構造方法,并重試。通過默認構造方法創建對象看完了上面冗長的邏輯,本節來看點輕松的吧通過默認構造方法創建對象。 1. 簡介 本篇文章是上一篇文章(創建單例 bean 的過程)的延續。在上一篇文章中,我們從戰略層面上領略了doCreateBean方法的全過程。本篇文章,我們就從戰術的層面上,詳細分析doCreat...
摘要:關于創建實例的過程,我將會分幾篇文章進行分析。源碼分析創建實例的入口在正式分析方法前,我們先來看看方法是在哪里被調用的。時,表明方法不存在,此時拋出異常。該變量用于表示是否提前暴露單例,用于解決循環依賴。 1. 簡介 在上一篇文章中,我比較詳細的分析了獲取 bean 的方法,也就是getBean(String)的實現邏輯。對于已實例化好的單例 bean,getBean(String) ...
閱讀 1644·2021-11-24 09:39
閱讀 3083·2021-11-22 15:24
閱讀 3091·2021-10-26 09:51
閱讀 3277·2021-10-19 11:46
閱讀 2891·2019-08-30 15:44
閱讀 2217·2019-08-29 15:30
閱讀 2537·2019-08-29 15:05
閱讀 773·2019-08-29 10:55