javascript
Spring Boot是如何实现自动配置的？
原文：sylvanassun.github.io/2018/01/08/2018-01-08-spring_boot_auto_configure/
Spring Boot 是 Spring 旗下眾多的子項目之一，其理念是約定優于配置，它通過實現了自動配置（大多數用戶平時習慣設置的配置作為默認配置）的功能來為用戶快速構建出標準化的應用。
Spring Boot 的特點可以概述為如下幾點：
-
內置了嵌入式的 Tomcat、Jetty 等 Servlet 容器，應用可以不用打包成War 格式，而是可以直接以 Jar 格式運行。
-
提供了多個可選擇的 ”starter ” 以簡化Maven的依賴管理（也支持Gradle），讓您可以按需加載需要的功能模塊。
-
盡可能地進行自動配置，減少了用戶需要動手寫的各種冗余配置項，Spring Boot 提倡無XML配置文件的理念，使用Spring Boot生成的應用完全不會生成任何配置代碼與XML配置文件。
-
提供了一整套的對應用狀態的監控與管理的功能模塊（通過引入spring-boot-starter-actuator），包括應用的線程信息、內存信息、應用是否處于健康狀態等，為了滿足更多的資源監控需求，Spring Cloud中的很多模塊還對其進行了擴展。
有關Spring Boot的使用方法就不做多介紹了，如有興趣請自行閱讀官方文檔Spring Boot或其他文章。
如今微服務的概念愈來愈熱，轉型或嘗試微服務的團隊也在如日漸增，而對于技術選型，Spring Cloud是一個比較好的選擇，它提供了一站式的分布式系統解決方案，包含了許多構建分布式系統與微服務需要用到的組件，例如服務治理、API網關、配置中心、消息總線以及容錯管理等模塊。可以說，Spring Cloud”全家桶”極其適合剛剛接觸微服務的團隊。似乎有點跑題了，不過說了這么多，我想要強調的是，Spring Cloud中的每個組件都是基于Spring Boot構建的，而理解了Spring Boot的自動配置的原理，顯然也是有好處的。
Spring Boot的自動配置看起來神奇，其實原理非常簡單，背后全依賴于@Conditional注解來實現的。
什么是@Conditional？
@Conditional是由Spring 4提供的一個新特性，用于根據特定條件來控制Bean的創建行為。而在我們開發基于Spring的應用的時候，難免會需要根據條件來注冊Bean。
例如，你想要根據不同的運行環境，來讓Spring注冊對應環境的數據源Bean，對于這種簡單的情況，完全可以使用@Profile注解實現，就像下面代碼所示：
@Configuration public class AppConfig {@Bean@Profile("DEV")public DataSource devDataSource() {...}@Bean@Profile("PROD")public DataSource prodDataSource() {...} }剩下只需要設置對應的Profile屬性即可，設置方法有如下三種：
-
通過context.getEnvironment().setActiveProfiles("PROD")來設置Profile屬性。
-
通過設定jvm的spring.profiles.active參數來設置環境（Spring Boot中可以直接在application.properties配置文件中設置該屬性）。
-
通過在DispatcherServlet的初始參數中設置。
但這種方法只局限于簡單的情況，而且通過源碼我們可以發現@Profile自身也使用了@Conditional注解。
package?org.springframework.context.annotation; @Target({ElementType.TYPE, ElementType.METHOD}) @Retention(RetentionPolicy.RUNTIME) @Documented @Conditional({ProfileCondition.class})?// 組合了Conditional注解 public?@interface?Profile {String[] value(); } package?org.springframework.context.annotation; class?ProfileCondition?implements?Condition?{ProfileCondition() {}// 通過提取出@Profile注解中的value值來與profiles配置信息進行匹配public?boolean?matches(ConditionContext context, AnnotatedTypeMetadata metadata)?{if(context.getEnvironment() !=?null) {MultiValueMap attrs = metadata.getAllAnnotationAttributes(Profile.class.getName());if(attrs !=?null) {Iterator var4 = ((List)attrs.get("value")).iterator();Object value;do?{if(!var4.hasNext()) {return?false;}value = var4.next();}?while(!context.getEnvironment().acceptsProfiles((String[])((String[])value)));return?true;}}return?true;} }在業務復雜的情況下，顯然需要使用到@Conditional注解來提供更加靈活的條件判斷，例如以下幾個判斷條件：
-
在類路徑中是否存在這樣的一個類。
-
在Spring容器中是否已經注冊了某種類型的Bean（如未注冊，我們可以讓其自動注冊到容器中，上一條同理）。
-
一個文件是否在特定的位置上。
-
一個特定的系統屬性是否存在。
-
在Spring的配置文件中是否設置了某個特定的值。
舉個栗子，假設我們有兩個基于不同數據庫實現的DAO，它們全都實現了UserDao，其中JdbcUserDAO與MySql進行連接，MongoUserDAO與MongoDB進行連接。
現在，我們有了一個需求，需要根據命令行傳入的系統參數來注冊對應的UserDao，就像java -jar app.jar -DdbType=MySQL會注冊JdbcUserDao，而java -jar app.jar -DdbType=MongoDB則會注冊MongoUserDao。
使用@Conditional可以很輕松地實現這個功能，僅僅需要在你自定義的條件類中去實現Condition接口，讓我們來看下面的代碼。（以下案例來自：https://dzone.com/articles/how-springboot-autoconfiguration-magic-works）
public?interface?UserDAO?{.... } public?class?JdbcUserDAO?implements?UserDAO?{.... } public?class?MongoUserDAO?implements?UserDAO?{.... } public?class?MySQLDatabaseTypeCondition?implements?Condition?{@Overridepublic?boolean?matches(ConditionContext conditionContext, AnnotatedTypeMetadata metadata)?{String enabledDBType = System.getProperty("dbType");?// 獲得系統參數 dbType// 如果該值等于MySql，則條件成立return?(enabledDBType !=?null?&& enabledDBType.equalsIgnoreCase("MySql"));} } // 與上述邏輯一致 public?class?MongoDBDatabaseTypeCondition?implements?Condition?{@Overridepublic?boolean?matches(ConditionContext conditionContext, AnnotatedTypeMetadata metadata)?{String enabledDBType = System.getProperty("dbType");return?(enabledDBType !=?null?&& enabledDBType.equalsIgnoreCase("MongoDB"));} } // 根據條件來注冊不同的Bean @Configuration public?class?AppConfig?{@Bean@Conditional(MySQLDatabaseTypeCondition.class)public?UserDAO?jdbcUserDAO()?{return?new?JdbcUserDAO();}@Bean@Conditional(MongoDBDatabaseTypeCondition.class)public?UserDAO?mongoUserDAO()?{return?new?MongoUserDAO();} }現在，我們又有了一個新需求，我們想要根據當前工程的類路徑中是否存在MongoDB的驅動類來確認是否注冊MongoUserDAO。為了實現這個需求，可以創建檢查MongoDB驅動是否存在的兩個條件類。
public?class?MongoDriverPresentsCondition?implements?Condition?{@Overridepublic?boolean?matches(ConditionContext conditionContext, AnnotatedTypeMetadata metadata)?{try?{Class.forName("com.mongodb.Server");return?true;}?catch?(ClassNotFoundException e) {return?false;}} } public?class?MongoDriverNotPresentsCondition?implements?Condition?{@Overridepublic?boolean?matches(ConditionContext conditionContext, AnnotatedTypeMetadata metadata)?{try?{Class.forName("com.mongodb.Server");return?false;}?catch?(ClassNotFoundException e) {return?true;}} }假如，你想要在UserDAO沒有被注冊的情況下去注冊一個UserDAOBean，那么我們可以定義一個條件類來檢查某個類是否在容器中已被注冊。
public?class?UserDAOBeanNotPresentsCondition?implements?Condition?{@Overridepublic?boolean?matches(ConditionContext conditionContext, AnnotatedTypeMetadata metadata)?{UserDAO userDAO = conditionContext.getBeanFactory().getBean(UserDAO.class);return?(userDAO ==?null);} }如果你想根據配置文件中的某項屬性來決定是否注冊MongoDAO，例如app.dbType是否等于MongoDB，我們可以實現以下的條件類。
public?class?MongoDbTypePropertyCondition?implements?Condition?{@Overridepublic?boolean?matches(ConditionContext conditionContext, AnnotatedTypeMetadata metadata)?{String dbType = conditionContext.getEnvironment().getProperty("app.dbType");return?"MONGO".equalsIgnoreCase(dbType);} }我們已經嘗試并實現了各種類型的條件判斷，接下來，我們可以選擇一種更為優雅的方式，就像@Profile一樣，以注解的方式來完成條件判斷。首先，我們需要定義一個注解類。
@Target({ ElementType.TYPE, ElementType.METHOD }) @Retention(RetentionPolicy.RUNTIME) @Documented @Conditional(DatabaseTypeCondition.class) public?@interface?DatabaseType {String?value(); }具體的條件判斷邏輯在DatabaseTypeCondition類中，它會根據系統參數dbType來判斷注冊哪一個Bean。
public?class?DatabaseTypeCondition?implements?Condition {@Overridepublic?boolean?matches(ConditionContext conditionContext, AnnotatedTypeMetadata metadata) {Map<String,?Object> attributes = metadata.getAnnotationAttributes(DatabaseType.class.getName());String?type?= (String) attributes.get("value");// 默認值為MySqlString?enabledDBType = System.getProperty("dbType",?"MySql");return?(enabledDBType !=?null?&&?type?!=?null?&& enabledDBType.equalsIgnoreCase(type));} }最后，在配置類應用該注解即可。
@Configuration @ComponentScan public class AppConfig {@Bean@DatabaseType("MySql")public UserDAO jdbcUserDAO() {return?new?JdbcUserDAO();}@Bean@DatabaseType("mongoDB")public?UserDAO?mongoUserDAO() {return?new?MongoUserDAO();} }AutoConfigure源碼分析
通過了解@Conditional注解的機制其實已經能夠猜到自動配置是如何實現的了，接下來我們通過源碼來看看它是怎么做的。本文中講解的源碼基于Spring Boot 1.5.9版本（最新的正式版本）。
使用過Spring Boot的童鞋應該都很清楚，它會替我們生成一個入口類，其命名規格為ArtifactNameApplication，通過這個入口類，我們可以發現一些信息。
@SpringBootApplication public?class?DemoApplication?{public?static?void?main(String[] args)?{SpringApplication.run(DemoApplication.class, args);} }首先該類被@SpringBootApplication注解修飾，我們可以先從它開始分析，查看源碼后可以發現它是一個包含許多注解的組合注解。
@Target({ElementType.TYPE}) @Retention(RetentionPolicy.RUNTIME) @Documented @Inherited @SpringBootConfiguration @EnableAutoConfiguration @ComponentScan(excludeFilters = {@Filter(type = FilterType.CUSTOM,classes = {TypeExcludeFilter.class} ),?@Filter(type = FilterType.CUSTOM,classes = {AutoConfigurationExcludeFilter.class} )} ) public?@interface?SpringBootApplication {@AliasFor(annotation = EnableAutoConfiguration.class,attribute =?"exclude")Class<?>[] exclude() default {};@AliasFor(annotation = EnableAutoConfiguration.class,attribute =?"excludeName")String[] excludeName() default {};@AliasFor(annotation = ComponentScan.class,attribute =?"basePackages")String[] scanBasePackages() default {};@AliasFor(annotation = ComponentScan.class,attribute =?"basePackageClasses")Class<?>[] scanBasePackageClasses() default {}; }該注解相當于同時聲明了@Configuration、@EnableAutoConfiguration與@ComponentScan三個注解（如果我們想定制自定義的自動配置實現，聲明這三個注解就足夠了），而@EnableAutoConfiguration是我們的關注點，從它的名字可以看出來，它是用來開啟自動配置的，源碼如下：
@Target({ElementType.TYPE}) @Retention(RetentionPolicy.RUNTIME) @Documented @Inherited @AutoConfigurationPackage @Import({EnableAutoConfigurationImportSelector.class}) public?@interface?EnableAutoConfiguration {String?ENABLED_OVERRIDE_PROPERTY =?"spring.boot.enableautoconfiguration";Class<?>[] exclude()?default?{};String[] excludeName()?default?{}; }我們發現@Import（Spring 提供的一個注解，可以導入配置類或者Bean到當前類中）導入了EnableAutoConfigurationImportSelector類，根據名字來看，它應該就是我們要找到的目標了。不過查看它的源碼發現它已經被Deprecated了，而官方API中告知我們去查看它的父類AutoConfigurationImportSelector。
/**?@deprecated?*/ @Deprecated public?class?EnableAutoConfigurationImportSelector?extends?AutoConfigurationImportSelector?{public?EnableAutoConfigurationImportSelector()?{}protected?boolean?isEnabled(AnnotationMetadata metadata)?{return?this.getClass().equals(EnableAutoConfigurationImportSelector.class)?((Boolean)this.getEnvironment().getProperty("spring.boot.enableautoconfiguration", Boolean.class, Boolean.valueOf(true))).booleanValue():true;} }由于AutoConfigurationImportSelector的源碼太長了，這里我只截出關鍵的地方，顯然方法selectImports是選擇自動配置的主入口，它調用了其他的幾個方法來加載元數據等信息，最后返回一個包含許多自動配置類信息的字符串數組。
public?String[] selectImports(AnnotationMetadata annotationMetadata) {if(!this.isEnabled(annotationMetadata)) {return?NO_IMPORTS;}?else?{try?{AutoConfigurationMetadata ex = AutoConfigurationMetadataLoader.loadMetadata(this.beanClassLoader);AnnotationAttributes attributes =?this.getAttributes(annotationMetadata);List configurations =?this.getCandidateConfigurations(annotationMetadata, attributes);configurations =?this.removeDuplicates(configurations);configurations =?this.sort(configurations, ex);Set exclusions =?this.getExclusions(annotationMetadata, attributes);this.checkExcludedClasses(configurations, exclusions);configurations.removeAll(exclusions);configurations =?this.filter(configurations, ex);this.fireAutoConfigurationImportEvents(configurations, exclusions);return?(String[])configurations.toArray(new?String[configurations.size()]);}?catch?(IOException var6) {throw?new?IllegalStateException(var6);}} }重點在于方法getCandidateConfigurations()返回了自動配置類的信息列表，而它通過調用SpringFactoriesLoader.loadFactoryNames()來掃描加載含有META-INF/spring.factories文件的jar包，該文件記錄了具有哪些自動配置類。（建議還是用IDE去看源碼吧，這些源碼單行實在太長了，估計文章中的觀看效果很差）
protected?List<String> getCandidateConfigurations(AnnotationMetadata metadata, AnnotationAttributes attributes) {List?configurations = SpringFactoriesLoader.loadFactoryNames(this.getSpringFactoriesLoaderFactoryClass(), this.getBeanClassLoader());Assert.notEmpty(configurations,?"No auto configuration classes?found in META-INF spring.factories.?If you are using a custom packaging, make sure that file is correct.");return?configurations; }public?static?List<String> loadFactoryNames(Class<?>?factoryClass,?ClassLoader?classLoader)?{String factoryClassName = factoryClass.getName();try?{Enumeration ex = classLoader !=?null?classLoader.getResources("META-INF/spring.factories"):ClassLoader.getSystemResources("META-INF/spring.factories");ArrayList result =?new?ArrayList();while(ex.hasMoreElements()) {URL url = (URL)ex.nextElement();Properties properties = PropertiesLoaderUtils.loadProperties(new?UrlResource(url));String factoryClassNames = properties.getProperty(factoryClassName);result.addAll(Arrays.asList(StringUtils.commaDelimitedListToStringArray(factoryClassNames)));}return?result;}?catch?(IOException var8) {throw?new?IllegalArgumentException("Unable to load ["?+ factoryClass.getName() +?"] factories from location ["?+?"META-INF/spring.factories"?+?"]", var8);} }接下來，我們在spring.factories文件中隨便找一個自動配置類，來看看是怎樣實現的。我查看了MongoDataAutoConfiguration的源碼，發現它聲明了@ConditionalOnClass注解，通過看該注解的源碼后可以發現，這是一個組合了@Conditional的組合注解，它的條件類是OnClassCondition。
@Configuration @ConditionalOnClass({Mongo.class, MongoTemplate.class}) @EnableConfigurationProperties({MongoProperties.class}) @AutoConfigureAfter({MongoAutoConfiguration.class}) public?class?MongoDataAutoConfiguration?{.... } @Target({ElementType.TYPE, ElementType.METHOD}) @Retention(RetentionPolicy.RUNTIME) @Documented @Conditional({OnClassCondition.class}) public @interface ConditionalOnClass {Class<?>[] value() default {};String[] name() default {}; }然后，我們開始看OnClassCondition的源碼，發現它并沒有直接實現Condition接口，只好往上找，發現它的父類SpringBootCondition實現了Condition接口。
class?OnClassCondition?extends?SpringBootCondition?implements?AutoConfigurationImportFilter,?BeanFactoryAware,?BeanClassLoaderAware?{..... } public?abstract?class?SpringBootCondition?implements?Condition?{private?final?Log logger = LogFactory.getLog(this.getClass());public?SpringBootCondition()?{}public?final?boolean?matches(ConditionContext context, AnnotatedTypeMetadata metadata)?{String classOrMethodName = getClassOrMethodName(metadata);try?{ConditionOutcome ex =?this.getMatchOutcome(context, metadata);this.logOutcome(classOrMethodName, ex);this.recordEvaluation(context, classOrMethodName, ex);return?ex.isMatch();}?catch?(NoClassDefFoundError var5) {throw?new?IllegalStateException("Could not evaluate condition on "?+ classOrMethodName +?" due to "?+ var5.getMessage() +?" not found. Make sure your own configuration does not rely on that class. This can also happen if you are @ComponentScanning a springframework package (e.g. if you put a @ComponentScan in the default package by mistake)", var5);}?catch?(RuntimeException var6) {throw?new?IllegalStateException("Error processing condition on "?+?this.getName(metadata), var6);}}public?abstract?ConditionOutcome?getMatchOutcome(ConditionContext var1, AnnotatedTypeMetadata var2); }SpringBootCondition實現的matches方法依賴于一個抽象方法this.getMatchOutcome(context, metadata)，我們在它的子類OnClassCondition中可以找到這個方法的具體實現。
public?ConditionOutcome getMatchOutcome(ConditionContext context, AnnotatedTypeMetadata metadata) {ClassLoader classLoader = context.getClassLoader();ConditionMessage matchMessage = ConditionMessage.empty();// 找出所有ConditionalOnClass注解的屬性List onClasses =?this.getCandidates(metadata, ConditionalOnClass.class);List onMissingClasses;if(onClasses !=?null) {// 找出不在類路徑中的類onMissingClasses =?this.getMatches(onClasses, OnClassCondition.MatchType.MISSING, classLoader);// 如果存在不在類路徑中的類，匹配失敗if(!onMissingClasses.isEmpty()) {return?ConditionOutcome.noMatch(ConditionMessage.forCondition(ConditionalOnClass.class,?new?Object[0]).didNotFind("required class",?"required classes").items(Style.QUOTE, onMissingClasses));}matchMessage = matchMessage.andCondition(ConditionalOnClass.class,?new?Object[0]).found("required class",?"required classes").items(Style.QUOTE,?this.getMatches(onClasses, OnClassCondition.MatchType.PRESENT, classLoader));}// 接著找出所有ConditionalOnMissingClass注解的屬性// 它與ConditionalOnClass注解的含義正好相反，所以以下邏輯也與上面相反onMissingClasses =?this.getCandidates(metadata, ConditionalOnMissingClass.class);if(onMissingClasses !=?null) {List present =?this.getMatches(onMissingClasses, OnClassCondition.MatchType.PRESENT, classLoader);if(!present.isEmpty()) {return?ConditionOutcome.noMatch(ConditionMessage.forCondition(ConditionalOnMissingClass.class,?new?Object[0]).found("unwanted class",?"unwanted classes").items(Style.QUOTE, present));}matchMessage = matchMessage.andCondition(ConditionalOnMissingClass.class,?new?Object[0]).didNotFind("unwanted class",?"unwanted classes").items(Style.QUOTE,?this.getMatches(onMissingClasses, OnClassCondition.MatchType.MISSING, classLoader));}return?ConditionOutcome.match(matchMessage); } // 獲得所有annotationType注解的屬性 private?List<String> getCandidates(AnnotatedTypeMetadata metadata, Class<?> annotationType) {MultiValueMap attributes = metadata.getAllAnnotationAttributes(annotationType.getName(),?true);ArrayList candidates =?new?ArrayList();if(attributes ==?null) {return?Collections.emptyList();}?else?{this.addAll(candidates, (List)attributes.get("value"));this.addAll(candidates, (List)attributes.get("name"));return?candidates;} } private?void?addAll(List<String> list, List<Object> itemsToAdd) {if(itemsToAdd !=?null) {Iterator var3 = itemsToAdd.iterator();while(var3.hasNext()) {Object?item = var3.next();Collections.addAll(list, (String[])((String[])item));}} } ? ? // 根據matchType.matches方法來進行匹配 private?List<String> getMatches(Collection<String> candidates, OnClassCondition.MatchType matchType, ClassLoader classLoader) {ArrayList matches =?new?ArrayList(candidates.size());Iterator var5 = candidates.iterator();while(var5.hasNext()) {String?candidate = (String)var5.next();if(matchType.matches(candidate, classLoader)) {matches.add(candidate);}}return?matches; }關于match的具體實現在MatchType中，它是一個枚舉類，提供了PRESENT和MISSING兩種實現，前者返回類路徑中是否存在該類，后者相反。
private?static?enum?MatchType {PRESENT {public?boolean?matches(String className, ClassLoader classLoader)?{return?OnClassCondition.MatchType.isPresent(className, classLoader);}},MISSING {public?boolean?matches(String className, ClassLoader classLoader)?{return?!OnClassCondition.MatchType.isPresent(className, classLoader);}};private?MatchType()?{}// 跟我們之前看過的案例一樣，都利用了類加載功能來進行判斷private?static?boolean?isPresent(String className, ClassLoader classLoader)?{if(classLoader ==?null) {classLoader = ClassUtils.getDefaultClassLoader();}try?{forName(className, classLoader);return?true;}?catch?(Throwable var3) {return?false;}}private?static?Class<?> forName(String className, ClassLoader classLoader)?throws?ClassNotFoundException {return?classLoader !=?null?classLoader.loadClass(className):Class.forName(className);}public?abstract?boolean?matches(String var1, ClassLoader var2); }現在終于真相大白，@ConditionalOnClass的含義是指定的類必須存在于類路徑下，MongoDataAutoConfiguration類中聲明了類路徑下必須含有Mongo.class, MongoTemplate.class這兩個類，否則該自動配置類不會被加載。
在Spring Boot中到處都有類似的注解，像@ConditionalOnBean（容器中是否有指定的Bean），@ConditionalOnWebApplication（當前工程是否為一個Web工程）等等，它們都只是@Conditional注解的擴展。
當你揭開神秘的面紗，去探索本質時，發現其實Spring Boot自動配置的原理就是如此簡單，在了解這些知識后，你完全可以自己去實現自定義的自動配置類，然后編寫出自定義的starter。
總結
以上是生活随笔為你收集整理的Spring Boot是如何实现自动配置的？的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Spring Boot 2发送邮件手把手
- 下一篇： Spring Boot 启动，1 秒搞定