跳到主要內容

SpringBoot啟動流程分析（五）：SpringBoot自動裝配原理實現

SpringBoot系列文章簡介


SpringBoot源碼閱讀輔助篇：


　　Spring IoC容器與應用上下文的設計與實現


SpringBoot啟動流程源碼分析：



  1. SpringBoot啟動流程分析（一）：SpringApplication類初始化過程

  2. SpringBoot啟動流程分析（二）：SpringApplication的run方法

  3. SpringBoot啟動流程分析（三）：SpringApplication的run方法之prepareContext()方法

  4. SpringBoot啟動流程分析（四）：IoC容器的初始化過程

  5. SpringBoot啟動流程分析（五）：SpringBoot自動裝配原理實現

  6. SpringBoot啟動流程分析（六）：IoC容器依賴注入


筆者註釋版Spring Framework與SpringBoot源碼git傳送門：請不要吝嗇小星星



  1. spring-framework-5.0.8.RELEASE

  2. SpringBoot-2.0.4.RELEASE


自定義Starter：


　　SpringBoot應用篇（一）：自定義starter


一、前言


　　上一篇文章，通過分析refresh()方法中的invokeBeanFactoryPostProcessors()方法，分析了IoC容器的初始化過程，這一節從代碼上如下所示，接上一節ConfigurationClassParser類中的parse()方法，接着分析SpringBoot的自動裝配原理。


 1 // ConfigurationClassParser類 
  2 public void parse(Set<BeanDefinitionHolder> configCandidates) { 
  3     this.deferredImportSelectors = new LinkedList<>(); 
  4     for (BeanDefinitionHolder holder : configCandidates) { 
  5         BeanDefinition bd = holder.getBeanDefinition(); 
  6         try { 
  7             // 如果是SpringBoot項目進來的，bd其實就是前面主類封裝成的 AnnotatedGenericBeanDefinition（AnnotatedBeanDefinition接口的實現類） 
  8             if (bd instanceof AnnotatedBeanDefinition) { 
  9                 parse(((AnnotatedBeanDefinition) bd).getMetadata(), holder.getBeanName()); 
 10             } else if (bd instanceof AbstractBeanDefinition && ((AbstractBeanDefinition) bd).hasBeanClass()) { 
 11                 parse(((AbstractBeanDefinition) bd).getBeanClass(), holder.getBeanName()); 
 12             } else { 
 13                 parse(bd.getBeanClassName(), holder.getBeanName()); 
 14             } 
 15         } catch (BeanDefinitionStoreException ex) { 
 16             throw ex; 
 17         } catch (Throwable ex) { 
 18             throw new BeanDefinitionStoreException( 
 19                     "Failed to parse configuration class [" + bd.getBeanClassName() + "]", ex); 
 20         } 
 21     } 
 22     // 加載默認的配置---》（對springboot項目來說這裏就是自動裝配的入口了） 
 23     processDeferredImportSelectors(); 
 24 }

 


二、SpringBoot自動裝配原理。


2.1、@SpringBootApplication註解


　　對這個註解詳細大家一定非常熟悉了。再來好好看看這個註解。


 1 @Target(ElementType.TYPE) 
  2 @Retention(RetentionPolicy.RUNTIME) 
  3 @Documented 
  4 @Inherited 
  5 @SpringBootConfiguration 
  6 @EnableAutoConfiguration 
  7 @ComponentScan(excludeFilters = { 
  8         @Filter(type = FilterType.CUSTOM, classes = TypeExcludeFilter.class), 
  9         @Filter(type = FilterType.CUSTOM, classes = AutoConfigurationExcludeFilter.class) }) 
 10 public @interface SpringBootApplication { 
 11     ... 
 12 }

　　接着看@EnableAutoConfiguration


1 @Target(ElementType.TYPE) 
 2 @Retention(RetentionPolicy.RUNTIME) 
 3 @Documented 
 4 @Inherited 
 5 @AutoConfigurationPackage 
 6 @Import(AutoConfigurationImportSelector.class) 
 7 public @interface EnableAutoConfiguration { 
 8     ... 
 9 }

　　OK，看到@Import(AutoConfigurationImportSelector.class)導入了一個重要的類AutoConfigurationImportSelector。


