SpringBoot之自动装配原理DataSourceAutoConfiguration注解剖析

自动装配候选类满足候选bean流程如下：

1. 解析@Conditional & @Conditional 引申出的相关注解【@ConditionalOnClass、@ConditionalOnMissingBean】判断当前自动装配类是否需要跳过skip作为候选bean的流程。
2. 候选类存在@Component注解则加载其全部的内部类，当然内部类必须存在@Configuration注解。
3. 处理当前候选类@ComponentScans注解引入的新候选类，当然内部类必须存在@Configuration注解。
4. 处理当前候选类@Import注解导入的新候选类。
5. 处理当前候选类@Bean注解引入的新候选类。

如果步骤1不成立，则表明当前自动装配候选类不具有候选bean的条件，直接中断候选流程。 

如果步骤1成立则当前自动装配的候选类一定将成为IOC容器的候选bean。

步骤2加载内部member类的目的：将这些内部类尝试也作为IOC容器的候选bean。

步骤3@Import注解的目的：将导入的候选类试图也作为IOC容器的候选bean。

内部member类 & @Import注解导入的类均为多个新的候选类，不管是步骤2还是步骤4优先遍历其每一个新增候选类，其流程如上步骤1 ~ 步骤5。

首先通过 DeferredImportSelectorGroupingHandler 找到候选类DataSourceAutoConfiguration。

@Configuration(proxyBeanMethods = false)
@ConditionalOnClass({ DataSource.class, EmbeddedDatabaseType.class })
@EnableConfigurationProperties(DataSourceProperties.class)
@Import({ DataSourcePoolMetadataProvidersConfiguration.class, DataSourceInitializationConfiguration.class })
public class DataSourceAutoConfiguration {
 
    @Configuration(proxyBeanMethods = false)
    @Conditional(EmbeddedDatabaseCondition.class)
    @ConditionalOnMissingBean({ DataSource.class, XADataSource.class })
    @Import(EmbeddedDataSourceConfiguration.class)
    protected static class EmbeddedDatabaseConfiguration {
 
    }
 
    @Configuration(proxyBeanMethods = false)
    @Conditional(PooledDataSourceCondition.class)
    @ConditionalOnMissingBean({ DataSource.class, XADataSource.class })
    @Import({ DataSourceConfiguration.Hikari.class, DataSourceConfiguration.Tomcat.class,
        DataSourceConfiguration.Dbcp2.class, DataSourceConfiguration.Generic.class,
        DataSourceJmxConfiguration.class })
    protected static class PooledDataSourceConfiguration {
 
    }
    //解析@Conditional注解时，会同时加载当前注解嵌套的其他注解OnPropertyCondition、@Conditional，并分别触发各自注解的甄别流程
    static class PooledDataSourceCondition extends AnyNestedCondition {
 
        PooledDataSourceCondition() {
            super(ConfigurationPhase.PARSE_CONFIGURATION);
        }
        // 如果存在显式配置spring.datasource.type，则条件类PooledDataSourceCondition必有效
        @ConditionalOnProperty(prefix = "spring.datasource", name = "type")
        static class ExplicitType {
 
        }
        // 如果ExplicitType不成立，则选择判断条件类PooledDataSourceAvailableCondition
        @Conditional(PooledDataSourceAvailableCondition.class)
        static class PooledDataSourceAvailable {
 
        }
 
    }
 
    static class PooledDataSourceAvailableCondition extends SpringBootCondition {
 
        @Override
        public ConditionOutcome getMatchOutcome(ConditionContext context, AnnotatedTypeMetadata metadata) {
            ConditionMessage.Builder message = ConditionMessage.forCondition("PooledDataSource");
            // 如果HikariDataSource、org.apache.tomcat.jdbc.pool.DataSource、BasicDataSource三种数据库类型，只要项目中存在任一一种，则条件类PooledDataSourceAvailable必有效
            if (DataSourceBuilder.findType(context.getClassLoader()) != null) {
                return ConditionOutcome.match(message.foundExactly("supported DataSource"));
            }
            return ConditionOutcome.noMatch(message.didNotFind("supported DataSource").atAll());
        }
 
    }
 
