Spring AOP源码解析(二)

前言

  上一篇中我们扒拉了一下spring-aop的底裤，详细解读了spring-aop中的各种抽象概念，本篇开始我们一起研究研究spring-aop的织入过程（基于5.2.6.RELEASE）。建议各位同学本地打开一份源码对照食用，效果更佳。

  前方高能！！！本篇重度依赖于上一篇解读的抽象概念，不熟悉的同学请速速撤离，以免误伤。

  正式开始之前，各位同学还请思考一下，在拥有了关于AOP的全局视角之后，如果是你，会怎样有机地结合这些概念来实现织入呢？我听到有同学说利用BeanPostProcessor。嗯，不错，Bean后置处理器给我们提供了这样一个切入点——可以在Bean自动装配完毕、行将可用之前对它进行定制，如果我们在这里返回一个代理对象，那么它就会取代原始对象。具体来说，就是在BeanPostProcessor#postProcessAfterInitialization(...)回调中完成织入并返回新创建的代理对象。那么，真的是这样吗？

一切从EnableAspectJAutoProxy说起

  EnableAspectJAutoProxy的作用自不必多说，不过我们今天深入一点，探究一下它的源码。这个说白了就是看它通过Import元注解向容器中导入了些什么，我们知道Spring中EnableXXX类型的注解都是代理给Import元注解向容器中导入功能组件的。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
