1. 復(fù)現(xiàn)錯(cuò)誤

今天在執(zhí)行quartz定時(shí)任務(wù)時(shí)，報(bào)出如下錯(cuò)誤：

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

發(fā)現(xiàn)這個(gè)錯(cuò)誤：No qualifying bean of type 'com.xxx.CollectionTaskServiceImpl' available。

2. 分析錯(cuò)誤

我們繼續(xù)看錯(cuò)誤，錯(cuò)誤發(fā)生在SpringApplicationContext.getBean的方法中。

結(jié)合No qualifying bean of type 'com.xxx.CollectionTaskServiceImpl' available錯(cuò)誤可知，SpringApplicationContext拿不到CollectionTaskServiceImpl這個(gè)類。

如是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實(shí)現(xiàn)了 ApplicationContextAware 接口，并由@Component注解。

我們?cè)偃ネ驴矗e(cuò)誤在CollectionTaskJob類的execute方法中，如下代碼：

@Slf4j
@DisallowConcurrentExecution
public class CollectionTaskJob implements Job {

    @Override
    public void execute(JobExecutionContext jobExecutionContext) throws JobExecutionException {
        CollectionTaskServiceImpl collectionTaskServiceImpl = SpringApplicationContext.getBean(CollectionTaskServiceImpl.class);
        //此處省略邏輯代碼
   }
}

我們?cè)偃タ?code>CollectionTaskServiceImpl類，如下代碼所示：

@Service
public class CollectionTaskServiceImpl implements CollectionTaskService {
	//此處省略邏輯代碼
}

CollectionTaskServiceImpl實(shí)現(xiàn)了CollectionTaskService接口，并由@Service注解。

按道理說，CollectionTaskServiceImpl類注入到spring容器中，通過SpringApplicationContext能夠拿得到，但結(jié)果是拿不到的。

但為什么拿不到呢？我們需要寫個(gè)測(cè)試類，如下代碼所示：

@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;
  }
}

測(cè)試類Test實(shí)現(xiàn)了CommandLineRunner和ApplicationContextAware接口，此時(shí)，我們運(yùn)行代碼：

你會(huì)清楚的看到，beansOfType的容器為0，確實(shí)沒有拿到。

我們將CollectionTaskServiceImpl修改為CollectionTaskService：

 @Override
  public void run(String... args) throws Exception {
    Map<String, CollectionTaskService> beansOfType =
        applicationContext.getBeansOfType(CollectionTaskService.class);
    System.out.println();
  }

重新運(yùn)行：

此時(shí)，拿到了CollectionTaskServiceImpl的對(duì)象，但注意紅框處，它采用的是jdk aop 的動(dòng)態(tài)代理。

然后，我修改CollectionTaskServiceImpl類，不實(shí)現(xiàn)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();
  }

重新運(yùn)行代碼：

如此，也能拿到了CollectionTaskServiceImpl的對(duì)象，但注意紅框處，它采用的是spring cglib的動(dòng)態(tài)代理。

分析到這里大體就明白了，可以有如下兩種解決方法。

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類，不實(shí)現(xiàn)CollectionTaskService即可。

4. 分析spring中的jdk和cglib的動(dòng)態(tài)代理

4.1 動(dòng)態(tài)代理對(duì)比

JDK動(dòng)態(tài)代理是實(shí)現(xiàn)了被代理對(duì)象所實(shí)現(xiàn)的接口，CGLib是繼承了被代理對(duì)象。

JDK和CGLib都是在運(yùn)行期生成字節(jié)碼，JDK是直接寫Class字節(jié)碼。CGLib使用ASM框架Class字節(jié)碼，Cglib代理實(shí)現(xiàn)更復(fù)雜，生成代理類的效率比JDK代理低。

JDK調(diào)用代理方法，是通過反射機(jī)制調(diào)用，CGLib是通過FastClass機(jī)制直接調(diào)用方法，CGLib執(zhí)行效率更高。

