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 {//这是我们自定义的普通配置类
    @Bean
    public 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的人来说,没办法将上述几点串联起来。所以,我们在花费一些篇幅来详细的解释下上面几个点。

  1. 我们都知道一般会在启动类上存在@SpringBootApplication注解,而@SpringBootApplication注解上就标注了@EnableAutoConfiguration。
  2. @EnableAutoConfiguration注解上面配置了@Import(AutoConfigurationImportSelector.class)。
  3. AutoConfigurationImportSelector实现了DeferredImportSelector。
  4. 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是如何保证顺序的。

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

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

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

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

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

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

文章来源地址https://uudwc.com/A/XkDmr

原文地址:https://blog.csdn.net/weixin_44182586/article/details/133432042

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请联系站长进行投诉反馈,一经查实,立即删除!

h
上一篇 2023年10月17日 02:26
【数据结构初阶】六、线性表中的队列(C语言 -- 链式结构实现队列)
下一篇 2023年10月17日 05:56