@Target({ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Import({AspectJAutoProxyRegistrar.class})
public @interface EnableAspectJAutoProxy {
  	/**
  	 * 是基于JDK动态代理还是CGLIB
  	 */
    boolean proxyTargetClass() default false;

    /**
     * 是否需要暴露代理对象到ThreadLocal中
     */
    boolean exposeProxy() default false;
}

注意到注解中的两个属性也存在于Advised接口，而Advised又保存着AOP配置信息，因此我们可以大胆地猜测这两个属性值最终会同步给Advised。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
class AspectJAutoProxyRegistrar implements ImportBeanDefinitionRegistrar {
	@Override
	public void registerBeanDefinitions(AnnotationMetadata importingClassMetadata,
                                      BeanDefinitionRegistry registry) {
		// 向容器中导入一个类型为AnnotationAwareAspectJAutoProxyCreator的Bean
    // 同时设置它的优先级为Ordered.HIGHEST_PRECEDENCE，角色为BeanDefinition.ROLE_INFRASTRUCTURE
		AopConfigUtils.registerAspectJAnnotationAutoProxyCreatorIfNecessary(registry);
		// 提取EnableAspectJAutoProxy注解的属性
		AnnotationAttributes enableAspectJAutoProxy =
				AnnotationConfigUtils.attributesFor(importingClassMetadata, EnableAspectJAutoProxy.class);
		if (enableAspectJAutoProxy != null) {
      // 如果proxyTargetClass=true，同步给AnnotationAwareAspectJAutoProxyCreator
			if (enableAspectJAutoProxy.getBoolean("proxyTargetClass")) {
				AopConfigUtils.forceAutoProxyCreatorToUseClassProxying(registry);
			}
      // 如果exposeProxy=true，同步给AnnotationAwareAspectJAutoProxyCreator
			if (enableAspectJAutoProxy.getBoolean("exposeProxy")) {
				AopConfigUtils.forceAutoProxyCreatorToExposeProxy(registry);
			}
		}
	}
}

AspectJAutoProxyRegistrar做的事情非常简单：

  1. 向容器中导入一个AnnotationAwareAspectJAutoProxyCreator类型的Bean，并设置优先级和角色
  2. 同步EnableAspectJAutoProxy注解的属性值给它

那么问题来了，这个AnnotationAwareAspectJAutoProxyCreator是个什么鬼呢？看名字的话它是某种自动代理的创建器，那么是不是就是它实现了BeanPostProcessor接口呢？

Variant AutoProxyCreator

Hierarchy of AnnotationAwareAspectJAutoProxyCreator

aj-arch

  查看类图，结果确如我们所想，AnnotationAwareAspectJAutoProxyCreator实现了BeanPostProcessor接口，只不过是其父类实现的。好呗，扒就扒到底，AbstractAutoProxyCreator走起。

What is SmartInstantiationAwareBeanPostProcessor

  题外话，AbstractAutoProxyCreator实现的并不是普通的BeanPostProcessor，而是SmartInstantiationAwareBeanPostProcessor。有些同学可能不太熟悉这个接口，简单说明一下，我们先看它的父接口InstantiationAwareBeanPostProcessor。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
public interface InstantiationAwareBeanPostProcessor extends BeanPostProcessor {
	/**
	 * 在Bean创建之前调用，如果返回一个非空对象，就会跳过标准的Spring Bean创建流程而直接来到
	 * postProcessAfterInitialization(...)，具体逻辑可查看AbstractAutowireCapableBeanFactory#createBean(...)
	 * 也就是说，如果我们想自己全盘接管Bean的生命周期，就可以使用这个回调
	 */
	@Nullable
	default Object postProcessBeforeInstantiation(Class<?> beanClass, String beanName) throws BeansException {
		return null;
	}

	/**
	 * 是否需要为刚创建好的Bean执行自动注入等标准流程，true表示执行标准的Spring Bean初始化流程，
	 * false表示由用户自己控制初始化流程，具体逻辑可查看AbstractAutowireCapableBeanFactory#populateBean(...)
	 */
	default boolean postProcessAfterInstantiation(Object bean, String beanName) throws BeansException {
		return true;
	}

	/**
	 * 在PropertyValues应用到目标Bean上之前，给用户一个机会去修改PropertyValues，这一步其实在
	 * BeanFactoryPostProcessor#postProcessBeanFactory(...)中也能实现，只是没有这里来得方便
	 */
	@Nullable
	default PropertyValues postProcessProperties(PropertyValues pvs, Object bean, 
                                               String beanName) throws BeansException {
		return null;
	}

	/**
	 * 已由#postProcessProperties(...)代替
	 */
	@Deprecated
	@Nullable
	default PropertyValues postProcessPropertyValues(PropertyValues pvs, PropertyDescriptor[] pds, 
                                                   Object bean, String beanName) throws BeansException {
		return pvs;
	}
}

spring-context中，CommonAnnotationBeanPostProcessor就实现了InstantiationAwareBeanPostProcessor接口用以支持javax.annotation.Resource注解。接下来是SmartInstantiationAwareBeanPostProcessor。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
public interface SmartInstantiationAwareBeanPostProcessor extends InstantiationAwareBeanPostProcessor {
	/**
	 * 预测#postProcessBeforeInstantiation(...)的回调参数beanClass，主要还是用来做type match
	 */
	@Nullable
	default Class<?> predictBeanType(Class<?> beanClass, String beanName) throws BeansException {
		return null;
	}

	/**
   * 返回候选的构造函数，用来决定是否采用autowire by constructor这种装配策略，
   * 具体逻辑可查看AbstractAutowireCapableBeanFactory#createBeanInstance(...)
	 */
	@Nullable
	default Constructor<?>[] determineCandidateConstructors(Class<?> beanClass, 
                                                          String beanName) throws BeansException {
		return null;
	}

	/**
	 * Spring解决循环依赖的思路是提前创建 + 缓存，#getEarlyBeanReference(...)给了我们一个机
	 * 会去访问这个被提前创建的Bean，因此我们可以在这里提前创建代理对象被返回，具体逻辑可查看
	 * AbstractAutowireCapableBeanFactory#getEarlyBeanReference(...)
	 * NOTE: 因为循环依赖的关系，这里传递进来的Bean是没有完全初始化好的，换句话说客户端是不能直接使用的
	 */
	default Object getEarlyBeanReference(Object bean, String beanName) throws BeansException {
		return bean;
	}
}

AbstractAutoProxyCreator是如何执行织入的

Implementing SmartInstantiationAwareBeanPostProcessor

  好了，言归正题，回到AbstractAutoProxyCreator，挑出它对SmartInstantiationAwareBeanPostProcessor的实现部分。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
/**
  * 换个角度理解，如果目标对象已经被包装过，那么它的类型肯定
  * 会发生改变，因此也就需要一种机制来告诉容器包装后类型，否则
  * 后续类型匹配就会出错，这个机制就是#predictBeanType(...)
  */
@Override
@Nullable
public Class<?> predictBeanType(Class<?> beanClass, String beanName) {
	if (this.proxyTypes.isEmpty()) {
		return null;
	}
   // 获取缓存key
	Object cacheKey = getCacheKey(beanClass, beanName);
   // proxyTypes的类型是Map<Object, Class<?>>
   // 不管是JDK动态代理，还是CGLIB动态生成子类，最终都会改变
   // 目标对象在容器中的类型，proxyTypes中保存着包装后的类型
	return this.proxyTypes.get(cacheKey);
}

@Override
public Object getEarlyBeanReference(Object bean, String beanName) {
	Object cacheKey = getCacheKey(bean.getClass(), beanName);
   // earlyProxyReferences的类型是Map<Object, Object>
   // getEarlyBeanReference(...)是最早能够访问到目标对象的地方
   // 然而，目标对象可能会在后续的后处理中被改变，比如被其它的处理器修改。
   // 但是只要在earlyProxyReferences中保存着原始目标对象，后续就可以
   // 检测目标对象是否真的被改变了
	this.earlyProxyReferences.put(cacheKey, bean);
   // 尝试包装目标对象，画重点，织入的核心逻辑
	return wrapIfNecessary(bean, beanName, cacheKey);
}

@Override
public Object postProcessBeforeInstantiation(Class<?> beanClass, String beanName) {
	Object cacheKey = getCacheKey(beanClass, beanName);
	// targetSourcedBeans中保存着通过自定义TargetSourceCreator创建的目标对象
   // 前面说过，#postProcessBeforeInstantiation(...)这个回调给了客户端全盘
   // 接管Bean生命周期的机会，TargetSourceCreator这个工厂接口就是设计来让客户
   // 端自行处理Bean的创建和属性注入等逻辑的。换言之，通过自定义TargetSourceCreator
   // 返回的目标对象被认为是完全初始化了的，并且会跳过标准的Spring Bean生命周期管理，那么
   // 这里就是最后的机会来完成织入并返回代理对象了
	if (!StringUtils.hasLength(beanName) || !this.targetSourcedBeans.contains(beanName)) {
     // advisedBeans的类型是Map<Object, Boolean>
     // 如果值为false，表示当前这个Bean不需要被代理
     // 值为true，表示已经被代理过了
     // 那么如果不需要代理，肯定就直接返回了
     // 如果已经代理过了，自然也不需要二次代理
     // 所以这里才用containsKey(...)判断一下
		if (this.advisedBeans.containsKey(cacheKey)) {
			return null;
		}
     // 1、isInfrastructureClass()检测Bean所属的类是不是Spring AOP的支撑类
     // 比如Advisor、Pointcut等等，这些类型是不需要被代理的
     // 2、shouldSkip(...)给了子类一个机会来决定 beanClass + beanName 二元组
     // 对应的Bean是不是不用进行代理
		if (isInfrastructureClass(beanClass) || shouldSkip(beanClass, beanName)) {
			this.advisedBeans.put(cacheKey, Boolean.FALSE);
			return null;
		}
	}

   // 如果用户确实需要全盘接管目标对象的生命周期
   // 那么这里是最后一个机会来完成织入并返回代理对象了
	TargetSource targetSource = getCustomTargetSource(beanClass, beanName);
	if (targetSource != null) {
		if (StringUtils.hasLength(beanName)) {
       // 记录下来
			this.targetSourcedBeans.add(beanName);
		}
     // 现在，目标对象已经到位 --> 从TargetSource中获取
     // 接下来只要知道可以作用在目标对象上的Advisor都有
     // 哪些就可以着手创建代理了
     
     // step 1: 模板方法，由子类实现，返回所有可能的Advisor
		Object[] specificInterceptors = getAdvicesAndAdvisorsForBean(beanClass, beanName, targetSource);
     // step 2: 根据已经掌握的信息 targetSouce + Advisors 来创建代理
		Object proxy = createProxy(beanClass, beanName, specificInterceptors, targetSource);
     // 代理创建完成以后，把它的类型记下来
		this.proxyTypes.put(cacheKey, proxy.getClass());
		return proxy;
	}
   
	return null;
}

@Override
public Object postProcessAfterInitialization(@Nullable Object bean, String beanName) {
	if (bean != null) {
		Object cacheKey = getCacheKey(bean.getClass(), beanName);
     // 前面说过，earlyProxyReferences中保存着bean的原始引用
     // 现在只需要简单判断一下就知道它有没有在其它地方被修改
     // 如果是，那就不得不重新尝试一下对它进行代理了
		if (this.earlyProxyReferences.remove(cacheKey) != bean) {
			return wrapIfNecessary(bean, beanName, cacheKey);
		}
	}
	return bean;
}

如果不考虑自定义TargetSourceCreator这种非常规流程，AbstractAutoProxyCreator一共有两个机会来完成织入，一处在getEarlyBeanReference(...)，另一处在postProcessAfterInitialization(...)。这两处都调用了wrapIfNecessary(...)来完成最后的织入，继续往下看。

wrapIfNecessary
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
protected Object wrapIfNecessary(Object bean, String beanName, Object cacheKey) {
	// 如果用户自行控制生命周期，就什么都不做
	if (StringUtils.hasLength(beanName) && this.targetSourcedBeans.contains(beanName)) {
		return bean;
	}
   // 对不需要被代理的类型，也什么都不做
	if (Boolean.FALSE.equals(this.advisedBeans.get(cacheKey))) {
		return bean;
	}
   // 对可能需要被代理类型，进一步检查它是否真的需要被代理
   // 这一步的检测逻辑同 #postProcessBeforeInstantiation(...)
	if (isInfrastructureClass(bean.getClass()) || shouldSkip(bean.getClass(), beanName)) {
		this.advisedBeans.put(cacheKey, Boolean.FALSE);
		return bean;
	}

   // step 1: 通过模板方法获取所有Advisor
	Object[] specificInterceptors = getAdvicesAndAdvisorsForBean(bean.getClass(), beanName, null);
   // 如果不为空，也就是配置了Advice，当然就需要被代理了
	if (specificInterceptors != DO_NOT_PROXY) {
		this.advisedBeans.put(cacheKey, Boolean.TRUE);
     // strp 2: 根据 目标对象 + Advisors 这两份信息来创建代理
     // createProxy(...)会根据配置信息来创建代理（jdk dynamic proxy/cglib subclassing）
     // 并且，Advisors经过处理后会组成一个拦截器链，这一部分的内容比较复杂，我们下篇再说
		Object proxy = createProxy(
				bean.getClass(), beanName, specificInterceptors, new SingletonTargetSource(bean));
     // 记录下代理对象的类型
		this.proxyTypes.put(cacheKey, proxy.getClass());
		return proxy;
	}
	// 没有找到任何Advisor，也就是说没有配置任何Advice
   // 那还代理给毛，自然就是false了
	this.advisedBeans.put(cacheKey, Boolean.FALSE);
	return bean;
}

wrapIfNecessary(...)和postProcessBeforeInstantiation(...)做的事情差不多，核心逻辑其实只有两步：

  1. 获取可以作用在目标对象上的Advisor集合
  2. 将第1步获取到的Advisor list转换成Interceptor list并安装到Join point上，说人话就是创建代理对象

createProxy(...)整个流程比较复杂，涉及到Advice的适配和扩展、拦截器链的初始化和安装、代理的创建等等，我们下篇再说。getAdvicesAndAdvisorsForBean(...)是一个模板方法，实现它的是AbstractAutoProxyCreator的子类AbstractAdvisorAutoProxyCreator，接下来我们分析一下getAdvicesAndAdvisorsForBean(...)。

AbstractAdvisorAutoProxyCreator是如何筛选Advisor的

getAdvicesAndAdvisorsForBean
1
2
3
4
5
6
7
8
9
10
@Override
@Nullable
protected Object[] getAdvicesAndAdvisorsForBean(Class<?> beanClass, String beanName,
                                                 @Nullable TargetSource targetSource) {
	List<Advisor> advisors = findEligibleAdvisors(beanClass, beanName);
	if (advisors.isEmpty()) {
		return DO_NOT_PROXY;
	}
	return advisors.toArray();
}

可以看到，它代理给了findEligibleAdvisors(...)，继续跟踪。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
protected List<Advisor> findEligibleAdvisors(Class<?> beanClass, String beanName) {
   // 获取BeanFactory中所有的Advisor
	List<Advisor> candidateAdvisors = findCandidateAdvisors();
   // Sping AOP中Advisor的类型主要是PointcutAdvisor
   // 这一步核心逻辑就是用Pointcut来对Advisor进行筛选
	List<Advisor> eligibleAdvisors = findAdvisorsThatCanApply(candidateAdvisors, beanClass, beanName);
   // 扩展方法，给子类一个增删改Advisor的机会
	extendAdvisors(eligibleAdvisors);
	if (!eligibleAdvisors.isEmpty()) {
     // 对Advisor进行排序，默认通过Spring标准的Ordered接口和@Order注解指定优先级
		eligibleAdvisors = sortAdvisors(eligibleAdvisors);
	}
	return eligibleAdvisors;
}

findEligibleAdvisors(...)的流程还是比较清晰的：

  1. 找出容器中所有的Advisor
  2. 通过Pointcut进行筛选
  3. 对剩下的Advisor进行排序
findCandidateAdvisors
1
2
3
4
protected List<Advisor> findCandidateAdvisors() {
	Assert.state(this.advisorRetrievalHelper != null, "No BeanFactoryAdvisorRetrievalHelper available");
	return this.advisorRetrievalHelper.findAdvisorBeans();
}

发现它又代理给了advisorRetrievalHelper#findAdvisorBeans()。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
public List<Advisor> findAdvisorBeans() {
	// 先读缓存
   String[] advisorNames = this.cachedAdvisorBeanNames;
	if (advisorNames == null) {
     // 缓存没有的话，从BeanFactory中一次性把所有的Advisor Bean的名称获取出来
		advisorNames = BeanFactoryUtils.beanNamesForTypeIncludingAncestors(
				this.beanFactory, Advisor.class, true, false);
		this.cachedAdvisorBeanNames = advisorNames;
	}
   // BeanFactory中也没有，那就真的没有了
	if (advisorNames.length == 0) {
		return new ArrayList<>();
	}

   // 否则的话，根据beanName挨个调用getBean(...)
	List<Advisor> advisors = new ArrayList<>();
	for (String name : advisorNames) {
     // 首先判断一下这个name所代表的Advisor是否符合条件，默认返回true
     // 可由AbstractAdvisorAutoProxyCreator及其子类进行改写，比如
     // InfrastructureAdvisorAutoProxyCreator就要求Advisor的角色
     // 必须是ROLE_INFRASTRUCTURE，所以@EnableCaching/@EnableTransactionManagement
     // 导入的一票Advisor的role都是ROLE_INFRASTRUCTURE
		if (isEligibleBean(name)) {
       // 跳过正在初始化的Advisor，毕竟这种的拿了也没用
			if (this.beanFactory.isCurrentlyInCreation(name)) {
				if (logger.isTraceEnabled()) {
					logger.trace("Skipping currently created advisor '" + name + "'");
				}
			}
			else {
				try {
           // 逐个获取
					advisors.add(this.beanFactory.getBean(name, Advisor.class));
				}
				catch (BeanCreationException ex) {
           // 如果目标对象和附加在它之上的Advisor间存在循环依赖
           // 这也是抛出BeanCurrentlyInCreationException异常的原因
           // 对这种情况，忽略这个Advisor
           // 个人感觉这种情况是否还是抛出异常比较好？
					Throwable rootCause = ex.getMostSpecificCause();
					if (rootCause instanceof BeanCurrentlyInCreationException) {
						BeanCreationException bce = (BeanCreationException) rootCause;
						String bceBeanName = bce.getBeanName();
						if (bceBeanName != null && this.beanFactory.isCurrentlyInCreation(bceBeanName)) {
							if (logger.isTraceEnabled()) {
								logger.trace("Skipping advisor '" + name +
										"' with dependency on currently created bean: " + ex.getMessage());
							}
							continue;
						}
					}
					throw ex;
				}
			}
		}
	}
	return advisors;
}
findAdvisorsThatCanApply
1
2
3
4
5
6
7
8
9
10
11
12
protected List<Advisor> findAdvisorsThatCanApply(
		List<Advisor> candidateAdvisors, Class<?> beanClass, String beanName) {
	// 在ThreadLocal中记录一下beanName
   // 用在spring自定义的 bean() AspectJ表达式中，不是很常用
	ProxyCreationContext.setCurrentProxiedBeanName(beanName);
	try {
		return AopUtils.findAdvisorsThatCanApply(candidateAdvisors, beanClass);
	}
	finally {
		ProxyCreationContext.setCurrentProxiedBeanName(null);
	}
}

核心逻辑都在AopUtils中了。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
public static List<Advisor> findAdvisorsThatCanApply(List<Advisor> candidateAdvisors, Class<?> clazz) {
	if (candidateAdvisors.isEmpty()) {
		return candidateAdvisors;
	}
	List<Advisor> eligibleAdvisors = new ArrayList<>();
   // IntroductionAdvisor我们就不说了，用得比较少
	for (Advisor candidate : candidateAdvisors) {
		if (candidate instanceof IntroductionAdvisor && canApply(candidate, clazz)) {
			eligibleAdvisors.add(candidate);
		}
	}
	boolean hasIntroductions = !eligibleAdvisors.isEmpty();
	for (Advisor candidate : candidateAdvisors) {
		if (candidate instanceof IntroductionAdvisor) {
			// already processed
			continue;
		}
     // 判断Advisor能否适用于此beanClass
		if (canApply(candidate, clazz, hasIntroductions)) {
			eligibleAdvisors.add(candidate);
		}
	}
	return eligibleAdvisors;
}

public static boolean canApply(Advisor advisor, Class<?> targetClass, boolean hasIntroductions) {
   // 忽略IntroductionAdvisor吧，我们不讲它
   // 毕竟PointcutAdvisor几乎就能代表spring中的Advisor了
	if (advisor instanceof IntroductionAdvisor) {
		return ((IntroductionAdvisor) advisor).getClassFilter().matches(targetClass);
	}
   // 如果是PointcutAdvisor
	else if (advisor instanceof PointcutAdvisor) {
		PointcutAdvisor pca = (PointcutAdvisor) advisor;
     // 使用Pointcut进行筛选
		return canApply(pca.getPointcut(), targetClass, hasIntroductions);
	}
	else {
     // Pointcut都没有的话默认它可以
     // 简单理解，这是一种generic advisor
		return true;
	}
}

 public static boolean canApply(Pointcut pc, Class<?> targetClass, boolean hasIntroductions) {
   Assert.notNull(pc, "Pointcut must not be null");
   // 首先看看类型是否匹配
   if (!pc.getClassFilter().matches(targetClass)) {
     return false;
   }
   
	// Special case: MethodMatcher.TRUE 对任何方法都返回match
   MethodMatcher methodMatcher = pc.getMethodMatcher();
   if (methodMatcher == MethodMatcher.TRUE) {
		// 自然没有判断的必要
     return true;
   }

   // 忽略Introduction吧
   IntroductionAwareMethodMatcher introductionAwareMethodMatcher = null;
   if (methodMatcher instanceof IntroductionAwareMethodMatcher) {
     introductionAwareMethodMatcher = (IntroductionAwareMethodMatcher) methodMatcher;
   }

   Set<Class<?>> classes = new LinkedHashSet<>();
   // 获取targetClass的原始类型，只有原始类型上才可能存在用户定义的方法
   // 也只有这些方法才有必要判断它是否匹配
   // 1. 不能是jdk dymamic proxy，jdk dynamic proxy上就不可能有
   if (!Proxy.isProxyClass(targetClass)) {
     // 2. 虽然不是jdk dynamic proxy，但有可能是cglib动态生成的子类啊，
     // cglib动态生成的子类也不可能有，所以需要获取一下user class
     classes.add(ClassUtils.getUserClass(targetClass));
   }
   
   // targetClass所实现接口也获取一下，接口中会定义方法，
   // 方法上可能有注解，而这些注解，有可能就是判断条件，比如说
   // spring-tx的@Transactional是可以标注在接口上的
   classes.addAll(ClassUtils.getAllInterfacesForClassAsSet(targetClass));

   for (Class<?> clazz : classes) {
     // 这没啥说的了，所有方法拿出来，逐个使用MethodMatcher判断一下
     // 这里不涉及isRuntime()的情况，那种情况需要方法被实际调用了才能判断
     // 对jdk dynamic proxy来说就是InvocationHandler#invoke(...)被调用的时候
     Method[] methods = ReflectionUtils.getAllDeclaredMethods(clazz);
     for (Method method : methods) {
       if (introductionAwareMethodMatcher != null ?
           introductionAwareMethodMatcher.matches(method, targetClass, hasIntroductions) :
           methodMatcher.matches(method, targetClass)) {
         return true;
       }
     }
   }

   return false;
 }
sortAdvisors
1
2
3
4
protected List<Advisor> sortAdvisors(List<Advisor> advisors) {
	AnnotationAwareOrderComparator.sort(advisors);
	return advisors;
}

默认的排序策略是很简单的，根据Advisor实现的Ordered接口或标注的Order注解提供的优先级进行排序。

结语

  本篇我们从EnableAspectJAutoProxy注解着手，一步一步分析了spring-aop是如何通过BeanPostProcessor来执行织入的，下一篇我们一起看看创建动态代理的全流程吧~~

Spring

本博客所有文章除特别声明外，均采用 CC BY-SA 4.0 协议 ，转载请注明出处！