4.2 原理區(qū)別

java動(dòng)態(tài)代理是利用反射機(jī)制生成一個(gè)實(shí)現(xiàn)代理接口的匿名類，在調(diào)用具體方法前調(diào)用InvokeHandler來處理。核心是實(shí)現(xiàn)InvocationHandler接口，使用invoke()方法進(jìn)行面向切面的處理，調(diào)用相應(yīng)的通知。

而cglib動(dòng)態(tài)代理是利用asm開源包，對(duì)代理對(duì)象類的class文件加載進(jìn)來，通過修改其字節(jié)碼生成子類來處理。

核心是實(shí)現(xiàn)MethodInterceptor接口，使用intercept()方法進(jìn)行面向切面的處理，調(diào)用相應(yīng)的通知。

1. 如果目標(biāo)對(duì)象實(shí)現(xiàn)了接口，默認(rèn)情況下會(huì)采用JDK的動(dòng)態(tài)代理實(shí)現(xiàn)AOP
2. 如果目標(biāo)對(duì)象實(shí)現(xiàn)了接口，可以強(qiáng)制使用CGLIB實(shí)現(xiàn)AOP
3. 如果目標(biāo)對(duì)象沒有實(shí)現(xiàn)了接口，必須采用CGLIB庫(kù)，spring會(huì)自動(dòng)在JDK動(dòng)態(tài)代理和CGLIB之間轉(zhuǎn)換

4.3 性能區(qū)別

1. CGLib底層采用ASM字節(jié)碼生成框架，使用字節(jié)碼技術(shù)生成代理類，在jdk6之前比使用Java反射效率要高。唯一需要注意的是，CGLib不能對(duì)聲明為final的方法進(jìn)行代理，因?yàn)?code>CGLib原理是動(dòng)態(tài)生成被代理類的子類。

2. 在jdk6、jdk7、jdk8逐步對(duì)JDK動(dòng)態(tài)代理優(yōu)化之后，在調(diào)用次數(shù)較少的情況下，JDK代理效率高于CGLIB代理效率，只有當(dāng)進(jìn)行大量調(diào)用的時(shí)候，jdk6和jdk7比CGLIB代理效率低一點(diǎn)，但是到jdk8的時(shí)候，jdk代理效率高于CGLIB代理。

4.4 各自局限

1. JDK的動(dòng)態(tài)代理機(jī)制只能代理實(shí)現(xiàn)了接口的類，而不能實(shí)現(xiàn)接口的類就不能實(shí)現(xiàn)JDK的動(dòng)態(tài)代理。

2. cglib是針對(duì)類來實(shí)現(xiàn)代理的，他的原理是對(duì)指定的目標(biāo)類生成一個(gè)子類，并覆蓋其中方法實(shí)現(xiàn)增強(qiáng)，但因?yàn)椴捎玫氖抢^承，所以不能對(duì)final修飾的類進(jìn)行代理。

4.5 靜態(tài)代理和動(dòng)態(tài)的本質(zhì)區(qū)別

1. 靜態(tài)代理只能通過手動(dòng)完成代理操作，如果被代理類增加新的方法，代理類需要同步新增，違背開閉原則。

2. 動(dòng)態(tài)代理采用在運(yùn)行時(shí)動(dòng)態(tài)生成代碼的方式，取消了對(duì)被代理類的擴(kuò)展限制，遵循開閉原則。

3. 若動(dòng)態(tài)代理要對(duì)目標(biāo)類的增強(qiáng)邏輯擴(kuò)展，結(jié)合策略模式，只需要新增策略類便可完成，無需修改代理類的代碼。文章來源地址http://www.zghlxwxcb.cn/news/detail-765908.html

到了這里，關(guān)于springframework.beans.factory.NoSuchBeanDefinitionException:No qualifying bean of type ‘x‘ available的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！