2.2、AutoConfigurationImportSelector


 1 // AutoConfigurationImportSelector類 
  2 //自動裝配 
  3 @Override 
  4 public String[] selectImports(AnnotationMetadata annotationMetadata) { 
  5     if (!isEnabled(annotationMetadata)) { 
  6         return NO_IMPORTS; 
  7     } 
  8     AutoConfigurationMetadata autoConfigurationMetadata = AutoConfigurationMetadataLoader 
  9             .loadMetadata(this.beanClassLoader); 
 10     AnnotationAttributes attributes = getAttributes(annotationMetadata); 
 11     //獲取所有的自動配置類（META-INF/spring.factories中配置的key為org.springframework.boot.autoconfigure.EnableAutoConfiguration的類） 
 12     List<String> configurations = getCandidateConfigurations(annotationMetadata, 
 13             attributes); 
 14     configurations = removeDuplicates(configurations); 
 15     //需要排除的自動裝配類（springboot的主類上 @SpringBootApplication(exclude = {com.demo.starter.config.DemoConfig.class})指定的排除的自動裝配類） 
 16     Set<String> exclusions = getExclusions(annotationMetadata, attributes); 
 17     checkExcludedClasses(configurations, exclusions); 
 18     //將需要排除的類從 configurations remove掉 
 19     configurations.removeAll(exclusions); 
 20     configurations = filter(configurations, autoConfigurationMetadata); 
 21     fireAutoConfigurationImportEvents(configurations, exclusions); 
 22     return StringUtils.toStringArray(configurations); 
 23 }

　　至於怎麼從章節一中提到的ConfigurationClassParser類中的parse()===>processDeferredImportSelectors()==>AutoConfigurationImportSelector#selectImports()，篇幅有限不做過多介紹。


　　 List<String> configurations = getCandidateConfigurations(annotationMetadata, attributes); 


　　我們來看一下getCandidateConfigurations()方法是怎麼拿到這些自動配置類的。


// AutoConfigurationImportSelector類
1 protected List<String> getCandidateConfigurations(AnnotationMetadata metadata, 
 2                                                   AnnotationAttributes attributes) { 
 3     List<String> configurations = SpringFactoriesLoader.loadFactoryNames( 
 4             getSpringFactoriesLoaderFactoryClass(), getBeanClassLoader()); 
 5     Assert.notEmpty(configurations, 
 6             "No auto configuration classes found in META-INF/spring.factories. If you " 
 7                     + "are using a custom packaging, make sure that file is correct."); 
 8     return configurations; 
 9 }

　　是不是又看到一個十分熟悉的方法loadFactoryNames()，沒錯，其實我們在分析SpringBoot啟動流程的第一篇文章的時候，就已經分析了，SpringBoot是如何從META-INF/spring.factories中加載指定key的value的。ok，我們在這裏再次回顧一遍。


　　看看loadFactoryNames()方法


// SpringFactoriesLoader類
1 public static List<String> loadFactoryNames(Class<?> factoryClass, @Nullable ClassLoader classLoader) { 
 2     String factoryClassName = factoryClass.getName(); 
 3     return loadSpringFactories(classLoader).getOrDefault(factoryClassName, Collections.emptyList()); 
 4 }

　　debug，看看要從META-INF/spring.factories中加載的類的key，如下圖所示：org.springframework.boot.autoconfigure.EnableAutoConfiguration



　　回到selectImports()方法，debug，跳過List<String> configurations = getCandidateConfigurations(annotationMetadata,attributes);看一下configurations



　　竟然有110個，那這些類都在哪裡呢？看spring-boot-autoconfigure（當然在SpringBoot的工程中，也不止這一個依賴包中存在該配置文件）工程下的META-INF/spring.factories，我們能看到org.springframework.boot.autoconfigure.EnableAutoConfiguration定義了一大堆。



　　其中還有一個com.demo.starter.config.DemoConfig是我自定義的starter。如下所示，我在測試工程中添加了自定義starter的依賴，所以SpringBoot就能掃描到。


1 <dependency> 
 2     <groupId>com.demo</groupId> 
 3     <artifactId>demo-spring-boot-starter</artifactId> 
 4     <version>0.0.1-RELEASE</version> 
 5 </dependency>


 　　繼續看Set<String> exclusions = getExclusions(annotationMetadata, attributes);方法，該方法是排除主類上@SpringBootApplication註解上排除的自動裝配的類。比如我們在該註解上排除我們自定義starter的自動裝配的類，@SpringBootApplication(exclude = {com.demo.starter.config.DemoConfig.class})（當然也可以用excludeName進行排除），那麼在後面的configurations.removeAll(exclusions);方法中將會刪除我們的com.demo.starter.config.DemoConfig.class。


