你有沒有遇到過這種場景在Service方法上標(biāo)了一個(gè)Transactional方法里的數(shù)據(jù)庫操作自動(dòng)就有了事務(wù)加了一個(gè)Log注解方法一調(diào)用日志自動(dòng)打印。你什么都沒做方法卻像被“監(jiān)聽”了一樣。很多人管這叫“Spring魔法”其實(shí)哪有什么魔法底層就是代理模式在撐場子。代理模式、動(dòng)態(tài)代理、Spring AOP這三個(gè)詞在面試題里出現(xiàn)頻率極高但真正能把它們串起來講清楚的人不多尤其是Spring AOP底層到底怎么選擇JDK動(dòng)態(tài)代理和CGLIB以及三級(jí)緩存和代理到底有什么關(guān)系網(wǎng)上講得七零八落。這篇我按靜態(tài)代理 - JDK動(dòng)態(tài)代理 - CGLIB動(dòng)態(tài)代理 - Spring AOP源碼 - 容器/三級(jí)緩存 - 手寫最小AOP 的順序完整過一遍。適合想搞懂Spring AOP底層、準(zhǔn)備面試或者被Transactional失效折磨過的人?？赐昴銜?huì)發(fā)現(xiàn)Spring AOP無非就是“提前給你造一個(gè)代理對(duì)象把通知排成攔截器鏈”而已。1. 代理模式到底解決了什么問題1.1 從一個(gè)加日志的需求說起先講一個(gè)最樸素的場景。你維護(hù)著一個(gè)老項(xiàng)目UserService里十幾個(gè)方法每個(gè)方法體里都是業(yè)務(wù)邏輯。某天老板說要給所有增刪改操作加審計(jì)日志你打算怎么辦第一種方案硬改在UserServiceImpl里每個(gè)方法開頭加一行日志結(jié)尾加一行日志。改完以后代碼里到處是日志邏輯業(yè)務(wù)邏輯被淹沒。下次要做事務(wù)、要做權(quán)限又得再改一遍。第二種方案寫一個(gè)包裝類UserServiceLogProxy讓它實(shí)現(xiàn)UserService接口內(nèi)部持有真正的UserServiceImpl在addUser這些方法里調(diào)用真對(duì)象前后輸出日志。這就是靜態(tài)代理不改變目標(biāo)類把橫切邏輯放到代理類里客戶端面向接口編程實(shí)際拿到的是代理對(duì)象。很多新人會(huì)問這跟裝飾器模式有什么區(qū)別差別主要看意圖。裝飾器模式重點(diǎn)在于“增強(qiáng)功能”比如給咖啡加牛奶代理模式重點(diǎn)在于“控制訪問”比如在調(diào)用目標(biāo)之前校驗(yàn)權(quán)限、記錄日志、管理事務(wù)。但落到代碼上兩者結(jié)構(gòu)非常像都是組合一個(gè)目標(biāo)對(duì)象、實(shí)現(xiàn)同一個(gè)接口。在實(shí)際項(xiàng)目里不必過分糾結(jié)名字只要知道這種“用一個(gè)對(duì)象替另一個(gè)對(duì)象擋在前面”的思路就是代理的核心思想。代理對(duì)象對(duì)外暴露的接口和原對(duì)象一致調(diào)用方無感知但是真正干活的還是原對(duì)象代理只是在前后插入了一些橫切邏輯。1.2 靜態(tài)代理示例與優(yōu)缺點(diǎn)靜態(tài)代理的代碼長這樣。定義接口和目標(biāo)類public interface UserService { void addUser(String name); } public class UserServiceImpl implements UserService { Override public void addUser(String name) { System.out.println(保存用戶 name); } }然后手寫一個(gè)代理類public class UserServiceProxy implements UserService { private final UserService target; private final TransactionManager tx; public UserServiceProxy(UserService target, TransactionManager tx) { this.target target; this.tx tx; } Override public void addUser(String name) { tx.begin(); try { target.addUser(name); tx.commit(); } catch (Exception e) { tx.rollback(); throw e; } } }這個(gè)寫法確實(shí)很直白但用起來十分別扭。第一一個(gè)代理類只能服務(wù)一個(gè)接口如果系統(tǒng)里有幾十個(gè)Service接口就得寫幾十個(gè)代理類。第二目標(biāo)類里每個(gè)方法都得手工同步到代理類里接口一旦增加方法代理類和目標(biāo)類要一起改。第三橫切邏輯一多比如日志、事務(wù)、權(quán)限都要加你怎么組合是寫LogProxy、TxProxy、SecurityProxy層層包嗎還是在同一個(gè)Proxy里塞一大堆邏輯無論哪種代碼量都會(huì)爆炸。所以靜態(tài)代理不是沒用而是在某個(gè)局部、接口穩(wěn)定、橫切邏輯固定的時(shí)候最直接。比如接入一個(gè)老SDK不想改SDK里的類只想在調(diào)用前埋點(diǎn)寫一個(gè)實(shí)現(xiàn)同接口的包裝類就夠了。不用引入Spring不用學(xué)AOP概念代碼直白到?jīng)]人看不懂。但一旦規(guī)模上來就必須讓代理類由機(jī)器在運(yùn)行時(shí)生成這就是動(dòng)態(tài)代理的出場前提。2. 動(dòng)態(tài)代理運(yùn)行時(shí)生成代理類2.1 JDK動(dòng)態(tài)代理基于接口的代理JDK在java.lang.reflect包下提供了Proxy和InvocationHandler。代理類不用你手寫而是運(yùn)行時(shí)由JVM生成。你要做的只是告訴它代理對(duì)象要實(shí)現(xiàn)哪些接口方法被調(diào)用時(shí)回調(diào)哪個(gè)處理器。調(diào)用Proxy.newProxyInstance時(shí)JVM會(huì)動(dòng)態(tài)生成一個(gè)$Proxy0類這個(gè)類實(shí)現(xiàn)了你傳入的接口并且繼承了java.lang.reflect.Proxy。因?yàn)镴ava是單繼承所以它沒法再繼承業(yè)務(wù)類這就是JDK動(dòng)態(tài)代理只能基于接口的根源。UserService target new UserServiceImpl(); UserService proxy (UserService) Proxy.newProxyInstance( target.getClass().getClassLoader(), target.getClass().getInterfaces(), (p, method, args) - { System.out.println(before method.getName()); Object result method.invoke(target, args); System.out.println(after method.getName()); return result; }); proxy.addUser(張三);代碼里的第三個(gè)參數(shù)是InvocationHandler所有代理對(duì)象的方法調(diào)用都會(huì)進(jìn)入這里。method.invoke(target, args)這行才是真正調(diào)用目標(biāo)對(duì)象的方法前后想塞什么邏輯都行。這里有個(gè)容易被忽略的點(diǎn)如果方法來自O(shè)bject類比如toString、hashCode、equals需要特殊處理。否則每次調(diào)用toString也會(huì)走一遍代理邏輯某些場景下會(huì)發(fā)生詭異遞歸。我在手寫框架時(shí)會(huì)單獨(dú)判斷Object.class.equals(method.getDeclaringClass())直接放行。JDK動(dòng)態(tài)代理的應(yīng)用非常廣泛。MyBatis的Mapper接口就是經(jīng)典案例你只寫一個(gè)接口不寫實(shí)現(xiàn)類MyBatis在運(yùn)行時(shí)為每個(gè)Mapper接口生成代理對(duì)象方法調(diào)用被MapperProxy攔截翻譯成SQL執(zhí)行。沒有JDK動(dòng)態(tài)代理MyBatis這種“接口即DAO”的玩法根本沒法實(shí)現(xiàn)。2.2 CGLIB動(dòng)態(tài)代理基于繼承的代理CGLIB走的是另一條路把目標(biāo)類當(dāng)作父類用ASM字節(jié)碼技術(shù)在運(yùn)行時(shí)生成一個(gè)子類再重寫父類的方法。所有對(duì)代理對(duì)象方法的調(diào)用都會(huì)進(jìn)入MethodInterceptor回調(diào)。因?yàn)闆]有“必須繼承Proxy基類”的限制所以它不需要接口只要目標(biāo)類和目標(biāo)方法不是final就能代理。Enhancer enhancer new Enhancer(); enhancer.setSuperclass(UserServiceImpl.class); enhancer.setCallback((MethodInterceptor) (obj, method, args, proxy) - { System.out.println(before method.getName()); Object result proxy.invokeSuper(obj, args); System.out.println(after method.getName()); return result; }); UserServiceImpl proxy (UserServiceImpl) enhancer.create(); proxy.addUser(李四);注意一個(gè)特別容易踩的坑在CGLIB回調(diào)里調(diào)用目標(biāo)方法時(shí)要用proxy.invokeSuper(obj, args)不要用method.invoke(obj, args)。因?yàn)閛bj已經(jīng)是代理對(duì)象了method又是父類的方法聲明如果通過反射直接調(diào)用obj方法調(diào)用會(huì)再次進(jìn)入攔截器形成無限遞歸最后棧溢出。invokeSuper走的是FastClass機(jī)制直接定位到父類的原始方法實(shí)現(xiàn)不會(huì)觸發(fā)攔截器。CGLIB能力很強(qiáng)但也有邊界。目標(biāo)類不能是final的否則沒法生成子類final方法不會(huì)被子類重寫所以攔截不到private方法在字節(jié)碼層面是靜態(tài)綁定同樣攔截不到static方法也不行。在很多框架中CGLIB被重打包進(jìn)了org.springframework.cglib包所以Spring項(xiàng)目里你往往不需要額外引入依賴直接用Spring內(nèi)部的Enhancer即可。2.3 兩種動(dòng)態(tài)代理選型對(duì)比對(duì)比維度JDK動(dòng)態(tài)代理CGLIB動(dòng)態(tài)代理代理對(duì)象生成方式運(yùn)行時(shí)生成實(shí)現(xiàn)接口的類運(yùn)行時(shí)生成目標(biāo)類的子類目標(biāo)要求必須有接口目標(biāo)類不能是final目標(biāo)方法不能是final回調(diào)機(jī)制InvocationHandlerMethodInterceptor方法調(diào)用特點(diǎn)通過反射調(diào)用目標(biāo)方法通過FastClass索引調(diào)用父類方法典型應(yīng)用MyBatis Mapper、舊版Spring默認(rèn)配置無接口的Service、Spring Boot默認(rèn)配置限制只能代理接口中聲明的方法無法代理final/static/private方法選型思路其實(shí)很簡單目標(biāo)類實(shí)現(xiàn)接口了優(yōu)先考慮JDK動(dòng)態(tài)代理目標(biāo)類根本沒接口只能考慮CGLIBSpring Boot默認(rèn)幫你選了CGLIB因?yàn)樗屗蠦ean行為一致。但這不代表CGLIB一定更好。JDK創(chuàng)建代理對(duì)象更快因?yàn)樯山涌趯?shí)現(xiàn)類比生成子類簡單CGLIB在方法調(diào)用階段因?yàn)橛蠪astClass索引某些場景下調(diào)用開銷更小。在Spring里兩者最終都會(huì)被包裝成統(tǒng)一的AOP代理框架性能差異遠(yuǎn)沒有網(wǎng)上傳的那么夸張不必過分糾結(jié)。3. Spring AOP的代理選擇與底層實(shí)現(xiàn)3.1 AOP編程模型幾個(gè)必須記住的名字在深入源碼前先把Spring AOP的幾個(gè)核心術(shù)語過一遍。Aspect是切面Pointcut是切點(diǎn)Advice是通知Advisor是把切點(diǎn)和通知綁在一起的對(duì)象。你可以把切點(diǎn)理解成“哪些方法要攔”通知理解成“攔下來之后干什么”Advisor就是一張配置表寫著“這個(gè)切面在哪些方法上做哪些事”。Spring的Around注解對(duì)應(yīng)MethodInterceptor是環(huán)繞通知Before、AfterReturning、AfterThrowing、After最終都會(huì)被適配成對(duì)應(yīng)的MethodInterceptor統(tǒng)一放進(jìn)一個(gè)攔截器鏈。這意味著你寫多個(gè)切面的時(shí)候它們的執(zhí)行順序本質(zhì)上就是攔截器鏈上等待處理的MethodInterceptor列表的順序。理解了這一點(diǎn)再看AOP失效問題、看多次嵌套切面的執(zhí)行順序就不會(huì)發(fā)懵。3.2 源碼說話DefaultAopProxyFactory到底怎么選代理Spring AOP不像上面那樣直接調(diào)Proxy.newProxyInstance或Enhancer.create它封裝了ProxyFactory。你可以用編程方式創(chuàng)建AOP代理ProxyFactory factory new ProxyFactory(); factory.setTarget(new UserServiceImpl()); factory.addInterface(UserService.class); factory.addAdvice((MethodInterceptor) invocation - { System.out.println(環(huán)繞前); Object result invocation.proceed(); System.out.println(環(huán)繞后); return result; }); UserService proxy (UserService) factory.getProxy();getProxy()內(nèi)部會(huì)調(diào)用DefaultAopProxyFactory.createAopProxy(AdvisedSupport config)。我把Spring 5.3的核心邏輯簡化貼在下面public AopProxy createAopProxy(AdvisedSupport config) throws AopConfigException { if (config.isOptimize() || config.isProxyTargetClass() || hasNoUserSuppliedProxyInterfaces(config)) { Class? targetClass config.getTargetClass(); if (targetClass.isInterface() || Proxy.isProxyClass(targetClass) || ClassUtils.isLambdaClass(targetClass)) { return new JdkDynamicAopProxy(config); } return new ObjenesisCglibAopProxy(config); } else { return new JdkDynamicAopProxy(config); } } private boolean hasNoUserSuppliedProxyInterfaces(AdvisedSupport config) { Class?[] ifcs config.getProxiedInterfaces(); return ifcs.length 0 || (ifcs.length 1 SpringProxy.class.isAssignableFrom(ifcs[0])); }這段邏輯非常關(guān)鍵。第一如果配置了optimize或者配置了proxyTargetClasstrue或者用戶沒有額外提供代理接口就進(jìn)入“目標(biāo)類判斷”分支。第二在目標(biāo)類判斷分支里如果目標(biāo)類本身是接口或者已經(jīng)是JDK代理類或者是lambda類就回落到JDK代理否則才用CGLIB。所以網(wǎng)上很多人說“Spring Boot默認(rèn)開啟CGLIB就是所有Bean都走CGLIB”這句話不準(zhǔn)確。如果目標(biāo)類是個(gè)接口即使開了proxyTargetClasstrueSpring還是會(huì)退化成JDK動(dòng)態(tài)代理。這是最容易在面試?yán)锉蛔穯柕募?xì)節(jié)。3.3 拿到代理之后攔截器鏈?zhǔn)窃趺磮?zhí)行的確定了代理類型后getProxy()返回的就是一個(gè)代理對(duì)象。以JdkDynamicAopProxy為例它實(shí)現(xiàn)了InvocationHandler代理對(duì)象的所有方法調(diào)用都會(huì)進(jìn)入它的invoke方法。在invoke里Spring會(huì)把AdvisedSupport中配置的Advisor列表取出來交給AdvisorChainFactory轉(zhuǎn)成ListMethodInterceptor然后創(chuàng)建ReflectiveMethodInvocation從索引0開始逐個(gè)調(diào)用攔截器直到最后一個(gè)攔截器執(zhí)行完才真正通過反射調(diào)用目標(biāo)方法。整個(gè)過程就是一個(gè)責(zé)任鏈模式。每個(gè)攔截器都可以在調(diào)用proceed()之前做前置邏輯在proceed()之后做后置邏輯還可以拋異常、短路、放行。Around通知里那個(gè)ProceedingJoinPoint.proceed()底層就是這條攔截器鏈的觸發(fā)點(diǎn)。你甚至可以在攔截器里改變參數(shù)、改變返回值只要最后把結(jié)果交給下一個(gè)環(huán)節(jié)。3.4 為什么Spring Boot默認(rèn)用CGLIBSpring Framework從4.0開始如果目標(biāo)類沒有接口默認(rèn)使用CGLIBSpring Boot 2.x開始直接把spring.aop.proxy-target-class默認(rèn)值設(shè)成了true也就是說所有Bean默認(rèn)啟用CGLIB代理除非你手動(dòng)改成false。原因很簡單很多實(shí)際項(xiàng)目里的Service Bean不實(shí)現(xiàn)接口JDK代理搞不定統(tǒng)一用CGLIB能讓所有Bean的代理行為可預(yù)期避免“有的代理有的不代理”的混亂。但這個(gè)默認(rèn)值也帶來了一些實(shí)際影響。以前用JDK代理時(shí)你面向接口注入代碼里到處是接口類型改成CGLIB后你不小心把字段聲明成實(shí)現(xiàn)類類型反而能注入成功因?yàn)镃GLIB生成的代理類會(huì)繼承實(shí)現(xiàn)類。這會(huì)讓一些舊代碼在切換配置后出現(xiàn)奇奇怪怪的問題。我在實(shí)際項(xiàng)目里建議除非團(tuán)隊(duì)已經(jīng)有明確的代理方式約定否則不要輕易去改spring.aop.proxy-target-classfalse保持Boot默認(rèn)值把精力放在切面本身的設(shè)計(jì)上。4. 與Spring容器結(jié)合自動(dòng)代理與三級(jí)緩存4.1 誰在容器里創(chuàng)建代理對(duì)象前面講的是手動(dòng)創(chuàng)建代理Spring容器里不會(huì)讓每個(gè)Bean自己調(diào)ProxyFactory。它引入了一個(gè)叫AbstractAutoProxyCreator的BeanPostProcessor。以EnableAspectJAutoProxy為例它會(huì)把AnnotationAwareAspectJAutoProxyCreator注冊(cè)到容器里這個(gè)類繼承自AbstractAutoProxyCreator。任何一個(gè)Bean在生命周期走到初始化完成后postProcessAfterInitialization會(huì)調(diào)用wrapIfNecessary檢查當(dāng)前Bean是否有匹配的Advisor有匹配就創(chuàng)建代理并返回代理對(duì)象替換原Bean。這一步發(fā)生在Bean返回給調(diào)用方之前所以Autowired注入到的、ApplicationContext.getBean拿到的已經(jīng)是代理對(duì)象。原Bean可能被遺忘在某個(gè)角落唯一的作用就是作為代理的target被反射調(diào)用。這就是為什么你用debug打斷點(diǎn)看到controller里注入的service對(duì)象class名帶著$$EnhancerByCGLIB$$或者$Proxy而不是你寫的UserServiceImpl。4.2 三級(jí)緩存與代理的關(guān)系三級(jí)緩存和AOP的關(guān)系是最容易被講亂的部分。三級(jí)緩存指的是DefaultSingletonBeanRegistry里的三個(gè)MapsingletonObjects存完整單例earlySingletonObjects存早期引用singletonFactories存ObjectFactory工廠。Spring創(chuàng)建Bean的流程是實(shí)例化原始對(duì)象 - 屬性填充 - 初始化。在實(shí)例化完成之后Spring會(huì)立刻把一個(gè)ObjectFactory放進(jìn)三級(jí)緩存。為什么要這么早為了處理循環(huán)依賴。假設(shè)A依賴BB依賴A。A實(shí)例化后還沒填屬性B在填充A時(shí)發(fā)現(xiàn)A正在創(chuàng)建中于是去三級(jí)緩存里拿A的ObjectFactory調(diào)用getObject()。這一步如果A配置了切面AbstractAutoProxyCreator的getEarlyBeanReference會(huì)提前生成代理對(duì)象然后把這個(gè)代理對(duì)象放到二級(jí)緩存同時(shí)刪掉三級(jí)緩存里的工廠。B拿到的就是A的代理。如果沒有AOPgetObject()返回的就是原始對(duì)象同樣放進(jìn)二級(jí)緩存。所以三級(jí)緩存里存的不是Bean本身而是一個(gè)“創(chuàng)建早期引用”的工廠函數(shù)。這里有一個(gè)關(guān)鍵點(diǎn)二級(jí)緩存明明能存早期引用了為什么還要三級(jí)緩存因?yàn)锳在實(shí)例化后、屬性填充前Spring并不知道A最終會(huì)不會(huì)被AOP代理。如果一開始就把原始對(duì)象放到二級(jí)緩存等后面再創(chuàng)建代理B手里已經(jīng)攥著原始對(duì)象了增強(qiáng)就徹底失效。三級(jí)緩存存的是工廠每次需要早期引用時(shí)才執(zhí)行一次getEarlyBeanReference動(dòng)態(tài)決定返回原始對(duì)象還是代理對(duì)象。一旦返回過一次結(jié)果會(huì)被放進(jìn)二級(jí)緩存下次請(qǐng)求直接拿緩存保證同一個(gè)Bean只產(chǎn)生一個(gè)早期暴露對(duì)象不會(huì)每次依賴注入都生成新代理。4.3 無循環(huán)依賴時(shí)代理發(fā)生在哪里沒有循環(huán)依賴時(shí)AOP代理發(fā)生在Bean初始化完成后的postProcessAfterInitialization階段也就是PostConstruct、InitializingBean.afterPropertiesSet這些都執(zhí)行完然后才返回代理對(duì)象。有循環(huán)依賴時(shí)代理可能提前到實(shí)例化剛完成就被創(chuàng)建。這個(gè)差異正好解釋了為什么有些循環(huán)依賴場景下構(gòu)造器注入或字段注入拿到的對(duì)象和預(yù)期不一樣。網(wǎng)上常說“三級(jí)緩存解決循環(huán)依賴”嚴(yán)格說應(yīng)該是三級(jí)緩存配合SmartInstantiationAwareBeanPostProcessor讓AOP代理在正確的時(shí)機(jī)生成避免引用方拿到原始對(duì)象之后失去增強(qiáng)能力。如果你自己手寫一個(gè)Spring不考慮AOP只解決循環(huán)依賴其實(shí)兩級(jí)緩存就夠了。正因?yàn)橛蠥OP這種“初始化完成后要替換最終對(duì)象”的機(jī)制存在才需要先放一個(gè)工廠延遲決定要不要提前造代理。我把這段放在這里是想讓你把三級(jí)緩存和AOP當(dāng)成一對(duì)組合來理解而不是死記三個(gè)Map的名字。5. 實(shí)戰(zhàn)手寫一個(gè)最小AOP框架5.1 設(shè)計(jì)攔截器鏈看源碼容易飄自己寫一遍才知道水有多深。我基于JDK動(dòng)態(tài)代理實(shí)現(xiàn)一個(gè)極簡的責(zé)任鏈AOP直接跑起來就能看到效果。先定義一個(gè)攔截器接口public interface MethodInterceptor { Object intercept(MethodInvocation invocation) throws Throwable; }然后定義調(diào)用鏈對(duì)象MethodInvocation它的核心職責(zé)是維護(hù)當(dāng)前攔截器執(zhí)行到第幾個(gè)以及什么時(shí)候真正調(diào)用目標(biāo)方法public class MethodInvocation { private final Object target; private final Method method; private final Object[] args; private final ListMethodInterceptor interceptors; private int current 0; public MethodInvocation(Object target, Method method, Object[] args, ListMethodInterceptor interceptors) { this.target target; this.method method; this.args args; this.interceptors interceptors; } public Object proceed() throws Throwable { if (current interceptors.size()) { return method.invoke(target, args); } return interceptors.get(current).intercept(this); } }proceed()方法就是責(zé)任鏈的入口如果已經(jīng)走到鏈尾就用反射調(diào)用目標(biāo)方法否則取出下一個(gè)攔截器執(zhí)行。每個(gè)攔截器可以在調(diào)用invocation.proceed()前后插入自己的邏輯類似Spring AOP里Around通知的寫法。這個(gè)玩具模型已經(jīng)把ReflectiveMethodInvocation最核心的思路復(fù)刻出來了。5.2 代理工廠封裝有了調(diào)用鏈對(duì)象接下來用JDK動(dòng)態(tài)代理做一個(gè)MiniAop.wrap方法public class MiniAop { public static T T wrap(T target, MethodInterceptor... interceptors) { Class?[] interfaces target.getClass().getInterfaces(); if (interfaces.length 0) { throw new IllegalArgumentException(演示代碼基于JDK動(dòng)態(tài)代理目標(biāo)類需要實(shí)現(xiàn)接口); } return (T) Proxy.newProxyInstance( target.getClass().getClassLoader(), interfaces, (proxy, method, args) - { if (Object.class.equals(method.getDeclaringClass())) { return method.invoke(target, args); } return new MethodInvocation(target, method, args, Arrays.asList(interceptors)).proceed(); }); } }注意我單獨(dú)判斷了Object類的方法這樣toString、hashCode、equals不會(huì)誤入攔截器鏈。如果你去掉這個(gè)判斷很可能會(huì)看到代理對(duì)象被打印時(shí)觸發(fā)了日志切面那感覺非常酸爽。真實(shí)生產(chǎn)框架里也會(huì)做類似處理只是藏得比較深。5.3 寫個(gè)測(cè)試用例驗(yàn)證責(zé)任鏈現(xiàn)在用這個(gè)迷你框架給UserService加兩個(gè)“切面”一個(gè)事務(wù)邏輯一個(gè)日志邏輯。UserService userService MiniAop.wrap(new UserServiceImpl(), invocation - { System.out.println(開啟事務(wù)); try { return invocation.proceed(); } finally { System.out.println(關(guān)閉事務(wù)); } }, invocation - { System.out.println(記錄日志); return invocation.proceed(); }); userService.addUser(王五);執(zhí)行結(jié)果如下開啟事務(wù) 記錄日志 保存用戶王五 關(guān)閉事務(wù)兩個(gè)攔截器的執(zhí)行順序和數(shù)組順序一致先執(zhí)行第一個(gè)第一個(gè)調(diào)用proceed()進(jìn)入第二個(gè)第二個(gè)調(diào)用proceed()真正進(jìn)入目標(biāo)方法然后依次返回。如果你想調(diào)換順序把wrap里的攔截器參數(shù)換一下就行。這個(gè)模型雖然簡陋但已經(jīng)能解釋Spring AOP多切面執(zhí)行順序、以及proceed()為什么能層層穿透。如果你還想支持自定義注解做切點(diǎn)可以在攔截器里判斷method.isAnnotationPresent(Log.class)命中后執(zhí)行日志邏輯思路和AnnotationAwareAspectJAutoProxyCreator一脈相承。6. 常見問題與排查技巧6.1 事務(wù)注解不生效的經(jīng)典現(xiàn)場知道代理怎么工作很多“玄學(xué)Bug”就有了解釋。Transactional失效最典型的場景就是自調(diào)用同一個(gè)類里this方法調(diào)用另一個(gè)標(biāo)注事務(wù)的方法。注意這里的this是Bean原始對(duì)象不是代理對(duì)象所以方法上再有注解也攔不到。解決辦法有幾種最簡單的就是拆B(yǎng)ean把需要事務(wù)的方法放到另一個(gè)Service里注入調(diào)用或者把Bean自己注入進(jìn)來用注入的那個(gè)代理對(duì)象去調(diào)用也可以配置exposeProxytrue后使用AopContext.currentProxy()。更隱蔽的是private方法上加事務(wù)注解CGLIB生成子類時(shí)無法重寫private方法JDK代理的接口方法里也沒有它所以必然失效。同理final方法、final類也無法被代理增強(qiáng)。很多老代碼重構(gòu)時(shí)順手把敏感方法設(shè)置成private或final事務(wù)就悄悄失效了排查起來特別坑。遇到這類問題先確認(rèn)方法修飾符再確認(rèn)是不是自調(diào)用90%的“事務(wù)不生效”都出在這兩個(gè)點(diǎn)上。6.2 如何判斷當(dāng)前Bean到底是不是代理排查AOP問題第一件事是確認(rèn)目標(biāo)對(duì)象到底有沒有被代理。你可以用AopUtils.isAopProxy(bean)直接判斷也可以看class名JDK代理類名通常以$Proxy開頭CGLIB代理類名里含有$$EnhancerByCGLIB$$。如果是在Idea里調(diào)試直接把注入的對(duì)象打印出來看getClass().getName()一目了然。Spring啟動(dòng)日志里也會(huì)暴露線索。開啟org.springframework.aop的DEBUG日志后能看到類似generated proxy target class的提示。Spring Boot項(xiàng)目可以在application.properties里加一行l(wèi)ogging.level.org.springframework.aopDEBUG?？吹酱韯?chuàng)建日志后再配合切面表達(dá)式排查問題范圍就縮小了一半。6.3 CGLIB和JDK代理各自的坑CGLIB不是萬能的。目標(biāo)類沒有無參構(gòu)造、目標(biāo)是final類、方法是final方法都會(huì)翻車。Spring Boot默認(rèn)開CGLIB之后很多老代碼因?yàn)闃?gòu)造器參數(shù)注入的方式也踩過坑。另一個(gè)容易忽略的問題是CGLIB生成的子類會(huì)繼承目標(biāo)類的所有非私有方法toString、equals這些也會(huì)被重寫如果切面表達(dá)式寫得太寬這些“意外方法”也會(huì)被攔截導(dǎo)致日志里出現(xiàn)莫名其妙的輸出。JDK代理的限制則主要反映在類型上一個(gè)Service實(shí)現(xiàn)類實(shí)現(xiàn)了一個(gè)接口Spring如果選JDK代理你注入時(shí)只能聲明接口類型不能聲明實(shí)現(xiàn)類類型。很多人把字段寫成UserServiceImpl結(jié)果一啟動(dòng)就ClassCastException本質(zhì)就是代理對(duì)象不是UserServiceImpl的子類而是Proxy的子類。改成接口注入問題立刻消失。理解原理后這類報(bào)錯(cuò)基本不用查資料就能定位。6.4 真實(shí)框架里的代理遠(yuǎn)不止Spring AOP代理模式不只是Spring AOP的地基。MyBatis的Mapper接口就是用JDK動(dòng)態(tài)代理實(shí)現(xiàn)的每個(gè)MapperProxy把接口方法調(diào)用翻譯成SqlSession操作所以你才能只寫接口不寫實(shí)現(xiàn)類。Spring Security的方法級(jí)安全注解PreAuthorize也是通過AOP代理在方法調(diào)用前做權(quán)限校驗(yàn)底層鏈路和事務(wù)一樣依賴攔截器鏈。Spring AI里的模型客戶端內(nèi)部同樣大量使用代理機(jī)制封裝調(diào)用細(xì)節(jié)讓你面向一個(gè)接口就能發(fā)起模型調(diào)用不需要關(guān)心底層的序列化和網(wǎng)絡(luò)請(qǐng)求。所以我說代理不是一個(gè)孤立的設(shè)計(jì)模式而是整個(gè)Java生態(tài)的地基。你今天搞明白的InvocationHandler和Enhancer明天在看MyBatis源碼、看Spring Security源碼時(shí)還會(huì)反復(fù)遇到。理解它相當(dāng)于拿到了一把能打開好多框架的鑰匙。我個(gè)人在實(shí)際操作中的體會(huì)是別再死背“JDK代理需要接口CGLIB不需要”這種結(jié)論了把今天這段代碼自己敲一遍再跟著DefaultAopProxyFactory源碼走一遍比背十遍面試題都管用。源碼拿到手不要通讀直接找ProxyFactory - AopProxy - MethodInterceptor這條線其他旁路一概不看效率最高。等你親手造出那個(gè)迷你AOP框架再回頭看Spring的代理邏輯你會(huì)覺得它親切得像自己寫的一樣。