    static class EmbeddedDatabaseCondition extends SpringBootCondition {
 
        private final SpringBootCondition pooledCondition = new PooledDataSourceCondition();
 
        @Override
        public ConditionOutcome getMatchOutcome(ConditionContext context, AnnotatedTypeMetadata metadata) {
            ConditionMessage.Builder message = ConditionMessage.forCondition("EmbeddedDataSource");
            if (anyMatches(context, metadata, this.pooledCondition)) {
              return ConditionOutcome.noMatch(message.foundExactly("supported pooled data source"));
            }
            EmbeddedDatabaseType type = EmbeddedDatabaseConnection.get(context.getClassLoader()).getType();
            if (type == null) {
              return ConditionOutcome.noMatch(message.didNotFind("embedded database").atAll());
            }
            return ConditionOutcome.match(message.found("embedded database").items(type));
        }
 
    }
 
}

1. 优先解析@ConditionalOnClass注解，如果不满足条件则直接中断流程，候选类DataSourceAutoConfiguration直接放弃。
2. 加载DataSourceAutoConfiguration类内部的内部类即EmbeddedDatabaseConfiguration、PooledDataSourceConfiguration。
3. 解析@Import注解导入的候选类。

1. 解析@ConditionalOnClass注解

2.DataSourceAutoConfiguration类内部的内部类

内部类包含EmbeddedDatabaseConfiguration、PooledDataSourceConfiguration。继续按照标准流程分析每个内部类。

如果每个内部类显式实现Order接口，则按照顺序依次分析每个内部类，否则内部类集合是无序的。

DataSourceAutoConfiguration这俩内部类，其类本身没有任何属性元素，即使这样这俩内部类也会类似DataSourceAutoConfiguration被添加到ConfigurationClassParser属性configurationClasses中。但是这种情况下内部类本身没有任何实际意义，真正需要的是内部类@Import注解导入的新候选类。

Hikari、Tomcat、Dbcp2、Generic、DataSourceJmxConfiguration这几种数据库类型选择过程：

内部类@Conditional & @Conditional 引申出的相关注解必须满足条件，否则还尚未解析@Import注解就提前终止流程了。

PooledDataSourceCondition实现了接口AnyNestedCondition：表示@ConditionalOnProperty、@Conditional这俩条件只需满足一个就不会放弃PooledDataSourceConfiguration。

遍历@Import注解导入的每一个候选类：每一个候选类又是一个完整流程...

3.解析@Import注解导入的候选类

通过@Import注解导入的DataSourcePoolMetadataProvidersConfiguration.class, DataSourceInitializationConfiguration.class两个类，其分析流程是最晚的，即DataSourceAutoConfiguration所有内部类解析完毕之后才是解析该俩类的时机。

解析DataSourceAutoConfiguration候选类过程中涉及至少两部分Import：DataSourceAutoConfiguration类导入的候选类、内部类PooledDataSourceConfiguration导入的候选类、甚至DataSourceConfiguration.Hikari类也能导入候选类。按照从外到里的解析流程，内部的Import属性并不影响外部的。

DataSourceConfiguration静态内部类满足与否，内部类PooledDataSourceConfiguration都会被纳入ConfigurationClassParser属性configurationClasses中；当然，内部类PooledDataSourceConfiguration、EmbeddedDatabaseConfiguration两者有没有满足条件都不会影响DataSourceAutoConfiguration被纳入ConfigurationClassParser属性configurationClasses中， 也不影响DataSourcePoolMetadataProvidersConfiguration、DataSourceInitializationConfiguration的解析流程。

总结：自动装配候选类存在的必要性是为了通过 @Import 、@Bean注解注入新的bean；当前候选类@Conditional 相关注解只要满足条件，@Import 、@Bean流程必然会被执行；至于候选类内部类的解析结果并不会影响候选类@Import注解的功能执行【前提候选类@Conditional 相关注解满足条件】；