1. 复现错误
今天在执行quartz定时任务时，报出如下错误：
org.springframework.beans.factory.NoSuchBeanDefinitionException: No qualifying bean of type 'com.xxx.CollectionTaskServiceImpl' available
at org.springframework.beans.factory.support.DefaultListableBeanFactory.getBean(DefaultListableBeanFactory.java:351)
at org.springframework.beans.factory.support.DefaultListableBeanFactory.getBean(DefaultListableBeanFactory.java:342)
at org.springframework.context.support.AbstractApplicationContext.getBean(AbstractApplicationContext.java:1127)
at com.xxx.SpringApplicationContext.getBean(SpringApplicationContext.java:19)
at com.xxx.quartz.CollectionTaskJob.execute(CollectionTaskJob.java:27)
at org.quartz.core.JobRunShell.run(JobRunShell.java:202)
... 1 common frames omitted
发现这个错误：No qualifying bean of type 'com.xxx.CollectionTaskServiceImpl' available。
2. 分析错误
我们继续看错误，错误发生在SpringApplicationContext.getBean的方法中。
结合No qualifying bean of type 'com.xxx.CollectionTaskServiceImpl' available错误可知，SpringApplicationContext拿不到CollectionTaskServiceImpl这个类。
如是SpringApplicationContext的源码：
@Component
public class SpringApplicationContext implements ApplicationContextAware {
private static ApplicationContext applicationContext;
@Override
public void setApplicationContext(ApplicationContext applicationContext) throws BeansException {
SpringApplicationContext.applicationContext = applicationContext;
}
public static <T> T getBean(Class<T> requiredType){
return applicationContext.getBean(requiredType);
}
}
SpringApplicationContext实现了 ApplicationContextAware 接口，并由@Component注解。
我们再去往下看，错误在CollectionTaskJob类的execute方法中，如下代码：
@Slf4j
@DisallowConcurrentExecution
public class CollectionTaskJob implements Job {
@Override
public void execute(JobExecutionContext jobExecutionContext) throws JobExecutionException {
CollectionTaskServiceImpl collectionTaskServiceImpl = SpringApplicationContext.getBean(CollectionTaskServiceImpl.class);
//此处省略逻辑代码
}
}
我们再去看CollectionTaskServiceImpl类，如下代码所示：
@Service
public class CollectionTaskServiceImpl implements CollectionTaskService {
//此处省略逻辑代码
}
CollectionTaskServiceImpl实现了CollectionTaskService接口，并由@Service注解。
按道理说，CollectionTaskServiceImpl类注入到spring容器中，通过SpringApplicationContext能够拿得到，但结果是拿不到的。
但为什么拿不到呢？我们需要写个测试类，如下代码所示：
@Component
public class Test implements CommandLineRunner, ApplicationContextAware {
private ApplicationContext applicationContext;
@Override
public void run(String... args) throws Exception {
Map<String, CollectionTaskServiceImpl> beansOfType =
applicationContext.getBeansOfType(CollectionTaskServiceImpl.class);
System.out.println();
}
@Override
public void setApplicationContext(ApplicationContext applicationContext) throws BeansException {
this.applicationContext = applicationContext;
}
}
测试类Test实现了CommandLineRunner和ApplicationContextAware接口，此时，我们运行代码：
你会清楚的看到，beansOfType的容器为0，确实没有拿到。
我们将CollectionTaskServiceImpl修改为CollectionTaskService：
@Override
public void run(String... args) throws Exception {
Map<String, CollectionTaskService> beansOfType =
applicationContext.getBeansOfType(CollectionTaskService.class);
System.out.println();
}
重新运行：
此时，拿到了CollectionTaskServiceImpl的对象，但注意红框处，它采用的是jdk aop 的动态代理。
然后，我修改CollectionTaskServiceImpl类，不实现CollectionTaskService接口，如下代码所示：
@Service
public class CollectionTaskServiceImpl {
//此处省略逻辑代码
}
而run方法依然是CollectionTaskServiceImpl，如下代码所示：
@Override
public void run(String... args) throws Exception {
Map<String, CollectionTaskServiceImpl> beansOfType =
applicationContext.getBeansOfType(CollectionTaskServiceImpl.class);
System.out.println();
}
重新运行代码：
如此，也能拿到了CollectionTaskServiceImpl的对象，但注意红框处，它采用的是spring cglib的动态代理。
分析到这里大体就明白了，可以有如下两种解决方法。
3. 解决问题
3.1 解决方法一
修改CollectionTaskJob类的execute方法，在SpringApplicationContext.getBean方法中传入CollectionTaskService.class接口，如下代码所示：
@Slf4j
@DisallowConcurrentExecution
public class CollectionTaskJob implements Job {
@Override
public void execute(JobExecutionContext jobExecutionContext) throws JobExecutionException {
CollectionTaskServiceImpl collectionTaskServiceImpl = (CollectionTaskServiceImpl) SpringApplicationContext.getBean(CollectionTaskService.class);
//此处省略逻辑代码
}
}
3.2 解决方法二
修改CollectionTaskServiceImpl类，不实现CollectionTaskService即可。
4. 分析spring中的jdk和cglib的动态代理
4.1 动态代理对比
JDK动态代理是实现了被代理对象所实现的接口，CGLib是继承了被代理对象。
JDK和CGLib都是在运行期生成字节码，JDK是直接写Class字节码。CGLib使用ASM框架Class字节码，Cglib代理实现更复杂，生成代理类的效率比JDK代理低。
JDK调用代理方法，是通过反射机制调用，CGLib是通过FastClass机制直接调用方法，CGLib执行效率更高。
4.2 原理区别
java动态代理是利用反射机制生成一个实现代理接口的匿名类，在调用具体方法前调用InvokeHandler来处理。核心是实现InvocationHandler接口，使用invoke()方法进行面向切面的处理，调用相应的通知。
而cglib动态代理是利用asm开源包，对代理对象类的class文件加载进来，通过修改其字节码生成子类来处理。
核心是实现MethodInterceptor接口，使用intercept()方法进行面向切面的处理，调用相应的通知。
- 如果目标对象实现了接口，默认情况下会采用
JDK的动态代理实现AOP - 如果目标对象实现了接口，可以强制使用
CGLIB实现AOP - 如果目标对象没有实现了接口，必须采用
CGLIB库，spring会自动在JDK动态代理和CGLIB之间转换
4.3 性能区别
-
CGLib底层采用ASM字节码生成框架，使用字节码技术生成代理类，在jdk6之前比使用Java反射效率要高。唯一需要注意的是，CGLib不能对声明为final的方法进行代理，因为CGLib原理是动态生成被代理类的子类。 -
在
jdk6、jdk7、jdk8逐步对JDK动态代理优化之后，在调用次数较少的情况下，JDK代理效率高于CGLIB代理效率，只有当进行大量调用的时候，jdk6和jdk7比CGLIB代理效率低一点，但是到jdk8的时候，jdk代理效率高于CGLIB代理。
4.4 各自局限
-
JDK的动态代理机制只能代理实现了接口的类，而不能实现接口的类就不能实现JDK的动态代理。 -
cglib是针对类来实现代理的，他的原理是对指定的目标类生成一个子类，并覆盖其中方法实现增强，但因为采用的是继承，所以不能对final修饰的类进行代理。
| 类型 | 机制 | 回调方式 | 适用场景 | 效率 |
| JDK动态代理 | 委托机制，代理类和目标类都实现了同样的接口，InvocationHandler持有目标类，代理类委托InvocationHandler去调用目标类的原始方法 | 反射 | 目标类是接口类 | 效率瓶颈在反射调用稍慢 |
| CGLIB动态代理 | 继承机制，代理类继承了目标类并重写了目标方法，通过回调函数MethodInterceptor调用父类方法执行原始逻辑 | 通过FastClass方法索引调用 | 非接口类、非final类，非final方法 | 第一次调用因为要生成多个Class对象，比JDK方式慢。多次调用因为有方法索引比反射快，如果方法过多，switch case过多其效率还需测试 |
4.5 静态代理和动态的本质区别
-
静态代理只能通过手动完成代理操作，如果被代理类增加新的方法，代理类需要同步新增，违背开闭原则。
-
动态代理采用在运行时动态生成代码的方式，取消了对被代理类的扩展限制，遵循开闭原则。文章来源：https://www.toymoban.com/news/detail-765908.html
-
若动态代理要对目标类的增强逻辑扩展，结合策略模式，只需要新增策略类便可完成，无需修改代理类的代码。文章来源地址https://www.toymoban.com/news/detail-765908.html
到了这里，关于springframework.beans.factory.NoSuchBeanDefinitionException:No qualifying bean of type ‘x‘ available的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
