Spring Boot的自动装配中的@ConditionalOnBean条件装配注解在Spring启动过程中，是如何保证处理顺序靠后的

前言

为什么Spring Boot条件注解那么多，而标题中是@ConditionalOnBean呢？

因为，相比之下我们用的比较多的条件装配注解也就是@ConditionalOnClass、@ConditionalOnBean了，而@ConditionalOnClass对顺序并不敏感（说白了就是判断类加载器是否可以在其路径下加载到Class，所以和Spring的处理顺序没啥关系），但是@ConditionalOnBean就不同了，如果顺序无法保证，那么自动装配中的@ConditionalOnBean就可能会失效。

还有一点需要强调一下，正如Spring Boot官方建议的那样，请在自动装配类中使用条件装配注解，不要在自己定义普通配置类（普通配置类指的是我们自定义的@Configuration配置类）中使用，在普通配置类中使用条件装配注解，能不能生效那就看命了，尤其是@ConditionalOnBean这种对顺序敏感的注解；可能会出现在IDE中生效，但是到了线上就不生效了，因为你光靠ClassLoader的加载顺序是不靠谱的，在不同的操作系统环境下，class文件的加载顺序存在不确定性，文件是由文件系统管理，不同的文件管理系统有不同的机制。

可能有些人会想，我自定义@Configuration的普通配置类，我自己来显示的控制加载顺序，不过有一点请注意，你要控制的是BeanDefinition的注册顺序，而不是Bean的注入顺序；

我能想到的唯一可以控制BeanDefinition注册顺序的方式就是：自定义一个实现BeanDefinitionRegistryPostProcessor接口的实现类，并且还要实现PriorityOrder接口，要保证顺序比ConfigurationClassPostProcessor靠前，这样才有机会提前注册BeanDefinition到容器中；当然你也可以定义一个ApplicationContextInitializer接口实现类，然后通过initialize方法将自定义的BeanDefinitionRegistryPostProcessor接口的实现类添加到容器中，这样不用实现PriorityOrder接口也可以保证在ConfigurationClassPostProcessor前面执行。

不过上面说的BeanDefinitionRegistryPostProcessor接口实现类向容器添加BeanDefinition属于歪门邪道吧，明明正常扫描@Configuration注解来注册的配置类，非要把@Configuration注解去掉或者放到@ComponentScan扫不到的包下，然后由BeanDefinitionRegistryPostProcessor接口硬编码注入，应该也没有人会这么编码。

所以请切记，条件装配注解并不是无敌的，也是需要考虑使用场景的，不能随便的滥用，因此尽量在自动装配配置类中使用条件装配注解！！！

@ConditionalOnBean判断的是容器中是否存在BD，而不是判断的容器中是否存在Bean对象，这一点请注意。

为什么要保证顺序

我们举个例子来说一下@ConditionalOnBean注解处理顺序的重要性。

例子中是@ConditionalOnMissingBean注解，但是和@ConditionalOnBean注解的逻辑基本一致的。下面代码表达的意思就是，我们定义的普通配置类中，对RedisTemplete进行了个性化设置，此时我们肯定希望容器中只存在我们自定义的RedisTemplate；而Spring Boot的自动装配的条件装配机制也确实满足了我们的这种需求；