　　configurations = filter(configurations, autoConfigurationMetadata);該行代碼將會過濾掉不需要裝配的類。過濾的邏輯有很多，比如我們常用的@ConditionXXX註解。如下所示：


 1 @ConditionalOnBean:容器中有指定的Bean  
  2 @ConditionalOnClass：當類路徑下有指定的類 
  3 @ConditionalOnExpression:基於SpEL表達式作為判斷條件   
  4 @ConditionalOnJava:基於JVM版本作為判斷條件   
  5 @ConditionalOnJndi:在JNDI存在的條件下查找指定的位置   
  6 @ConditionalOnMissingBean:當容器中沒有指定Bean的情況下   
  7 @ConditionalOnMissingClass:當類路徑下沒有指定的類 
  8 @ConditionalOnNotWebApplication:當前項目不是Web項目 
  9 @ConditionalOnProperty:配置文件中指定的屬性是否有指定的值   
 10 @ConditionalOnResource:類路徑下是否有指定的資源   
 11 @ConditionalOnSingleCandidate:當指定Bean在容器中只有一個，或者雖然有多個但是指定首選Bean 
 12 @ConditionalOnWebApplication:當前項目是Web項目的條件下

 　　至於如何將這些類解析成BeanDefinition並註冊進beanDefinition中的，和上一節講的過程是一樣的，不再贅述了。


　　debug，跳過refresh()方法中的invokeBeanFactoryPostProcessors(beanFactory);方法。如下圖所示，最終在beanFactory的BeanDefinitionMap中找到了自定義starter中的自動裝配的類。



 


　　綜合本文和上一篇博文我們詳細的梳理了IoC容器的初始化過程，到此IoC容器的初始化過程就結束了。


 


　　


　　原創不易，轉載請註明出處。


　　如有錯誤的地方還請留言指正。

【精選推薦文章】



如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站，提高曝光率!!



想要讓你的商品在網路上成為最夯、最多人討論的話題?



網頁設計公司推薦更多不同的設計風格，搶佔消費者視覺第一線



不管是台北網頁設計公司、台中網頁設計公司，全省皆有專員為您服務



想知道最厲害的台北網頁設計公司推薦、台中網頁設計公司推薦專業設計師"嚨底家"!!


Orignal From: SpringBoot啟動流程分析（五）：SpringBoot自動裝配原理實現

留言

張貼留言

這個網誌中的熱門文章

Python 併發總結，多線程，多進程，異步IO

1 測量函數運行時間 import time def profile(func): def wrapper(*args, ** kwargs): import time start = time.time() func( *args, ** kwargs) end = time.time() print ' COST: {} ' .format(end - start) return wrapper @profile def fib(n): if n<= 2 : return 1 return fib(n-1) + fib(n-2 ) fib( 35 )   2 啟動多個線程，並等待完成   2.1 使用threading.enumerate() import threading for i in range(2 ): t = threading.Thread(target=fib, args=(35 ,)) t.start() main_thread = threading.currentThread() for t in threading.enumerate(): if t is main_thread: continue t.join()   2.2 先保存啟動的線程 threads = [] for i in range(5 ): t = Thread(target=foo, args= (i,)) threads.append(t) t.start() for t in threads: t.join()   3 使用信號量，限制同時能有幾個線程訪問臨界區 from threading import Semaphore import time sema = Semaphor...
張貼留言
閱讀完整內容

高雄十大包子名店出爐

