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