@Configuration
public class RedisConfig {//这是我们自定义的普通配置类@Beanpublic RedisTemplate<Object, Object> redisTemplate() {RedisTemplate<Object, Object> template = new RedisTemplate<>();	//巴拉巴拉一大堆个性化的逻辑//template.setXXX();return template;}
}public class RedisAutoConfiguration {//这是Spring Boot自动装配的配置类@Bean@ConditionalOnMissingBean(name = "redisTemplate")@ConditionalOnSingleCandidate(RedisConnectionFactory.class)public RedisTemplate<Object, Object> redisTemplate(RedisConnectionFactory redisConnectionFactory) {RedisTemplate<Object, Object> template = new RedisTemplate<>();template.setConnectionFactory(redisConnectionFactory);return template;}@Bean@ConditionalOnMissingBean@ConditionalOnSingleCandidate(RedisConnectionFactory.class)public StringRedisTemplate stringRedisTemplate(RedisConnectionFactory redisConnectionFactory) {StringRedisTemplate template = new StringRedisTemplate();template.setConnectionFactory(redisConnectionFactory);return template;}}

我们假设一下：如果RedisAutoConfiguration自动装配配置类在我们自定义的RedisConfig普通配置类前面执行了，那就会导致当时的容器中不存在名字为redisTemplate的bean对象，当处理我们自定义的RedisConfig配置类的时候，就会报错，因为存在同名的bean了。

总而言之，对于@ConditionalOnBean注解来说，顺序很重要，是必须要保证的。

顺序是如何保证的

关于原理其实还是挺多内容的，因为需要足够清楚Spring的ConfigurationClassPostProcessor以及Spring Boot的AutoConfigurationImportSelector，这样才能彻底掌握原理中的细节内容。考虑到篇幅问题，我们还是以关键逻辑为主，弄清楚@ConditionalOnBean顺序是怎么保证的即可。

首先我们说几点比较关键的基础知识。

@EnableAutoConfiguration：主要作用是开启Spring Boot的自动装配，属于Spring Boot注解；
@Import：主要作用是向容器中导入BeanDefinition，导入的BD直接当做ConfigurationClass来处理；
ImportSelector：是一个接口，主要作用是向容器中导入BD；
DeferredImportSelector：是一个继承了ImportSelector的接口，除了继承的能力外，还额外增加了延迟导入的能力（当然这个延迟导入借助的是Spring对ConfigurationClass的处理流程来实现的，并不是DeferredImportSelector自身具有延迟导入能力的方法）；
AutoConfigurationImportSelector：是一个实现了DeferredImportSelector接口的实现类，自动装配的核心逻辑主要就在这里；

可能对不熟悉Spring的人来说，没办法将上述几点串联起来。所以，我们在花费一些篇幅来详细的解释下上面几个点。

我们都知道一般会在启动类上存在@SpringBootApplication注解，而@SpringBootApplication注解上就标注了@EnableAutoConfiguration。
@EnableAutoConfiguration注解上面配置了@Import(AutoConfigurationImportSelector.class)。
AutoConfigurationImportSelector实现了DeferredImportSelector。
DeferredImportSelector继承了ImportSelector。

@SpringBootConfiguration
@EnableAutoConfiguration
@ComponentScan(excludeFilters = { @Filter(type = FilterType.CUSTOM, classes = TypeExcludeFilter.class),@Filter(type = FilterType.CUSTOM, classes = AutoConfigurationExcludeFilter.class) })
public @interface SpringBootApplication {......此处省略很多无关内容
}@AutoConfigurationPackage
@Import(AutoConfigurationImportSelector.class)
public @interface EnableAutoConfiguration {......此处省略一些无关内容
}public class AutoConfigurationImportSelector implements DeferredImportSelector, BeanClassLoaderAware, ResourceLoaderAware, BeanFactoryAware, EnvironmentAware, Ordered {......此处省略很多无关内容
}public interface DeferredImportSelector extends ImportSelector {......此处省略一些无关内容
}

通过代码示例，我们可以清楚的看到，在编码层面，这几个注解、接口以及实现类已经串起来了。

下面画个流程简图，来说明一下Spring是如何保证顺序的。

绿色为相关度较高的关键代码逻辑；红色条件装配的判断节点；

我们再用文字把流程中的关键点整理一下：

ConfigurationClass的处理分2步；第一步：处理ConfigurationClass的注解信息并保存下来；第二步：对保存下来的信息进行处理，创建BD并注册到容器中。
在第一步中，普通配置类先进行处理，遇到自动装配的AutoConfigurationImportSelector（属于DeferredImportSelector接口类型）会先保存起来，等到普通配置类处理完成后，再进行统一的DeferredImportSelector接口类型的处理；在处理过程中导入的配置类都会放在LinkedHashMap类型的configurationClasses集合中，这样就可以利用默认情况下LinkedHashMap按照插入顺序遍历的特性，来控制普通配置类和自动装配配置类顺序。
在第二步中，已经得到了带有顺序的configurationClasses集合，普通配置类在前，自动装配配置类在后；这样在循环处理的时候，就是先处理的普通配置类，普通配置类处理完成后，已经将相应的BD注册到了容器中；而在处理自动装配配置类的时候，通过条件装配的判断，可以准确的判断出当前容器中是否存在对应的BD，这样就保证了自动装配功能的正常。

结语

虽然@ConditionalOnBean是Spring Boot的注解，但是我们通过流程图发现，大部分核心的代码逻辑都是属于Spring的。因此，@ConditionalOnBean条件装配的顺序就是Spring的DeferredImportSelector接口延迟处理机制来保证的。

对于熟悉Spring源码的人来说，可能看这篇文章很容易；如果不太熟悉，可以了解一下ConfigurationClassPostProcessor这个类，因为对于注解驱动（使用xml配置文件的项目越来越少了）的项目来说，这个类真的是太重要了。这个类处理的是BeanDefinition阶段，因此可以不用对Bean注册阶段有过多的了解。了解了ConfigurationClassPostProcessor这个类，那么读懂条件装配的原理，并且掌握代码逻辑细节，那肯定是轻轻松松儿的。

下面是我整理的关于 ConfigurationClassPostProcessor的主要逻辑流程图，也附上，有需要的可以看看。