网站公司建立,做一个微网站平台,重庆涪陵网站设计公司哪家专业,wordpress附件大小前言 为什么Spring Boot条件注解那么多#xff0c;而标题中是ConditionalOnBean呢#xff1f; 因为#xff0c;相比之下我们用的比较多的条件装配注解也就是ConditionalOnClass、ConditionalOnBean了#xff0c;而ConditionalOnClass对顺序并不敏感#xff08;说白了就是判…前言 为什么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 RedisTemplateObject, Object redisTemplate() {RedisTemplateObject, Object template new RedisTemplate(); //巴拉巴拉一大堆个性化的逻辑//template.setXXX();return template;}
}public class RedisAutoConfiguration {//这是Spring Boot自动装配的配置类BeanConditionalOnMissingBean(name redisTemplate)ConditionalOnSingleCandidate(RedisConnectionFactory.class)public RedisTemplateObject, Object redisTemplate(RedisConnectionFactory redisConnectionFactory) {RedisTemplateObject, Object template new RedisTemplate();template.setConnectionFactory(redisConnectionFactory);return template;}BeanConditionalOnMissingBeanConditionalOnSingleCandidate(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是一个接口主要作用是向容器中导入BDDeferredImportSelector是一个继承了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的主要逻辑流程图也附上有需要的可以看看。
