知識星球（點選上方公眾號，可快速關註）
來源：sylvanassun ，
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註解來實現的。
本文作者為SylvanasSun(sylvanas.sun@gmail.com)，首發於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 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。
【關於投稿】
如果大家有原創好文投稿，請直接給公號傳送留言。
① 留言格式：
【投稿】+《 文章標題》+ 文章連結
② 示例：
【投稿】《不要自稱是程式員，我十多年的 IT 職場總結》：http://blog.jobbole.com/94148/
③ 最後請附上您的個人簡介哈~
看完本文有收穫？請轉發分享給更多人
關註「ImportNew」，提升Java技能
