以前寫過 IOC 的源碼分析，那篇文章真的有點長，看完須要點耐心。不少讀者但願能寫一寫 Spring AOP 的源碼分析文章，這樣讀者看完 IOC + AOP 也就對 Spring 會有比較深的理解了。今天終於成文了，可能不少讀者早就再也不等待了，不過主要爲了後來者吧。html
本文不會像 IOC 源碼分析那篇文章同樣，很具體地分析每一行 Spring AOP 的源碼，目標讀者是已經知道 Spring IOC 源碼是怎麼回事的讀者，由於 Spring AOP 終歸是依賴於 IOC 容器來管理的。java
Spring AOP 的源碼並不簡單，由於它多，因此閱讀源碼最好就是找到一個分支，追蹤下去。本文定位爲蜻蜓點水，看個大概，不具體到每個細節。spring
前言
這一節，咱們先來"猜猜" Spring 是怎麼實現 AOP 的。數組
在 Spring 的容器中，咱們面向的對象是一個個的 bean 實例，bean 是什麼？咱們能夠簡單理解爲是 BeanDefinition 的實例，Spring 會根據 BeanDefinition 中的信息爲咱們生產合適的 bean 實例出來。bash
當咱們須要使用 bean 的時候，經過 IOC 容器的 getBean(…) 方法從容器中獲取 bean 實例，只不過大部分的場景下，咱們都用了依賴注入，因此不多手動調用 getBean(...) 方法。app
Spring AOP 的原理很簡單，就是動態代理，它和 AspectJ 不同，AspectJ 是直接修改掉你的字節碼。maven
代理模式很簡單，接口 + 真實實現類 + 代理類，其中 真實實現類 和 代理類 都要實現接口，實例化的時候要使用代理類。因此，Spring AOP 須要作的是生成這麼一個代理類，而後替換掉真實實現類來對外提供服務。ide
替換的過程怎麼理解呢？在 Spring IOC 容器中很是容易實現，就是在 getBean(…) 的時候返回的其實是代理類的實例，而這個代理類咱們本身沒寫代碼，它是 Spring 採用 JDK Proxy 或 CGLIB 動態生成的。oop
getBean(…) 方法用於查找或實例化容器中的 bean，這也是爲何 Spring AOP 只能做用於 Spring 容器中的 bean 的緣由，對於不是使用 IOC 容器管理的對象，Spring AOP 是無能爲力的。源碼分析
本文使用的調試代碼
閱讀源碼很好用的一個方法就是跑代碼來調試，由於本身一行一行地看的話，比較枯燥，並且不免會漏掉一些東西。
下面，咱們先準備一些簡單的調試用的代碼。
首先先定義兩個 Service 接口：
// OrderService.java
public interface OrderService {
Order createOrder(String username, String product);
Order queryOrder(String username);
}
// UserService.java
public interface UserService {
User createUser(String firstName, String lastName, int age);
User queryUser();
}
複製代碼
而後，分別來一個接口實現類：
// OrderServiceImpl.java
public class OrderServiceImpl implements OrderService {
@Override
public Order createOrder(String username, String product) {
Order order = new Order();
order.setUsername(username);
order.setProduct(product);
return order;
}
@Override
public Order queryOrder(String username) {
Order order = new Order();
order.setUsername("test");
order.setProduct("test");
return order;
}
}
// UserServiceImpl.java
public class UserServiceImpl implements UserService {
@Override
public User createUser(String firstName, String lastName, int age) {
User user = new User();
user.setFirstName(firstName);
user.setLastName(lastName);
user.setAge(age);
return user;
}
@Override
public User queryUser() {
User user = new User();
user.setFirstName("test");
user.setLastName("test");
user.setAge(20);
return user;
}
}
複製代碼
寫兩個 Advice：
public class LogArgsAdvice implements MethodBeforeAdvice {
@Override
public void before(Method method, Object[] args, Object target) throws Throwable {
System.out.println("準備執行方法: " + method.getName() + ", 參數列表：" + Arrays.toString(args));
}
}
複製代碼
public class LogResultAdvice implements AfterReturningAdvice {
@Override
public void afterReturning(Object returnValue, Method method, Object[] args, Object target)
throws Throwable {
System.out.println(method.getName() + "方法返回：" + returnValue);
}
}
複製代碼
配置一下：
咱們這邊使用了前面文章介紹的配置 Advisor 的方式，咱們回顧一下。
每一個 advisor 內部持有 advice 實例，advisor 負責匹配，內部的 advice 負責實現攔截處理。配置了各個 advisor 後，配置 DefaultAdvisorAutoProxyCreator 使得全部的 advisor 配置自動生效。
啓動：
public class SpringAopSourceApplication {
public static void main(String[] args) {
// 啓動 Spring 的 IOC 容器
ApplicationContext context = new ClassPathXmlApplicationContext("classpath:DefaultAdvisorAutoProxy.xml");
UserService userService = context.getBean(UserService.class);
OrderService orderService = context.getBean(OrderService.class);
userService.createUser("Tom", "Cruise", 55);
userService.queryUser();
orderService.createOrder("Leo", "隨便買點什麼");
orderService.queryOrder("Leo");
}
}
複製代碼
輸出：
準備執行方法: createUser, 參數列表：[Tom, Cruise, 55]
queryUser方法返回：User{firstName='test', lastName='test', age=20, address='null'}
準備執行方法: createOrder, 參數列表：[Leo, 隨便買點什麼]
queryOrder方法返回：Order{username='test', product='test'}
複製代碼
從輸出結果，咱們能夠看到：
LogArgsAdvice 做用於 UserService#createUser(…) 和 OrderService#createOrder(…) 兩個方法；
LogResultAdvice 做用於 UserService#queryUser() 和 OrderService#queryOrder(…) 兩個方法；
下面的代碼分析中，咱們將基於這個簡單的例子來介紹。
IOC 容器管理 AOP 實例
本節介紹 Spring AOP 是怎麼做用於 IOC 容器中的 bean 的。
Spring AOP 的使用介紹 那篇文章已經介紹過 DefaultAdvisorAutoProxyCreator 類了，它能實現自動將全部的 advisor 生效。
咱們來追蹤下 DefaultAdvisorAutoProxyCreator 類，看看它是怎麼一步步實現的動態代理。而後在這個基礎上，咱們再簡單追蹤下 @AspectJ 配置方式下的源碼實現。
首先，先看下 DefaultAdvisorAutoProxyCreator 的繼承結構：
咱們能夠發現，DefaultAdvisorAutoProxyCreator 最後竟然是一個 BeanPostProcessor，在 Spring IOC 源碼分析的時候說過，BeanPostProcessor 的兩個方法，分別在 init-method 的先後獲得執行。
public interface BeanPostProcessor {
Object postProcessBeforeInitialization(Object bean, String beanName) throws BeansException;
Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException;
}
複製代碼
這裏再貼一下 IOC 的源碼，咱們回顧一下：
// AbstractAutowireCapableBeanFactory
protected Object doCreateBean(final String beanName, final RootBeanDefinition mbd, final Object[] args)
throws BeanCreationException {
// Instantiate the bean.
BeanWrapper instanceWrapper = null;
if (mbd.isSingleton()) {
instanceWrapper = this.factoryBeanInstanceCache.remove(beanName);
}
if (instanceWrapper == null) {
// 1. 建立實例
instanceWrapper = createBeanInstance(beanName, mbd, args);
}
...
// Initialize the bean instance.
Object exposedObject = bean;
try {
// 2. 裝載屬性
populateBean(beanName, mbd, instanceWrapper);
if (exposedObject != null) {
// 3. 初始化
exposedObject = initializeBean(beanName, exposedObject, mbd);
}
}
...
}
複製代碼
在上面第 3 步 initializeBean(...) 方法中會調用 BeanPostProcessor 中的方法，以下：
protected Object initializeBean(final String beanName, final Object bean, RootBeanDefinition mbd) {
...
Object wrappedBean = bean;
if (mbd == null || !mbd.isSynthetic()) {
// 1. 執行每個 BeanPostProcessor 的 postProcessBeforeInitialization 方法
wrappedBean = applyBeanPostProcessorsBeforeInitialization(wrappedBean, beanName);
}
try {
// 調用 bean 配置中的 init-method="xxx"
invokeInitMethods(beanName, wrappedBean, mbd);
}
...
if (mbd == null || !mbd.isSynthetic()) {
// 咱們關注的重點是這裏！！！
// 2. 執行每個 BeanPostProcessor 的 postProcessAfterInitialization 方法
wrappedBean = applyBeanPostProcessorsAfterInitialization(wrappedBean, beanName);
}
return wrappedBean;
}
複製代碼
也就是說，Spring AOP 會在 IOC 容器建立 bean 實例的最後對 bean 進行處理。其實就是在這一步進行代理加強。
咱們回過頭來，DefaultAdvisorAutoProxyCreator 的繼承結構中，postProcessAfterInitialization() 方法在其父類 AbstractAutoProxyCreator 這一層被覆寫了：
// AbstractAutoProxyCreator
@Override
public Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException {
if (bean != null) {
Object cacheKey = getCacheKey(bean.getClass(), beanName);
if (!this.earlyProxyReferences.contains(cacheKey)) {
return wrapIfNecessary(bean, beanName, cacheKey);
}
}
return bean;
}
複製代碼
繼續往裏看 wrapIfNecessary(...) 方法，這個方法將返回代理類（若是須要的話）：
protected Object wrapIfNecessary(Object bean, String beanName, Object cacheKey) {
if (beanName != null && this.targetSourcedBeans.contains(beanName)) {
return bean;
}
if (Boolean.FALSE.equals(this.advisedBeans.get(cacheKey))) {
return bean;
}
if (isInfrastructureClass(bean.getClass()) || shouldSkip(bean.getClass(), beanName)) {
this.advisedBeans.put(cacheKey, Boolean.FALSE);
return bean;
}
// 返回匹配當前 bean 的全部的 advisor、advice、interceptor
// 對於本文的例子，"userServiceImpl" 和 "OrderServiceImpl" 這兩個 bean 建立過程當中，
// 到這邊的時候都會返回兩個 advisor
Object[] specificInterceptors = getAdvicesAndAdvisorsForBean(bean.getClass(), beanName, null);
if (specificInterceptors != DO_NOT_PROXY) {
this.advisedBeans.put(cacheKey, Boolean.TRUE);
// 建立代理...建立代理...建立代理...
Object proxy = createProxy(
bean.getClass(), beanName, specificInterceptors, new SingletonTargetSource(bean));
this.proxyTypes.put(cacheKey, proxy.getClass());
return proxy;
}
this.advisedBeans.put(cacheKey, Boolean.FALSE);
return bean;
}
複製代碼
這裏有兩個點提一下：
getAdvicesAndAdvisorsForBean(bean.getClass(), beanName, null)，這個方法將獲得全部的可用於攔截當前 bean 的advisor、advice、interceptor。
另外一個就是 TargetSource 這個概念，它用於封裝真實實現類的信息，上面用了 SingletonTargetSource 這個實現類，其實咱們這裏也不太須要關心這個，知道有這麼回事就能夠了。
咱們繼續往下看 createProxy(…) 方法：
// 注意看這個方法的幾個參數，
// 第三個參數攜帶了全部的 advisors
// 第四個參數 targetSource 攜帶了真實實現的信息
protected Object createProxy(
Class<?> beanClass, String beanName, Object[] specificInterceptors, TargetSource targetSource) {
if (this.beanFactory instanceof ConfigurableListableBeanFactory) {
AutoProxyUtils.exposeTargetClass((ConfigurableListableBeanFactory) this.beanFactory, beanName, beanClass);
}
// 建立 ProxyFactory 實例
ProxyFactory proxyFactory = new ProxyFactory();
proxyFactory.copyFrom(this);
// 在 schema-based 的配置方式中，咱們介紹過，若是但願使用 CGLIB 來代理接口，能夠配置
// proxy-target-class="true",這樣無論有沒有接口，都使用 CGLIB 來生成代理：
// <aop:config proxy-target-class="true">......</aop:config>
if (!proxyFactory.isProxyTargetClass()) {
if (shouldProxyTargetClass(beanClass, beanName)) {
proxyFactory.setProxyTargetClass(true);
}
else {
// 點進去稍微看一下代碼就知道了，主要就兩句：
// 1. 有接口的，調用一次或屢次：proxyFactory.addInterface(ifc);
// 2. 沒有接口的，調用：proxyFactory.setProxyTargetClass(true);
evaluateProxyInterfaces(beanClass, proxyFactory);
}
}
// 這個方法會返回匹配了當前 bean 的 advisors 數組
// 對於本文的例子，"userServiceImpl" 和 "OrderServiceImpl" 到這邊的時候都會返回兩個 advisor
// 注意：若是 specificInterceptors 中有 advice 和 interceptor，它們也會被包裝成 advisor，進去看下源碼就清楚了
Advisor[] advisors = buildAdvisors(beanName, specificInterceptors);
for (Advisor advisor : advisors) {
proxyFactory.addAdvisor(advisor);
}
proxyFactory.setTargetSource(targetSource);
customizeProxyFactory(proxyFactory);
proxyFactory.setFrozen(this.freezeProxy);
if (advisorsPreFiltered()) {
proxyFactory.setPreFiltered(true);
}
return proxyFactory.getProxy(getProxyClassLoader());
}
複製代碼
咱們看到，這個方法主要是在內部建立了一個 ProxyFactory 的實例，而後 set 了一大堆內容，剩下的工做就都是這個 ProxyFactory 實例的了，經過這個實例來建立代理: getProxy(classLoader)。
ProxyFactory 詳解
根據上面的源碼，咱們走到了 ProxyFactory 這個類了，咱們到這個類來一看究竟。
順着上面的路子，咱們首先到 ProxyFactory#getProxy(classLoader) 方法：
public Object getProxy(ClassLoader classLoader) {
return createAopProxy().getProxy(classLoader);
}
複製代碼
該方法首先經過 createAopProxy() 建立一個 AopProxy 的實例：
protected final synchronized AopProxy createAopProxy() {
if (!this.active) {
activate();
}
return getAopProxyFactory().createAopProxy(this);
}
複製代碼
建立 AopProxy 以前，咱們須要一個 AopProxyFactory 實例，而後看 ProxyCreatorSupport 的構造方法：
public ProxyCreatorSupport() {
this.aopProxyFactory = new DefaultAopProxyFactory();
}
複製代碼
這樣就將咱們導到 DefaultAopProxyFactory 這個類了，咱們看它的 createAopProxy(…) 方法：
public class DefaultAopProxyFactory implements AopProxyFactory, Serializable {
@Override
public AopProxy createAopProxy(AdvisedSupport config) throws AopConfigException {
// (我也沒用過這個optimize，默認false) || (proxy-target-class=true) || (沒有接口)
if (config.isOptimize() || config.isProxyTargetClass() || hasNoUserSuppliedProxyInterfaces(config)) {
Class<?> targetClass = config.getTargetClass();
if (targetClass == null) {
throw new AopConfigException("TargetSource cannot determine target class: " +
"Either an interface or a target is required for proxy creation.");
}
// 若是要代理的類自己就是接口，也會用 JDK 動態代理
// 我也沒用過這個。。。
if (targetClass.isInterface() || Proxy.isProxyClass(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])));
}
}
複製代碼
到這裏，咱們知道 createAopProxy 方法有可能返回 JdkDynamicAopProxy 實例，也有可能返回 ObjenesisCglibAopProxy 實例，這裏總結一下：
若是被代理的目標類實現了一個或多個自定義的接口，那麼就會使用 JDK 動態代理，若是沒有實現任何接口，會使用 CGLIB 實現代理，若是設置了 proxy-target-class="true"，那麼都會使用 CGLIB。
JDK 動態代理基於接口，因此只有接口中的方法會被加強，而 CGLIB 基於類繼承，須要注意就是若是方法使用了 final 修飾，或者是 private 方法，是不能被加強的。
有了 AopProxy 實例之後，咱們就回到這個方法了：
public Object getProxy(ClassLoader classLoader) {
return createAopProxy().getProxy(classLoader);
}
複製代碼
咱們分別來看下兩個 AopProxy 實現類的 getProxy(classLoader) 實現。
JdkDynamicAopProxy 類的源碼比較簡單，總共兩百多行，
@Override
public Object getProxy(ClassLoader classLoader) {
if (logger.isDebugEnabled()) {
logger.debug("Creating JDK dynamic proxy: target source is " + this.advised.getTargetSource());
}
Class<?>[] proxiedInterfaces = AopProxyUtils.completeProxiedInterfaces(this.advised, true);
findDefinedEqualsAndHashCodeMethods(proxiedInterfaces);
return Proxy.newProxyInstance(classLoader, proxiedInterfaces, this);
}
複製代碼
java.lang.reflect.Proxy.newProxyInstance(…) 方法須要三個參數，第一個是 ClassLoader，第二個參數表明須要實現哪些接口，第三個參數最重要，是 InvocationHandler 實例，咱們看到這裏傳了 this，由於 JdkDynamicAopProxy 自己實現了 InvocationHandler 接口。
InvocationHandler 只有一個方法，當生成的代理類對外提供服務的時候，都會導到這個方法中：
public interface InvocationHandler {
public Object invoke(Object proxy, Method method, Object[] args)
throws Throwable;
}
複製代碼
下面來看看 JdkDynamicAopProxy 對其的實現：
@Override
public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
MethodInvocation invocation;
Object oldProxy = null;
boolean setProxyContext = false;
TargetSource targetSource = this.advised.targetSource;
Class<?> targetClass = null;
Object target = null;
try {
if (!this.equalsDefined && AopUtils.isEqualsMethod(method)) {
// The target does not implement the equals(Object) method itself.
// 代理的 equals 方法
return equals(args[0]);
}
else if (!this.hashCodeDefined && AopUtils.isHashCodeMethod(method)) {
// The target does not implement the hashCode() method itself.
// 代理的 hashCode 方法
return hashCode();
}
else if (method.getDeclaringClass() == DecoratingProxy.class) {
// There is only getDecoratedClass() declared -> dispatch to proxy config.
//
return AopProxyUtils.ultimateTargetClass(this.advised);
}
else if (!this.advised.opaque && method.getDeclaringClass().isInterface() &&
method.getDeclaringClass().isAssignableFrom(Advised.class)) {
// Service invocations on ProxyConfig with the proxy config...
return AopUtils.invokeJoinpointUsingReflection(this.advised, method, args);
}
Object retVal;
// 若是設置了 exposeProxy，那麼將 proxy 放到 ThreadLocal 中
if (this.advised.exposeProxy) {
// Make invocation available if necessary.
oldProxy = AopContext.setCurrentProxy(proxy);
setProxyContext = true;
}
// May be null. Get as late as possible to minimize the time we "own" the target,
// in case it comes from a pool.
target = targetSource.getTarget();
if (target != null) {
targetClass = target.getClass();
}
// Get the interception chain for this method.
// 建立一個 chain，包含全部要執行的 advice
List<Object> chain = this.advised.getInterceptorsAndDynamicInterceptionAdvice(method, targetClass);
// Check whether we have any advice. If we don't, we can fallback on direct // reflective invocation of the target, and avoid creating a MethodInvocation. if (chain.isEmpty()) { // We can skip creating a MethodInvocation: just invoke the target directly // Note that the final invoker must be an InvokerInterceptor so we know it does // nothing but a reflective operation on the target, and no hot swapping or fancy proxying. // chain 是空的，說明不須要被加強，這種狀況很簡單 Object[] argsToUse = AopProxyUtils.adaptArgumentsIfNecessary(method, args); retVal = AopUtils.invokeJoinpointUsingReflection(target, method, argsToUse); } else { // We need to create a method invocation... // 執行方法，獲得返回值 invocation = new ReflectiveMethodInvocation(proxy, target, method, args, targetClass, chain); // Proceed to the joinpoint through the interceptor chain. retVal = invocation.proceed(); } // Massage return value if necessary. Class<?> returnType = method.getReturnType(); if (retVal != null && retVal == target && returnType != Object.class && returnType.isInstance(proxy) && !RawTargetAccess.class.isAssignableFrom(method.getDeclaringClass())) { // Special case: it returned "this" and the return type of the method // is type-compatible. Note that we can't help if the target sets
// a reference to itself in another returned object.
retVal = proxy;
}
else if (retVal == null && returnType != Void.TYPE && returnType.isPrimitive()) {
throw new AopInvocationException(
"Null return value from advice does not match primitive return type for: " + method);
}
return retVal;
}
finally {
if (target != null && !targetSource.isStatic()) {
// Must have come from TargetSource.
targetSource.releaseTarget(target);
}
if (setProxyContext) {
// Restore old proxy.
AopContext.setCurrentProxy(oldProxy);
}
}
}
複製代碼
上面就三言兩語說了一下，感興趣的讀者本身去深刻探索下，不是很難。簡單地說，就是在執行每一個方法的時候，判斷下該方法是否須要被一次或屢次加強（執行一個或多個 advice）。
說完了 JDK 動態代理 JdkDynamicAopProxy#getProxy(classLoader)，咱們再來瞄一眼 CGLIB 的代理實現 ObjenesisCglibAopProxy#getProxy(classLoader)。
ObjenesisCglibAopProxy 繼承了 CglibAopProxy，而 CglibAopProxy 繼承了 AopProxy。
ObjenesisCglibAopProxy 使用了 Objenesis 這個庫，和 cglib 同樣，咱們不須要在 maven 中進行依賴，由於 spring-core.jar 直接把它的源代碼也搞過來了。
經過 CGLIB 生成代理的代碼量有點大，咱們就不進行深刻分析了，咱們看下大致的骨架。它的 getProxy(classLoader) 方法在父類 CglibAopProxy 類中：
// CglibAopProxy#getProxy(classLoader)
@Override
public Object getProxy(ClassLoader classLoader) {
...
// Configure CGLIB Enhancer...
Enhancer enhancer = createEnhancer();
if (classLoader != null) {
enhancer.setClassLoader(classLoader);
if (classLoader instanceof SmartClassLoader &&
((SmartClassLoader) classLoader).isClassReloadable(proxySuperClass)) {
enhancer.setUseCache(false);
}
}
enhancer.setSuperclass(proxySuperClass);
enhancer.setInterfaces(AopProxyUtils.completeProxiedInterfaces(this.advised));
enhancer.setNamingPolicy(SpringNamingPolicy.INSTANCE);
enhancer.setStrategy(new ClassLoaderAwareUndeclaredThrowableStrategy(classLoader));
Callback[] callbacks = getCallbacks(rootClass);
Class<?>[] types = new Class<?>[callbacks.length];
for (int x = 0; x < types.length; x++) {
types[x] = callbacks[x].getClass();
}
// fixedInterceptorMap only populated at this point, after getCallbacks call above
enhancer.setCallbackFilter(new ProxyCallbackFilter(
this.advised.getConfigurationOnlyCopy(), this.fixedInterceptorMap, this.fixedInterceptorOffset));
enhancer.setCallbackTypes(types);
// Generate the proxy class and create a proxy instance.
return createProxyClassAndInstance(enhancer, callbacks);
}
catch (CodeGenerationException ex) {
...
}
catch (IllegalArgumentException ex) {
...
}
catch (Throwable ex) {
...
}
}
複製代碼
CGLIB 生成代理的核心類是 Enhancer 類，這裏就不展開說了。
基於註解的 Spring AOP 源碼分析
上面咱們蜻蜓點水地介紹了使用 DefaultAdvisorAutoProxyCreator 來實現 Spring AOP 的源碼，這裏，咱們也一樣蜻蜓點水地來看下 @AspectJ 的實現原理。
咱們以前說過，開啓 @AspectJ 的兩種方式，一個是 <aop:aspectj-autoproxy/>，一個是 @EnableAspectJAutoProxy，它們的原理是同樣的，都是經過註冊一個 bean 來實現的。
解析 <aop:aspectj-autoproxy/> 須要用到 AopNamespaceHandler：
而後到類 AspectJAutoProxyBeanDefinitionParser：
class AspectJAutoProxyBeanDefinitionParser implements BeanDefinitionParser {
@Override
@Nullable
public BeanDefinition parse(Element element, ParserContext parserContext) {
AopNamespaceUtils.registerAspectJAnnotationAutoProxyCreatorIfNecessary(parserContext, element);
extendBeanDefinition(element, parserContext);
return null;
}
...
}
複製代碼
進去 registerAspectJAnnotationAutoProxyCreatorIfNecessary(...) 方法：
public static void registerAspectJAnnotationAutoProxyCreatorIfNecessary(
ParserContext parserContext, Element sourceElement) {
BeanDefinition beanDefinition = AopConfigUtils.registerAspectJAnnotationAutoProxyCreatorIfNecessary(
parserContext.getRegistry(), parserContext.extractSource(sourceElement));
useClassProxyingIfNecessary(parserContext.getRegistry(), sourceElement);
registerComponentIfNecessary(beanDefinition, parserContext);
}
複製代碼
再進去 AopConfigUtils#registerAspectJAnnotationAutoProxyCreatorIfNecessary(...)：
public static BeanDefinition registerAspectJAnnotationAutoProxyCreatorIfNecessary(BeanDefinitionRegistry registry,
@Nullable Object source) {
return registerOrEscalateApcAsRequired(AnnotationAwareAspectJAutoProxyCreator.class, registry, source);
}
複製代碼
最終咱們看到，Spring 註冊了一個 AnnotationAwareAspectJAutoProxyCreator 的 bean，beanName 爲："org.springframework.aop.config.internalAutoProxyCreator"。
咱們看下 AnnotationAwareAspectJAutoProxyCreator 的繼承結構：
和前面介紹的 DefaultAdvisorAutoProxyCreator 同樣，它也是一個 BeanPostProcessor，剩下的咱們就不說了，它和它的父類 AspectJAwareAdvisorAutoProxyCreator 都不復雜。
閒聊 InstantiationAwareBeanPostProcessor
爲何要說這個呢？由於我發現，不少人都覺得 Spring AOP 是經過這個接口來做用於 bean 生成代理的。
public interface InstantiationAwareBeanPostProcessor extends BeanPostProcessor {
Object postProcessBeforeInstantiation(Class<?> beanClass, String beanName) throws BeansException;
boolean postProcessAfterInstantiation(Object bean, String beanName) throws BeansException;
PropertyValues postProcessPropertyValues(
PropertyValues pvs, PropertyDescriptor[] pds, Object bean, String beanName) throws BeansException;
}
複製代碼
它和 BeanPostProcessor 的方法很是類似，並且它還繼承了 BeanPostProcessor。
不仔細看還真的很差區分，下面是 BeanPostProcessor 中的兩個方法：
Object postProcessBeforeInitialization(Object bean, String beanName) throws BeansException;
Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException;
複製代碼
發現沒有，InstantiationAwareBeanPostProcessor 是 Instantiation，BeanPostProcessor 是 Initialization，它表明的是 bean 在實例化完成而且屬性注入完成，在執行 init-method 的先後進行做用的。
而 InstantiationAwareBeanPostProcessor 的執行時機要前面一些，你們須要翻下 IOC 的源碼：
// AbstractAutowireCapableBeanFactory 447行
protected Object createBean(String beanName, RootBeanDefinition mbd, Object[] args) throws BeanCreationException {
...
try {
// 讓 InstantiationAwareBeanPostProcessor 在這一步有機會返回代理
Object bean = resolveBeforeInstantiation(beanName, mbdToUse);
if (bean != null) {
return bean;
}
}
// BeanPostProcessor 是在這裏面實例化後才能獲得執行
Object beanInstance = doCreateBean(beanName, mbdToUse, args);
...
return beanInstance;
}
複製代碼
點進去看 resolveBeforeInstantiation(beanName, mbdToUse) 方法，而後就會導到 InstantiationAwareBeanPostProcessor 的 postProcessBeforeInstantiation 方法，對於咱們分析的 AOP 來講，該方法的實如今 AbstractAutoProxyCreator 類中：
@Override
public Object postProcessBeforeInstantiation(Class<?> beanClass, String beanName) throws BeansException {
...
if (beanName != null) {
TargetSource targetSource = getCustomTargetSource(beanClass, beanName);
if (targetSource != null) {
this.targetSourcedBeans.add(beanName);
Object[] specificInterceptors = getAdvicesAndAdvisorsForBean(beanClass, beanName, targetSource);
Object proxy = createProxy(beanClass, beanName, specificInterceptors, targetSource);
this.proxyTypes.put(cacheKey, proxy.getClass());
return proxy;
}
}
return null;
}
複製代碼
咱們能夠看到，這裏也有建立代理的邏輯，以致於不少人會搞錯。確實，這裏是有可能建立代理的，但前提是對於相應的 bean 咱們有自定義的 TargetSource 實現，進到 getCustomTargetSource(...) 方法就清楚了，咱們須要配置一個 customTargetSourceCreators，它是一個 TargetSourceCreator 數組。
這裏就再也不展開說 TargetSource 了，請參考 Spring Reference 中的 Using TargetSources。
小結
本文真的是蜻蜓點水，和我以前寫的文章有很大的不一樣，但願讀者不會嫌棄。
本文說細節說得比較少，若是你在看源碼的時候碰到不懂的，歡迎在評論區留言與你們進行交流。
（全文完）