, 圖文：吳恩文 高雄包子大賽落幕了，我只能就我個人意見， 介紹一下前十名這些包子，但是不能代表其他四位評審的意見，雖然身為評審長，我通常不會第一個表示意見，以免影響其他評審， 我主要工作是負責發問。   這次參賽的素包子很少，而且都不夠細致，又偏油，我不愛， 但是第一名的甜芝麻包－熔岩黑金包，竟然是素食得名－ 漢來蔬食巨蛋店。   這包子賣相太好，竹炭粉的黑色外皮刷上金粉，一上桌，眾人驚呼， 搶拍照，內餡是芝麻餡，混一點花生醬增稠，加入白糖芝麻油， 熔岩爆漿的程度剛剛好，我一直以為芝麻要配豬油才行、 但是選到好的黑芝麻油一樣不減香醇， 當下有二位評審就想宅配回家。   尤其特別的是，黑芝麻餡室溫易化，師傅必須要輪班躲在冷藏室內， 穿著大外套才能包，一天包不了多少，我笑說，漢來美食，集團餐廳那麼多，實力雄厚，根本是「 奧運選手報名參加村裡運動會」嘛，其他都是小包子店啊， 但是沒辦法，顯然大家都覺得它好看又好吃， 目前限定漢來蔬食高雄巨蛋店，二顆88元，可以冷凍宅配， 但是要排一陣子，因為供不應求，聽說，四月份， 台北sogo店開始會賣。   第二名的包子，左營寬來順早餐店，顯然平易近人的多，一顆肉包， 十塊錢，是所有參賽者中最便宜的，當然，個頭也小， 它的包子皮明顯和其他不同，灰灰的老麵，薄但紮實有嚼勁， 肉餡新鮮帶汁，因為打了些水，味道極其簡單，就是蔥薑，塩， 香油，薑味尤其明顯，是老眷村的味道， 而特別的是老闆娘是台灣本省人， 當年完全是依據眷村老兵的口味一步一步調整而來，沒有加什麼糖、 五香粉，胡椒粉，油蔥酥。就是蔥薑豬肉和老麵香，能得名， 應該是它的平實無華，鮮美簡單，打動人心。   這是標準的心靈美食，可以撫慰人心，得名之前，寛來順已經天天排隊，現在，恐怕要排更久了， 建議大家六七點早點上門。   第三名，「專十一」很神奇，我記得比賽最後， 大家連吃了幾家不能引起共鳴的包子，有些累，到了專十一， 就坐著等包子，其他評審一吃，就催我趕快試，我一吃， 也醒了大半。   它的包子皮厚薄適中，但是高筋麵粉高些，老麵加一點點酵母， 我心中，它的皮屬一屬二，至於餡又多又好吃，蛋黃還是切丁拌入， 不是整顆放，吃起來「美味、均衡、飽滿」。一顆二十元。   老闆是陸軍專科十一期畢業取名專十一，...
張貼留言
閱讀完整內容

韋伯連續劇終於更新 期待第一季順利完結

　　地球天文學界的跳票大王詹姆斯·韋伯空間望遠鏡 (James Webb Space Telescope，縮寫為 JWST)自 1996 年以來斷斷續續不按劇本演出的連續劇終於讓焦慮的觀眾們又等到了一次更新：五層遮陽罩測試順利完成。 裝配完成的韋伯望遠鏡與好夥伴遮陽罩同框啦。Credit: NASA 　　嚴格的測試是任何空間任務順利成功的重中之重。遮陽罩，這個韋伯望遠鏡異常重要的親密夥伴，要是無法正常運轉的話，韋伯的這一季天文界連續劇說不準就要一直拖更了。 　　詹姆斯·韋伯空間望遠鏡是歷史上造出的最先進的空間望遠鏡。它不僅是一架紅外望遠鏡，還具有特別高的靈敏度。但想要達到辣么高的靈敏度來研究系外行星和遙遠的宇宙童年，韋伯童鞋必須非常"冷靜"，體溫升高的話，靈敏度會大大折損。這個時候，遮陽罩就要大顯身手啦。 　　遮陽罩在韋伯的設計中至關重要。韋伯望遠鏡會被發射到拉格朗日 L2 點，運行軌道很高，遠離太陽、地球與月球。太陽是韋伯的主要熱量干擾的來源，其次是地球與月球。遮陽罩會有效阻斷來自這三大熱源的能量並保護韋伯維持在工作溫度正常運轉。這個工作溫度指的是零下 220 攝氏度(-370 華氏度；50 開爾文)。 上圖中我們可以看出，韋伯望遠鏡的配置大致可分為兩部分：紅色較熱的一面溫度為 85 攝氏度，藍色較冷的一面溫度達到零下 233 攝氏度。紅色的這部分中，儀器包括太陽能板、通信設備、計算機、以及轉向裝置。藍色部分的主要裝置包括鏡面、探測器、濾光片等。Credit: STSci. 　　遮陽罩的那一部分和望遠鏡的鏡面這部分可以產生非常極端的溫差。遮陽的這面溫度可以達到 110 攝氏度，足以煮熟雞蛋，而背陰處的部分溫度極低，足以凍結氧氣。 　　工程師們剛剛完成了五層遮陽罩的測試，按照韋伯在 L2 時的運行狀態安裝了遮陽罩。L2 距離地球約 160 萬公里。NASA 表示這些測試使用了航天器的自帶系統來展開遮陽罩，測試目前都已成功完成。韋伯望遠鏡遮陽罩負責人 James Cooper 介紹說這是遮陽罩"第一次在望遠鏡系統的电子設備的控制下展開。儘管這個任務非常艱巨，難度高，但測試順利完成，遮陽罩展開時的狀態非常驚艷"。 　　遮陽罩由五層 Kapton 製成。Kapton 是一種聚酰亞胺薄膜材料， 耐高溫絕...
張貼留言
閱讀完整內容