前言

使用過(guò)spring的同學(xué)們都知道，如果出現(xiàn)了依賴(lài)注入失敗的問(wèn)題首先會(huì)想到以下幾點(diǎn)：

1、對(duì)應(yīng)的類(lèi)有沒(méi)有寫(xiě)@Service或@Component注解以供能被spring掃描注冊(cè)；

2、在配置中有沒(méi)有配置要掃描的包路徑，或是對(duì)應(yīng)的類(lèi)是否在已配置的包路徑下；

3、配置的包路徑錯(cuò)誤導(dǎo)致掃描失??；

4、同一個(gè)項(xiàng)目中jar沖突導(dǎo)致在注冊(cè)bean過(guò)程失敗進(jìn)而導(dǎo)致注入不成功；

問(wèn)題描述

使用springboot的時(shí)候發(fā)現(xiàn)項(xiàng)目正常編譯運(yùn)行，所有的bean都被掃描加載了，但是在前端調(diào)用接口的時(shí)候發(fā)現(xiàn)controller里的service竟然是null。

具體如下圖所示：

由上圖可以看出Device對(duì)應(yīng)的那個(gè)bean在spring容器中已經(jīng)是被注冊(cè)過(guò)了的，就意味著并不是對(duì)應(yīng)的類(lèi)沒(méi)有被加載掃描到。

但我通過(guò)在測(cè)試類(lèi)中運(yùn)行發(fā)現(xiàn)使用同樣的注入方式是可以注入成功并成功運(yùn)行，如下圖所示：

注入測(cè)試

為了進(jìn)一步測(cè)試是否能正常的注入依賴(lài)，將原先的注入方式改成了構(gòu)造注入的方式，發(fā)現(xiàn)也是能夠正常的注入進(jìn)去，如下圖所示：

通過(guò)以上測(cè)試發(fā)現(xiàn)，這次的問(wèn)題并不是因?yàn)閽呙杪窂交蚴亲⒔獾膯?wèn)題導(dǎo)致的，當(dāng)然這里的jar依賴(lài)這些也是正常的。

分析

仔細(xì)回想下這次的問(wèn)題，項(xiàng)目服務(wù)能正常啟動(dòng)，在spring的bean容器中也能找到對(duì)應(yīng)的bean那就說(shuō)明bean注冊(cè)過(guò)程是沒(méi)有問(wèn)題的。

接下來(lái)通過(guò)注入測(cè)試發(fā)現(xiàn)這幾個(gè)service也是能夠正常的注入到controller里，那說(shuō)明項(xiàng)目中DI這個(gè)過(guò)程也是OK的，否則的話不可能是換一種注入方式就能注入。

由此可見(jiàn)，此問(wèn)題并不是因?yàn)閟pring的問(wèn)題導(dǎo)致。接下來(lái)本菜鳥(niǎo)又查詢(xún)了一些資料說(shuō)可能是因?yàn)閯?dòng)態(tài)代理的問(wèn)題導(dǎo)致，項(xiàng)目中沒(méi)有獨(dú)特申明代理方式所以默認(rèn)使用的是JDK的動(dòng)態(tài)代理。

轉(zhuǎn)眼一想感覺(jué)是發(fā)現(xiàn)什么了（此處省略一萬(wàn)個(gè)滑稽…），感覺(jué)離成功又更近一步了。

這里我們先來(lái)看下常用的動(dòng)態(tài)代理：

1、jdk動(dòng)態(tài)代理：

• 使用jdk動(dòng)態(tài)代理只能對(duì)實(shí)現(xiàn)了接口的類(lèi)生成代理，而不能針對(duì)類(lèi)；
• 使用反射生成代理類(lèi)；

2、cglib動(dòng)態(tài)代理：

• 使用cglib代理是針對(duì)類(lèi)實(shí)現(xiàn)代理，主要是對(duì)指定的類(lèi)生成一個(gè)子類(lèi)，覆蓋其中的方法（繼承）；
• 底層采用ASM字節(jié)碼生成框架，使用字節(jié)碼技術(shù)生成代理類(lèi)，比使用Java反射效率要高。

