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註解來實現的。

本文作者爲SylvanasSun([email protected])，首發於SylvanasSun’s Blog。

原文鏈接：https://sylvanassun.github.io/2018/01/08/2018-01-08-spring_boot_auto_configure/

什麼是@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的初始參數中設置。

dispatcher

org.springframework.web.servlet.DispatcherServlet

spring.profiles.active

PROD

但這種方法只侷限於簡單的情況，而且通過源碼我們可以發現@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 {

@Override

public boolean matches(ConditionContext conditionContext, AnnotatedTypeMetadata metadata) {

String enabledDBType = System.getProperty("dbType"); // 獲得系統參數 dbType

// 如果該值等於MySql，則條件成立

return (enabledDBType != null && enabledDBType.equalsIgnoreCase("MySql"));

}

}

// 與上述邏輯一致

public class MongoDBDatabaseTypeCondition implements Condition {

@Override

public 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 {

@Override

public boolean matches(ConditionContext conditionContext, AnnotatedTypeMetadata metadata) {

try {

Class.forName("com.mongodb.Server");

return true;

} catch (ClassNotFoundException e) {

return false;

}

}

}

public class MongoDriverNotPresentsCondition implements Condition {

@Override

public 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 {

@Override

public 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 {

@Override

public 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 {

@Override

public boolean matches(ConditionContext conditionContext, AnnotatedTypeMetadata metadata) {

Map attributes = metadata

.getAnnotationAttributes(DatabaseType.class.getName());

String type = (String) attributes.get("value");

// 默認值爲MySql

String 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 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 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 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 list, List 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 getMatches(Collection 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。

作者：SylvanasSun

原文：https://sylvanassun.github.io/2018/01/08/2018-01-08-spring_boot_auto_configure/