前面的文章介紹了IOC的概念,Spring提供的bean容器便是對這一思想的具體實現,在接下來的幾篇文章會側重於探究這一bean容器是如何實現的。在此以前,先用一段話歸納一下bean容器的基本工做原理。顧名思義,bean容器的做用是替咱們管理bean對象(簡單的Java類對象)的。無論框架如何強大,仍是須要咱們程序員來告訴其一些必要信息的(好比要管理的bean對象的類相關信息、是否開啓組件掃描等),這些咱們稱之爲對Spring框架的配置,目前主流的配置方式是經過使用配置文件或註解。配置好以後,框架就須要將這些配置讀取並保存到內存中(其實就是保存在對象裏面)。通過這一步轉化以後,Spring框架就可以幫助咱們加載指定的類,而後將其實例化而且緩存起來以供須要的時候直接使用,這就是容器。當咱們將容器關閉時,Spring框架會將以前建立的全部相關對象所有銷燬,並釋放資源。java
如上只是簡單介紹了一下Spring提供的bean容器的基本工做原理,從中可以瞭解大致流程便可,真實的容器其工做原理遠遠比這複雜。本文主要總結Spring對配置的讀取以及將配置轉化保存到內存這部分,而且配置獲取這部分的源碼也只限於對xml配置文件的讀取。node
上面說到的配置讀取及初始化的功能對應前面文章中的代碼看起來只有區區一行,以下:程序員
BeanFactory beanFactory = new XmlBeanFactory(new ClassPathResource("beans.xml"));
這行代碼作了兩件事情:數組
Spring的配置文件讀取功能是封裝在ClassPathResource中,對應前面的代碼就是new ClassPathResource("bean.xml"),那麼ClassPathResource又是作什麼的呢?這個須要從頭提及。緩存
其實呢Spring將其內部使用到的資源的獲取方式獨立抽取出來,經過Resource接口來封裝底層資源,其接口定義以下:app
public interface InputStreamSource { InputStream getInputStream() throws IOException; } public interface Resource extends InputStreamSource { boolean exists(); boolean isReadable(); boolean isOpen(); URL getURL() throws IOException; URI getURI() throws IOException; File getFile() throws IOException; long contentLength() throws IOException; long lastModified() throws IOException; Resource createRelative(String relativePath) throws IOException; String getFilename(); String getDescription(); }
InputStreamSource是一個接口,它只有一個方法定義:getInputStream(),該方法返回一個新的InputStream對象,該接口定義任何能返回InputStream的類,好比file普通文件、Classpath下的資源文件和ByteArray等。框架
Resource接口用於抽象全部Spring內部使用到的底層資源:File、URL、Classpath等,其定義了一系列方法:ide
Spring中對不一樣來源的資源文件類型都有相應的Resource實現:文件(FileSystemResource)、Classpath資源( ClassPathResource)、URL資源(UrIResource)、InputStream資源(InputStreamResource)、Byte數組(ByteArrayResource)等。post
Resource接口的做用是消除底層資源訪問的差別,容許程序以一致的方式來訪問不一樣的底層資源,而其實現是很是簡單的,以getInputStream()方法實現爲例,ClassPathResource中的實現方式是直接調用class或者classLoader提供的底層方法getResourceAsStream,而對於FileSystemResource的實現其實更簡單,直接使用FileInputStream對文件進行實例化。ui
// ClasspathResource.java public InputStream getInputStream() throws IOException { InputStream is; if (this.clazz != null) { is = this.clazz.getResourceAs你Stream(this.path); } else if (this.classLoader != null) { is = this.classLoader.getResourceAsStream(this.path); } else { is = ClassLoader.getSystemResourceAsStream(this.path); } if (is == null) { throw new FileNotFoundException(getDescription() + " cannot be opened because it does not exist"); } return is; } // FileSystemResource public InputStream getInputStream()throws IOException{ return new FileInputStream(this.file); }
這樣就能夠將資源統一轉化成InputStream供後續使用了,而前面示例代碼中使用的xml配置文件是屬於什麼類型的Resource呢?其實從源碼中咱們就不難發現是屬於ClassPathResource的,而new ClassPathResource("bean.xml")這句代碼的內部實現就不細說了,無非就是初始化配置文件路徑。
一句話總結,Spring經過Resource接口抽象全部的資源,在容器啓動的第一步就是將資源文件映射成Resource對象,以供後續經過流的方式來獲取資源。
如今配置文件封裝到Resource中以後,後續Spring在初始化BeanFactory的過程當中就能夠方便地調用其getInputStream()方法來獲取其對應的流了,而後作進一步轉化。
public XmlBeanFactory(Resource resource) throws BeansException { this(resource, null); } public XmlBeanFactory(Resource resource, BeanFactory parentBeanFactory) throws BeansException { super(parentBeanFactory); this.reader.loadBeanDefinitions(resource); }
這段代碼主要做用是初始化BeanFactory,其中this.reader.loadBeanDefinitions(resource)就是資源加載的真正實現,也是咱們接下來的分析重點。
咱們來看一下loadBeanDefinitions()方法具體的內部實現:
public int loadBeanDefinitions(Resource resource) throws BeanDefinitionStoreException { return loadBeanDefinitions(new EncodedResource(resource)); } public int loadBeanDefinitions(EncodedResource encodedResource) throws BeanDefinitionStoreException { Assert.notNull(encodedResource, "EncodedResource must not be null"); if (logger.isInfoEnabled()) { logger.info("Loading XML bean definitions from " + encodedResource.getResource()); } // 經過屬性來記錄已經加載的資源 Set<EncodedResource> currentResources = this.resourcesCurrentlyBeingLoaded.get(); if (currentResources == null) { currentResources = new HashSet<EncodedResource>(4); this.resourcesCurrentlyBeingLoaded.set(currentResources); } if (!currentResources.add(encodedResource)) { throw new BeanDefinitionStoreException( "Detected cyclic loading of " + encodedResource + " - check your import definitions!"); } try { // 從encodeResource中獲取封裝的Resource對象並再次從Resouce中獲取其中的inputStream InputStream inputStream = encodedResource.getResource().getInputStream(); try { // InputSource這個類並不來自於Spring,它來自org.xml.sax.InputSource InputSource inputSource = new InputSource(inputStream); if (encodedResource.getEncoding() != null) { inputSource.setEncoding(encodedResource.getEncoding()); } // 核心邏輯部分 return doLoadBeanDefinitions(inputSource, encodedResource.getResource()); } finally { inputStream.close(); } } catch (IOException ex) { throw new BeanDefinitionStoreException( "IOException parsing XML document from " + encodedResource.getResource(), ex); } finally { currentResources.remove(encodedResource); if (currentResources.isEmpty()) { this.resourcesCurrentlyBeingLoaded.remove(); } } }
這一部分其實還只是數據準備階段,主要作了以下三件事情:
protected int doLoadBeanDefinitions(InputSource inputSource, Resource resource) throws BeanDefinitionStoreException { try { int validationMode = getValidationModeForResource(resource); Document doc = this.documentLoader.loadDocument( inputSource, getEntityResolver(), this.errorHandler, validationMode, isNamespaceAware()); return registerBeanDefinitions(doc, resource); } catch (BeanDefinitionStoreException ex) { throw ex; } 。。。catch若干異常 }
不考慮其中異常類的代碼,這段代碼其實只作了三件事:
這3個步驟支撐着整個Spring容器部分的實現基礎,尤爲是第3步對配置文件的解析,邏輯很是的複雜,這裏咱們只分析第2步和第3步。
XmIBeanFactoryReader類對於文檔讀取並無親力親爲,而是委託給了DocumentLoader去執行,這裏的DocumentLoader只是個接口,實際對象則是DefaultDocumentLoader,解析代碼以下:
public Document loadDocument(InputSource inputSource, EntityResolver entityResolver, ErrorHandler errorHandler, int validationMode, boolean namespaceAware) throws Exception { DocumentBuilderFactory factory = createDocumentBuilderFactory(validationMode, namespaceAware); if (logger.isTraceEnabled()) { logger.trace("Using JAXP provider [" + factory.getClass().getName() + "]"); } DocumentBuilder builder = createDocumentBuilder(factory, entityResolver, errorHandler); return builder.parse(inputSource); }
首先建立DocumentBuilderFactory,再經過DocumentBuilderFactory建立DocumentBuilder,而後解析inputSource來返回Document對象。這部分是JDK提供的功能,有興趣的能夠自行搜索,此處就再也不贅述。
當把文件轉換爲Document後,接下來的提取及註冊bean就是重頭戲。繼續上面的分析,當程序已經擁有XML文檔文件的Document實例對象時,就會被引入下面這個方法:
public int registerBeanDefinitions(Document doc, Resource resource) throws BeanDefinitionStoreException { // 使用DefaultBeanDefinitionDocumentReader實例化BeanDefinitionDocumentReader BeanDefinitionDocumentReader documentReader = createBeanDefinitionDocumentReader(); // 將環境變量設置其中 documentReader.setEnvironment(getEnvironment()); // 在實例化BeanDefinitionReader時候會將BeanDefinitionRegistry傳入,默認使用繼承自DefaultListableBeanFactory的子類 // 記錄統計前BeanDefinition的加載個數 int countBefore = getRegistry().getBeanDefinitionCount(); // 加載及註冊bean documentReader.registerBeanDefinitions(doc, createReaderContext(resource)); // 記錄本次加載的BeanDefinition個數 return getRegistry().getBeanDefinitionCount() - countBefore; }
在這個方法中,加載及註冊bean的邏輯是委託給BeanDefinitionDocumentReader指向的類來處理,這很好地應用了面向對象中單一職責的原則。BeanDefinitionDocumentReader是一個接口,其實例化的工做是在 createBeanDefinitionDocumentReader()中完成的,而經過此方法,BeanDefinitionDocumentReader真正的類型其實已是DefaultBeanDefinitionDocumentReader了,進入DefaultBeanDefinitionDocumentReader的registerBeanDefinitions()方法後,發現這個方法的重要目的之一就是提取root,以便於再次將root做爲參數繼續BeanDefinition的註冊:
public void registerBeanDefinitions(Document doc, XmlReaderContext readerContext) { this.readerContext = readerContext; logger.debug("Loading bean definitions"); Element root = doc.getDocumentElement(); doRegisterBeanDefinitions(root); }
終於到了核心邏輯的底部doRegisterBeanDefinitions(root),若是說以前一直是XML加載解析的準備階段,那麼doRegisterBeanDefinitions算是真正地開始進行解析了。
protected void doRegisterBeanDefinitions(Element root) { // 處理profile屬性 String profileSpec = root.getAttribute(PROFILE_ATTRIBUTE); if (StringUtils.hasText(profileSpec)) { String[] specifiedProfiles = StringUtils.tokenizeToStringArray( profileSpec, BeanDefinitionParserDelegate.MULTI_VALUE_ATTRIBUTE_DELIMITERS); if (!getEnvironment().acceptsProfiles(specifiedProfiles)) { return; } } // 專門處理解析 BeanDefinitionParserDelegate parent = this.delegate; this.delegate = createDelegate(this.readerContext, root, parent); // 解析前處理,留給子類實現 preProcessXml(root); parseBeanDefinitions(root, this.delegate); // 解析後處理,留給子類實現 postProcessXml(root); this.delegate = parent; }
這裏首先是對profile的處理,而後開始進行解析,preProcessXml(root)和postProcessXml(root)方法是空實現,留待用戶繼承DefaultBeanDefinitionDocumentReader後須要在Bean解析先後作一些處理時重寫這兩個方法。跟蹤代碼進入parseBeanDefinitions(root, this.delegate):
protected void parseBeanDefinitions(Element root, BeanDefinitionParserDelegate delegate) { // 對beans的處理 if (delegate.isDefaultNamespace(root)) { NodeList nl = root.getChildNodes(); for (int i = 0; i < nl.getLength(); i++) { Node node = nl.item(i); if (node instanceof Element) { Element ele = (Element) node; if (delegate.isDefaultNamespace(ele)) { // 對bean的處理 parseDefaultElement(ele, delegate); } else { // 對bean的處理 delegate.parseCustomElement(ele); } } } } else { delegate.parseCustomElement(root); } }
在Spring的XML配置裏面有兩大類Bean聲明,一種是默認的,如:
<bean id="test"class="test.TestBean"/>
另外一類就是自定義的,如:
<tx: annotation-driven/>
而兩種方式的讀取及解析差異是很是大的,若是採用 Spring默認配置,Spring固然知道該怎麼作,可是若是是自定義的,那麼就須要用戶實現一些接口及配置了。對於根節點或者子節點若是是默認命名空間的話則採用parseDefaultElement方法進行解析,不然使用delegate. parseCustomElement方法對自定義命名空間進行解析。而判斷是否默認命名空間仍是自定義命名空間的辦法實際上是使用node. getNamespaceURI()獲取命名空間,並與Spring中固定的命名空間http://www.Springframework.org/schema/beans進行比對。若是一致則認爲是默認,不然就認爲是自定義。
本文主要總結Spring對配置(xml配置文件)的讀取以及將配置轉化保存到內存這部分,對xml配置的讀取主要是將其轉換成Resource,而將配置轉化保存則主要是從Resource中獲取InputStream並將其解析轉化成BeanDefinition等對象保存起來。