了解到這里后本菜感覺(jué)想到點(diǎn)什么了，本菜的項(xiàng)目中沒(méi)有單獨(dú)設(shè)置代理模式，所以spring對(duì)bean處理的時(shí)候默認(rèn)是使用了jdk動(dòng)態(tài)代理，而項(xiàng)目里的service并非是接口而是一個(gè)class，而且還未實(shí)現(xiàn)某個(gè)接口，只是單純的class

?

本菜就想，是不是因?yàn)榻涌谑菃渭兊念?lèi)沒(méi)有實(shí)現(xiàn)接口，而jdk的動(dòng)態(tài)代理沒(méi)有將這個(gè)類(lèi)代理到，所以導(dǎo)致注入失敗了，于是本菜就設(shè)置了下代理為cglib動(dòng)態(tài)代理：

但經(jīng)本菜鳥(niǎo)測(cè)試發(fā)現(xiàn)，問(wèn)題依舊存在…(內(nèi)心開(kāi)始MMP了)。這時(shí)本菜鳥(niǎo)又想起了另一個(gè)點(diǎn)，spring在對(duì)bean進(jìn)行代理的時(shí)候會(huì)自行選擇代理方式：

(1)當(dāng)Bean實(shí)現(xiàn)接口時(shí)，Spring就會(huì)用JDK的動(dòng)態(tài)代理；

(2)當(dāng)Bean沒(méi)有實(shí)現(xiàn)接口時(shí)，Spring就使用CGlib動(dòng)態(tài)代理；

所以說(shuō)再次申明代理方式也是沒(méi)有用的。

除了以上的一些疑點(diǎn)，本菜又發(fā)現(xiàn)出現(xiàn)問(wèn)題的代碼里使用了spring的AOP，

于是開(kāi)始懷疑是不是AOP搞鬼了，于是找了相關(guān)代碼

從這里可見(jiàn)這里AOP切面切點(diǎn)用在了調(diào)用controller方法前，進(jìn)而再聯(lián)想到項(xiàng)目目前的代理方式是cglib動(dòng)態(tài)代理而非jdk動(dòng)態(tài)代理。于是猜想是不是因?yàn)锳OP切入的時(shí)候代理未生效沒(méi)有將對(duì)應(yīng)的bean給到對(duì)應(yīng)的方法里，后面繼續(xù)深入查詢(xún)看看@Aspect使用的代理方式

鎖定這個(gè)

繼續(xù)深入，看到這里發(fā)現(xiàn)看到有ProxyCreator （代理創(chuàng)建）

判斷生成的bean是否能夠被代理

創(chuàng)建代理類(lèi)bean實(shí)例

代碼較多省略了部分，這里繼續(xù)走到獲取代理

這里我們使用的是cglib動(dòng)態(tài)代理

關(guān)鍵代碼判斷對(duì)應(yīng)bean是否需要被代理并返回實(shí)例

設(shè)置過(guò)濾

中間的代碼比較多，省略了部分，關(guān)鍵代碼

這里可以看到對(duì)映射的方法進(jìn)行了過(guò)濾，依次看過(guò)去發(fā)現(xiàn)這里存在疑慮

看到這里就有疑問(wèn)了，因?yàn)槭褂肁OP的時(shí)候?qū)υL問(wèn)修飾符是沒(méi)有啥影響的，public、private、protect都是可以的，所以最終問(wèn)題應(yīng)該是這里在使用cglib的時(shí)候把私有方法過(guò)濾掉了不被代理，所以導(dǎo)致了在controller中依賴(lài)注入是成功的但調(diào)用這個(gè)接口方法時(shí)拿到的依賴(lài)為null，回看項(xiàng)目源代碼：

解決問(wèn)題

把這里的private改成public就可以了…

反思

論寫(xiě)代碼仔細(xì)的重要性！?。‰m然此次的事故代碼不是出自我手，但是這個(gè)小小的問(wèn)題卻耗費(fèi)了我好久時(shí)間，這里讓我不得不反思下以后寫(xiě)代碼要仔細(xì)仔細(xì)再仔細(xì)，同時(shí)遇到bug的時(shí)候在排查問(wèn)題的時(shí)候也是要仔細(xì)仔細(xì)仔細(xì)！不然很簡(jiǎn)單的問(wèn)題也是會(huì)被忽略掉。

總結(jié)

以上為個(gè)人經(jīng)驗(yàn)，希望能給大家一個(gè)參考，也希望大家多多支持腳本之家。

最新評(píng)論