Spring --@Primary注解

1.问题

当一个接口有2个不同实现时,使用@Autowired注解时会报org.springframework.beans.factory.NoUniqueBeanDefinitionException异常信息

2.方案1-@Qualifier

使用Qualifier注解,选择一个对象的名称,通常比较常用

3.方案2-@Primary

Primary可以理解为默认优先选择,同时不可以同时设置多个,
内部实质是设置BeanDefinition的primary属性

以下是一个例子:

package cn.myframe.test;

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.context.ApplicationContext;
import org.springframework.context.annotation.AnnotationConfigApplicationContext;
import org.springframework.context.annotation.Primary;
import org.springframework.stereotype.Component;

@Primary
@Component("metalSinger") // 加注解,让spring识别
 class MetalSinger implements Singer{

	@Override
	public String sing(String lyrics) {
		return "I am singing with DIO voice: "+lyrics;
	}
}


@Component("operaSinger")
 class OperaSinger implements Singer {
	@Override
	public String sing(String lyrics) {
		return "I am singing in Bocelli voice: "+lyrics;
	}
}

 interface Singer {
	String sing(String lyrics);
}

@Component
public class SingerService {
	@Autowired
//	@Qualifier("metalSinger")
	private Singer singer;
	public String sing(){
		return singer.sing("song lyrics");
	}

	public static void main(String[] args) {

		ApplicationContext context = new AnnotationConfigApplicationContext("cn.myframe.test");
		SingerService singerService = context.getBean(SingerService.class);
		System.out.println(singerService.sing());
	}

}
### 关于 `@Scheduled` 注解失效的原因分析 在使用 `dynamic-datasource-spring-boot-starter` 的情况下,如果发现 `@Scheduled` 定时任务无法正常运行,可能是因为该组件引入了额外的数据源配置逻辑,从而影响了 Spring Boot 默认的任务调度机制。具体原因可以归纳为以下几个方面: #### 1. 数据源切换策略干扰线程池执行 `dynamic-datasource-spring-boot-starter` 提供了一种动态数据源切换的功能,它会在事务上下文中注入特定的数据源信息。然而,默认的 `@Scheduled` 是基于独立的线程池运行的,这些线程不会自动继承主线程中的数据源上下文信息[^3]。 因此,当定时任务尝试访问数据库时,可能会因为缺少有效的数据源绑定而抛出异常或者被阻塞,最终表现为定时任务未被执行。 #### 2. 配置冲突或覆盖 某些情况下,`dynamic-datasource-spring-boot-starter` 可能会修改默认的应用程序上下文初始化顺序,这可能导致 Spring Boot 自带的 `TaskScheduler` 或者其他与定时任务相关的 Bean 被重新定义甚至完全替换掉。这种行为会影响整个应用中所有的计划任务功能。 --- ### 解决方案 针对上述问题,以下是几种可行的解决方案: #### 方法一:手动设置 TaskExecutor 并指定合适的线程属性 可以通过自定义一个 ThreadPoolTaskScheduler 来替代默认的任务调度器,并确保其能够正确处理多线程下的数据源切换需求。下面是一个简单的实现例子: ```java import org.springframework.context.annotation.Bean; import org.springframework.scheduling.concurrent.ThreadPoolTaskScheduler; public class SchedulerConfig { @Bean(name = "taskScheduler") public ThreadPoolTaskScheduler taskScheduler() { ThreadPoolTaskScheduler scheduler = new ThreadPoolTaskScheduler(); scheduler.setPoolSize(5); // 设置线程池大小 scheduler.setThreadNamePrefix("scheduled-task-"); // 设定线程名称前缀以便追踪日志 return scheduler; } } ``` 接着,在启动类上启用此定制化的调度器: ```java @SpringBootApplication @EnableScheduling public class Application { public static void main(String[] args) { SpringApplication.run(Application.class, args); } @Autowired private ThreadPoolTaskScheduler customScheduler; @PostConstruct public void initCustomScheduler(){ ScheduledAnnotationBeanPostProcessor processor = applicationContext.getBean(ScheduledAnnotationBeanPostProcessor.class); if(processor != null){ ReflectionTestUtils.setField(processor,"scheduler",customScheduler); } } } ``` 这种方法的核心在于显式声明了一个新的线程池实例并将其赋值给负责解析 `@Scheduled` 注解的处理器对象,这样就可以绕过潜在的数据源加载错误。 #### 方法二:调整 DynamicDataSourceAutoConfiguration 初始化时机 另一种方法是从源头解决问题——即改变动态数据源插件本身的加载优先级。通常来说,我们可以在项目的主 application.yml 文件里增加如下参数来延迟数据源装配过程直到所有必要的基础设施都已准备就绪为止: ```yaml spring: datasource: dynamic: primary: master # 主库名 strict: false # 是否严格匹配数据源 (推荐关闭) mybatis-plus: configuration: map-underscore-to-camel-case: true ``` 与此同时还需要确认是否存在重复定义相同 key 值的情况,如果有则需清理冗余项以免造成混淆。 最后一步就是验证当前环境下是否仍然存在兼容性障碍;如果是的话,则考虑升级到最新版本试试看是否有官方修复过的相关内容可用。 --- ### 总结 综上所述,`dynamic-datasource-spring-boot-starter` 和 `@Scheduled` 同时使用的场景下确实容易引发一些意想不到的行为表现。通过合理规划资源分配以及优化全局配置结构等方式均可以帮助缓解此类矛盾现象的发生概率。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值