關于ConditionalOnMissingBean失效問題的追蹤
遇到一個@ConditionalOnMissingBean失效的問題，今天花點時間來分析一下。
現(xiàn)場回放
services
首先介紹下代碼結構：有RunService,以及它的兩個實現(xiàn)類：TrainRunServiceImpl和CarRunServiceImpl
RunService
public interface RunService {
? ? void run();
}TrainRunServiceImpl
public class TrainRunServiceImpl implements RunService {
? ? @Override
? ? public void run() {
? ? ? ? System.out.println("開火車,wuwuwuwuwu");
? ? }
}CarRunServiceImpl
public class CarRunServiceImpl implements RunService {
? ? @Override
? ? public void run() {
? ? ? ? System.out.println("汽車,dididi");
? ? }
}操作類
操作類MyInitBean中，注入了RunService – byType
@Component
public class MyInitBean implements InitializingBean {
@Autowired
private RunService runService;
@Override
public void afterPropertiesSet() throws Exception {
runService.run();
}
}
configuration
我們在配置類中，注入RunService的實現(xiàn)bean,并通過@ConditionalOnMissingBean來判斷是否注入。
@Configuration
public class MyConfiguration {
@Bean
@ConditionalOnMissingBean
public RunService carRunServiceImpl() {
return new CarRunServiceImpl();
}
@Bean
public RunService trainRunServiceImpl() {
return new TrainRunServiceImpl();
}
}
拋出異常
按照上述的代碼，執(zhí)行后，本以為會成功執(zhí)行，但是卻拋出了異常，異常信息如下：
在spring容器中存在了兩個RunService實現(xiàn)類。
這導致了MyInitBean無法決定它到底該使用這兩個中的哪一個。(默認是byType注入的)
按照上述的異常信息，它給出了兩種解決方案：
@Qualifier
在注入bean時，指定bean的名稱.
@Controller
public class MyInitBean implements InitializingBean {
? ? @Autowired
? ? @Qualifier("carRunServiceImpl")
? ? private RunService runService;
}通過@Configuration配置類注入的bean,默認名稱為方法名稱
? @Bean // ?`trainRunServiceImpl `
? public RunService trainRunServiceImpl() {
? ? ?return new TrainRunServiceImpl();
?}直接在類頭部申明注入的bean,默認名稱為類名稱
@Service ?// ?`trainRunServiceImpl`
public class TrainRunServiceImpl implements RunService {
}@Primary
@Primary的作用是，在bean存在多個候選者且無法決定使用哪一個時，優(yōu)先使用帶有該注解的bean.
在配置類中Configuration添加
? @Bean
? @Primary
? public RunService trainRunServiceImpl() {
? ? ? return new TrainRunServiceImpl();
? }在類申明中添加
@Primary
public class TrainRunServiceImpl implements RunService {
}注意
在上述給出的兩種方法中，無論是使用@Primary還是這里容器中仍然存在多個實現(xiàn)類,
這并不是我們想要的結果。
這里為什么@ConditionalOnMissingBean會失效呢?
問題定位
在進行問題定位前，我們先來回顧一下@ConditionalOnMissingBean的工作原理
工作原理
@ConditionalOnMissingBean
ConditionalOnMissingBean的注解定義如下：
@Target({ ElementType.TYPE, ElementType.METHOD })
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Conditional(OnBeanCondition.class)
public @interface ConditionalOnMissingBean {
?? ?Class<?>[] value() default {};
?? ?String[] type() default {};
?? ?
?? ?//略....
}@ConditionalOnMissingBean通常可以有如下三種使用方式：
? ? @Bean
// ? ?@ConditionalOnMissingBean(type ="xxx.yyy.zzz.service")
// ? ?@ConditionalOnMissingBean(value = RunService.class)
? ? @ConditionalOnMissingBean //無參數(shù)，表示按照返回值類型過濾
? ? public RunService carRunServiceImpl() {
? ? ? ? return new CarRunServiceImpl();
? ? }在注解上看到了一個OnBeanCondition類，在@ConditionalOnBean,ConditionalOnSingleCandidate和ConditionalOnMissingBean都看到了它的身影。
OnBeanCondition
@Order(Ordered.LOWEST_PRECEDENCE)
class OnBeanCondition extends SpringBootCondition implements ConfigurationCondition {
?? ?@Override
?? ?public ConditionOutcome getMatchOutcome(ConditionContext context,
?? ??? ??? ?AnnotatedTypeMetadata metadata) {
?? ??? ?//ConditionalOnBean ?略
?? ??? ?//ConditionalOnSingleCandidate 略
?? ??? ?
?? ??? ?if (metadata.isAnnotated(ConditionalOnMissingBean.class.getName())) {
?? ??? ??? ?//尋找 @ConditionalOnMissingBean 匹配的 type;
?? ??? ??? ?BeanSearchSpec spec = new BeanSearchSpec(context, metadata,ConditionalOnMissingBean.class);
?? ??? ??? ?//從容器中尋找指定的type --- ?step1
?? ??? ??? ?MatchResult matchResult = getMatchingBeans(context, spec);
?? ??? ??? ?if (matchResult.isAnyMatched()) {
?? ??? ??? ??? ?//如果存在指定的type
?? ??? ??? ??? ?//reason: ?found beans of type 'service.Service' AServiceImpl
?? ??? ??? ??? ?String reason = createOnMissingBeanNoMatchReason(matchResult);
?? ??? ??? ??? ?//創(chuàng)建 ConditionOutcome.noMatch: return new ConditionOutcome(false, message);
?? ??? ??? ??? ?return ConditionOutcome.noMatch(ConditionMessage
?? ??? ??? ??? ??? ??? ?.forCondition(ConditionalOnMissingBean.class, spec)
?? ??? ??? ??? ??? ??? ?.because(reason));
?? ??? ??? ?}
?? ??? ??? ?
?? ??? ??? ?matchMessage = matchMessage.andCondition(ConditionalOnMissingBean.class, spec)
?? ??? ??? ??? ??? ?.didNotFind("any beans").atAll();
?? ??? ?}
?? ??? ?//默認 創(chuàng)建 ConditionOutcome.match : return new ConditionOutcome(true, message);
?? ??? ?return ConditionOutcome.match(matchMessage);
?? ?}
}ConditionOutcome 的用法：當match= true時，才注入容器.
若@ConditionalOnMissingBean找到了匹配項，則返回ConditionOutcome.notMatch，則不注入容器。
問題出在哪?
有了上面的一系列原理支撐,但是為什么沒有執(zhí)行到我們想要的結果呢？
debug執(zhí)行后，發(fā)現(xiàn)問題出現(xiàn)在OnBeanCondition .getMatchingBeans(context, spec)這個方法中。
首先再次回顧下配置類：
在注入carRunServiceImpl時，執(zhí)行OnBeanCondition .getMatchingBeans(context, spec)并沒有找到下面定義的trainRunServiceImpl.
真相只有一個：
@Configuration 在初始化bean的時候，順序出現(xiàn)了問題，那么如何控制初始化bean的順序呢？
解決問題
一頓分析之后，我們發(fā)現(xiàn)只要控制了bean的加載順序之后，上述的問題就可以解決了。
接下來我們來嘗試控制bean初始化順序：
Configuration中bean使用@Order ----------------- failure
@Configuration
public class MyConfiguration {
@Order(2)
@Bean
@ConditionalOnMissingBean
public RunService carRunServiceImpl() {
return new CarRunServiceImpl();
}
@Order(1)
@Bean
public RunService trainRunServiceImpl() {
return new TrainRunServiceImpl();
}
}
Configuration 調(diào)整bean申明順序----------------- success
將帶有@ConditionalOnMissingBean注解的bean,申明在代碼的末尾位置，操作成功：
@Configuration
public class MyConfiguration {
@Bean
public RunService trainRunServiceImpl() {
return new TrainRunServiceImpl();
}
@Bean
@ConditionalOnMissingBean
public RunService carRunServiceImpl() {
return new CarRunServiceImpl();
}
}
配置多個Configuration類，并通過@Order指定順序---------------- failure
@Configuration
@Order(Ordered.LOWEST_PRECEDENCE) //最低優(yōu)先級
public class MyConfiguration {
@Bean
@ConditionalOnMissingBean
public RunService carRunServiceImpl() {
return new CarRunServiceImpl();
}
}
@Configuration
@Order(Ordered.HIGHEST_PRECEDENCE) //最高優(yōu)先級
public class MyConfiguration2 {
@Bean
public RunService trainRunServiceImpl() {
return new TrainRunServiceImpl();
}
}
@Configuration并不能通過@Order指定順序。
大膽猜測下： @Configuration通過配置類名的自然順序來加載的。
@Configuration配置類加載順序通過類名順序來加載 ------- 驗證success
將MyConfiguration2重命名為Configuration2，而它的加載順序在MyConfiguration之前，執(zhí)行程序成功。
這里貌似所有的問題似乎都解決了， 只需要我們自定義的配置類名稱保證最優(yōu)先加載就可以了。我們只需要注意配置類的命名規(guī)則即可.
但是，這種解決方案，似乎并不是那么令人信服。
@AutoConfigureBefore，@AutoConfigureAfter
經(jīng)查文檔，終于找到了需要的東西：我們可以通過@AutoConfigureBefore,@AutoConfigureAfter來控制配置類的加載順序。
@Configuration
public class MyConfiguration {
@Bean
@ConditionalOnMissingBean
public RunService carRunServiceImpl() {
return new CarRunServiceImpl();
}
}
@Configuration
@AutoConfigureBefore(MyConfiguration.class)
public class MyConfiguration2 {
@Bean
public RunService trainRunServiceImpl() {
return new TrainRunServiceImpl();
}
}
注意：
如果要開啟@EnableAutoConfiguration需要在META-INF/spring.factories文件中添加如下內(nèi)容：
org.springframework.boot.autoconfigure.EnableAutoConfiguration=\ xxx.configuration.MyConfiguration2,\ xxx.configuration.MyConfiguration
結論
我們需要控制目標bean的加載順序即可。
但是我們在實際的使用一些通用plugin過程中（如redis），并沒有刻意的指定bean的加載順序，這是為什么呢?
因為：在實際的應用過程中，我們使用第三方插件，他們的默認配置都會存在于插件的jar包中，而我們的個性化配置則存在于自身的應用中。
而容器會優(yōu)先執(zhí)行classes/，然后才執(zhí)行jars/classes.
以上為個人經(jīng)驗，希望能給大家一個參考，也希望大家多多支持腳本之家。
相關文章
Spring Cloud Config 是一個解決分布式系統(tǒng)的配置管理方案，它包含了 server 和 client 兩個部分，這篇文章主要介紹了SpringCloud之配置中心Config（高可用）,需要的朋友可以參考下2022-04-04
這篇文章主要為大家詳細介紹了java學生信息管理系統(tǒng)源代碼，具有一定的參考價值，感興趣的小伙伴們可以參考一下2017-11-11
這篇文章主要介紹了ManyToMany單向、雙向:@JoinTable的使用方式，具有很好的參考價值，希望對大家有所幫助。如有錯誤或未考慮完全的地方，望不吝賜教2021-12-12
MyBatis-Flex BaseMapper的接口基本用法小結
本文主要介紹了MyBatis-Flex BaseMapper的接口基本用法小結,文中通過示例代碼介紹的非常詳細,對大家的學習或者工作具有一定的參考學習價值,需要的朋友們下面隨著小編來一起學習學習吧2025-02-02
這篇文章主要介紹了基于JWT實現(xiàn)SSO單點登錄流程圖解,文中通過示例代碼介紹的非常詳細，對大家的學習或者工作具有一定的參考學習價值,需要的朋友可以參考下2020-07-07
IntelliJ IDEA，就是Java語言開發(fā)工具 （IDE） 功能與Eclipse同類！本文通過圖文并茂的形式給大家介紹IntelliJ IDEA使用入門教程，非常適合新手小白操作，感興趣的朋友一起看看吧2020-10-10
在Spring Boot中,API接口參數(shù)可以通過多種方式獲取,具體取決于你定義的API接口參數(shù)類型（如路徑參數(shù)、查詢參數(shù)、請求體參數(shù)、請求頭等）,本文給大家就介紹了一些常見的參數(shù)獲取方式,需要的朋友可以參考下2024-06-06
這篇文章主要為大家詳細介紹了java實現(xiàn)快速打字游戲，文中示例代碼介紹的非常詳細，具有一定的參考價值，感興趣的小伙伴們可以參考一下2020-07-07
這篇文章主要介紹了Java類加載器層次結構原理解析,文中通過示例代碼介紹的非常詳細，對大家的學習或者工作具有一定的參考學習價值,需要的朋友可以參考下2020-06-06
編寫優(yōu)質(zhì)的并發(fā)代碼是一件難度極高的事情。Java語言從第一版本開始內(nèi)置了對多線程的支持，這一點在當年是非常了不起的，但是當我們對并發(fā)編程有了更深刻的認識和更多的實踐后，實現(xiàn)并發(fā)編程就有了更多的方案和更好的選擇。本文是對并發(fā)編程的核心理論做了下小結2016-05-05