AspectJAwareAdvisorAutoProxyCreator及为Bean生成代理时机分析
上篇文章说了,org.springframework.aop.aspectj.autoproxy.AspectJAwareAdvisorAutoProxyCreator这个类是Spring提供给开发者的AOP的核心类,就是AspectJAwareAdvisorAutoProxyCreator完成了【类/接口–>代理】的转换过程,首先我们看一下AspectJAwareAdvisorAutoProxyCreator的层次结构:
这里最值得注意的一点是最左下角的那个方框,我用几句话总结一下:
- AspectJAwareAdvisorAutoProxyCreator是BeanPostProcessor接口的实现类
- postProcessBeforeInitialization方法与postProcessAfterInitialization方法实现在父类AbstractAutoProxyCreator中
- postProcessBeforeInitialization方法是一个空实现
- 逻辑代码在postProcessAfterInitialization方法中
基于以上的分析,将Bean生成代理的时机已经一目了然了:在每个Bean初始化之后,如果需要,调用AspectJAwareAdvisorAutoProxyCreator中的postProcessBeforeInitialization为Bean生成代理。
代理对象实例化—-判断是否为<bean>生成代理
上文分析了Bean生成代理的时机是在每个Bean初始化之后,下面把代码定位到Bean初始化之后,先是AbstractAutowireCapableBeanFactory的initializeBean方法进行初始化:
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
|
protected
Object initializeBean( final
String beanName, final
Object bean, RootBeanDefinition mbd) {
if
(System.getSecurityManager() != null )
{
AccessController.doPrivileged( new
PrivilegedAction<Object>() {
public
Object run() {
invokeAwareMethods(beanName,
bean);
return
null ;
}
},
getAccessControlContext());
}
else
{
invokeAwareMethods(beanName,
bean);
}
Object
wrappedBean = bean;
if
(mbd == null
|| !mbd.isSynthetic()) {
wrappedBean
= applyBeanPostProcessorsBeforeInitialization(wrappedBean, beanName);
}
try
{
invokeInitMethods(beanName,
wrappedBean, mbd);
}
catch
(Throwable ex) {
throw
new
BeanCreationException(
(mbd
!= null
? mbd.getResourceDescription() : null ),
beanName,
"Invocation
of init method failed" ,
ex);
}
if
(mbd == null
|| !mbd.isSynthetic()) {
wrappedBean
= applyBeanPostProcessorsAfterInitialization(wrappedBean, beanName);
}
return
wrappedBean;
}
|
初始化之前是第16行的applyBeanPostProcessorsBeforeInitialization方法,初始化之后即29行的applyBeanPostProcessorsAfterInitialization方法:
1
2
3
4
5
6
7
8
9
10
11
12
|
public
Object applyBeanPostProcessorsAfterInitialization(Object existingBean, String beanName)
throws
BeansException {
Object
result = existingBean;
for
(BeanPostProcessor beanProcessor : getBeanPostProcessors()) {
result
= beanProcessor.postProcessAfterInitialization(result, beanName);
if
(result == null )
{
return
result;
}
}
return
result;
}
|
这里调用每个BeanPostProcessor的postProcessBeforeInitialization方法。按照之前的分析,看一下AbstractAutoProxyCreator的postProcessAfterInitialization方法实现:
1
2
3
4
5
6
7
8
9
|
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;
}
|
跟一下第5行的方法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
|
protected
Object wrapIfNecessary(Object bean, String beanName, Object cacheKey) {
if
( this .targetSourcedBeans.contains(beanName))
{
return
bean;
}
if
( this .nonAdvisedBeans.contains(cacheKey))
{
return
bean;
}
if
(isInfrastructureClass(bean.getClass()) || shouldSkip(bean.getClass(), beanName)) {
this .nonAdvisedBeans.add(cacheKey);
return
bean;
}
//
Create proxy if we have advice.
Object[]
specificInterceptors = getAdvicesAndAdvisorsForBean(bean.getClass(), beanName,
null );
if
(specificInterceptors != DO_NOT_PROXY) {
this .advisedBeans.add(cacheKey);
Object
proxy = createProxy(bean.getClass(), beanName, specificInterceptors, new
SingletonTargetSource(bean));
this .proxyTypes.put(cacheKey,
proxy.getClass());
return
proxy;
}
this .nonAdvisedBeans.add(cacheKey);
return
bean;
}
|
第2行~第11行是一些不需要生成代理的场景判断,这里略过。首先我们要思考的第一个问题是:哪些目标对象需要生成代理?因为配置文件里面有很多Bean,肯定不能对每个Bean都生成代理,因此需要一套规则判断Bean是不是需要生成代理,这套规则就是第14行的代码getAdvicesAndAdvisorsForBean:
1
2
3
4
5
6
7
8
9
|
protected
List<Advisor> findEligibleAdvisors(Class beanClass, String beanName) {
List<Advisor>
candidateAdvisors = findCandidateAdvisors();
List<Advisor>
eligibleAdvisors = findAdvisorsThatCanApply(candidateAdvisors, beanClass, beanName);
extendAdvisors(eligibleAdvisors);
if
(!eligibleAdvisors.isEmpty()) {
eligibleAdvisors
= sortAdvisors(eligibleAdvisors);
}
return
eligibleAdvisors;
}
|
顾名思义,方法的意思是为指定class寻找合适的Advisor。
第2行代码,寻找候选Advisors,根据上文的配置文件,有两个候选Advisor,分别是<aop:aspect>节点下的<aop:before>和<aop:after>这两个,这两个在XML解析的时候已经被转换生成了RootBeanDefinition。
跳过第3行的代码,先看下第4行的代码extendAdvisors方法,之后再重点看一下第3行的代码。第4行的代码extendAdvisors方法作用是向候选Advisor链的开头(也就是List.get(0)的位置)添加一个org.springframework.aop.support.DefaultPointcutAdvisor。
第3行代码,根据候选Advisors,寻找可以使用的Advisor,跟一下方法实现:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
|
public
static
List<Advisor> findAdvisorsThatCanApply(List<Advisor> candidateAdvisors, Class<?> clazz) {
if
(candidateAdvisors.isEmpty()) {
return
candidateAdvisors;
}
List<Advisor>
eligibleAdvisors = new
LinkedList<Advisor>();
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 ;
}
if
(canApply(candidate, clazz, hasIntroductions)) {
eligibleAdvisors.add(candidate);
}
}
return
eligibleAdvisors;
}
|
整个方法的主要判断都围绕canApply展开方法:
1
2
3
4
5
6
7
8
9
10
11
12
13
|
public
static
boolean
canApply(Advisor advisor, Class<?> targetClass, boolean
hasIntroductions) {
if
(advisor instanceof
IntroductionAdvisor) {
return
((IntroductionAdvisor) advisor).getClassFilter().matches(targetClass);
}
else
if
(advisor instanceof
PointcutAdvisor) {
PointcutAdvisor
pca = (PointcutAdvisor) advisor;
return
canApply(pca.getPointcut(), targetClass, hasIntroductions);
}
else
{
//
It doesn't have a pointcut so we assume it applies.
return
true ;
}
}
|
第一个参数advisor的实际类型是AspectJPointcutAdvisor,它是PointcutAdvisor的子类,因此执行第7行的方法:
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
|
public
static
boolean
canApply(Pointcut pc, Class<?> targetClass, boolean
hasIntroductions) {
if
(!pc.getClassFilter().matches(targetClass)) {
return
false ;
}
MethodMatcher
methodMatcher = pc.getMethodMatcher();
IntroductionAwareMethodMatcher
introductionAwareMethodMatcher = null ;
if
(methodMatcher instanceof
IntroductionAwareMethodMatcher) {
introductionAwareMethodMatcher
= (IntroductionAwareMethodMatcher) methodMatcher;
}
Set<Class>
classes = new
HashSet<Class>(ClassUtils.getAllInterfacesForClassAsSet(targetClass));
classes.add(targetClass);
for
(Class<?> clazz : classes) {
Method[]
methods = clazz.getMethods();
for
(Method method : methods) {
if
((introductionAwareMethodMatcher != null
&&
introductionAwareMethodMatcher.matches(method,
targetClass, hasIntroductions)) ||
methodMatcher.matches(method,
targetClass)) {
return
true ;
}
}
}
return
false ;
}
|
这个方法其实就是拿当前Advisor对应的expression做了两层判断:
- 目标类必须满足expression的匹配规则
- 目标类中的方法必须满足expression的匹配规则,当然这里方法不是全部需要满足expression的匹配规则,有一个方法满足即可
如果以上两条都满足,那么容器则会判断该<bean>满足条件,需要被生成代理对象,具体方式为返回一个数组对象,该数组对象中存储的是<bean>对应的Advisor。
代理对象实例化—-为<bean>生成代理代码上下文梳理
上文分析了为<bean>生成代理的条件,现在就正式看一下Spring上下文是如何为<bean>生成代理的。回到AbstractAutoProxyCreator的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
|
protected
Object wrapIfNecessary(Object bean, String beanName, Object cacheKey) {
if
( this .targetSourcedBeans.contains(beanName))
{
return
bean;
}
if
( this .nonAdvisedBeans.contains(cacheKey))
{
return
bean;
}
if
(isInfrastructureClass(bean.getClass()) || shouldSkip(bean.getClass(), beanName)) {
this .nonAdvisedBeans.add(cacheKey);
return
bean;
}
//
Create proxy if we have advice.
Object[]
specificInterceptors = getAdvicesAndAdvisorsForBean(bean.getClass(), beanName,
null );
if
(specificInterceptors != DO_NOT_PROXY) {
this .advisedBeans.add(cacheKey);
Object
proxy = createProxy(bean.getClass(), beanName, specificInterceptors, new
SingletonTargetSource(bean));
this .proxyTypes.put(cacheKey,
proxy.getClass());
return
proxy;
}
this .nonAdvisedBeans.add(cacheKey);
return
bean;
}
|
第14行拿到<bean>对应的Advisor数组,第15行判断只要Advisor数组不为空,那么就会通过第17行的代码为<bean>创建代理:
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
|
protected
Object createProxy(
Class<?>
beanClass, String beanName, Object[] specificInterceptors, TargetSource targetSource) {
ProxyFactory
proxyFactory = new
ProxyFactory();
//
Copy our properties (proxyTargetClass etc) inherited from ProxyConfig.
proxyFactory.copyFrom( this );
if
(!shouldProxyTargetClass(beanClass, beanName)) {
//
Must allow for introductions; can't just set interfaces to
//
the target's interfaces only.
Class<?>[]
targetInterfaces = ClassUtils.getAllInterfacesForClass(beanClass, this .proxyClassLoader);
for
(Class<?> targetInterface : targetInterfaces) {
proxyFactory.addInterface(targetInterface);
}
}
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( this .proxyClassLoader);
}
|
第4行~第6行new出了一个ProxyFactory,Proxy,顾名思义,代理工厂的意思,提供了简单的方式使用代码获取和配置AOP代理。
第8行的代码做了一个判断,判断的内容是<aop:config>这个节点中proxy-target-class=”false”或者proxy-target-class不配置,即不使用CGLIB生成代理。如果满足条件,进判断,获取当前Bean实现的所有接口,讲这些接口Class对象都添加到ProxyFactory中。
第17行~第28行的代码没什么看的必要,向ProxyFactory中添加一些参数而已。重点看第30行proxyFactory.getProxy(this.proxyClassLoader)这句:
1
2
3
|
public
Object getProxy(ClassLoader classLoader) {
return
createAopProxy().getProxy(classLoader);
}
|
实现代码就一行,但是却明确告诉我们做了两件事情:
- 创建AopProxy接口实现类
- 通过AopProxy接口的实现类的getProxy方法获取<bean>对应的代理
就从这两个点出发,分两部分分析一下。
代理对象实例化—-创建AopProxy接口实现类
看一下createAopProxy()方法的实现,它位于DefaultAopProxyFactory类中:
1
2
3
4
5
6
|
protected
final
synchronized
AopProxy createAopProxy() {
if
(! this .active)
{
activate();
}
return
getAopProxyFactory().createAopProxy( this );
}
|
前面的部分没什么必要看,直接进入重点即createAopProxy方法:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
|
public
AopProxy createAopProxy(AdvisedSupport config) throws
AopConfigException {
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." );
}
if
(targetClass.isInterface()) {
return
new
JdkDynamicAopProxy(config);
}
if
(!cglibAvailable) {
throw
new
AopConfigException(
"Cannot
proxy target class because CGLIB2 is not available. "
+
"Add
CGLIB to the class path or specify proxy interfaces." );
}
return
CglibProxyFactory.createCglibProxy(config);
}
else
{
return
new
JdkDynamicAopProxy(config);
}
}
|
平时我们说AOP原理三句话就能概括:
- 对类生成代理使用CGLIB
- 对接口生成代理使用JDK原生的Proxy
- 可以通过配置文件指定对接口使用CGLIB生成代理
这三句话的出处就是createAopProxy方法。看到默认是第19行的代码使用JDK自带的Proxy生成代理,碰到以下三种情况例外:
- ProxyConfig的isOptimize方法为true,这表示让Spring自己去优化而不是用户指定
- ProxyConfig的isProxyTargetClass方法为true,这表示配置了proxy-target-class=”true”
- ProxyConfig满足hasNoUserSuppliedProxyInterfaces方法执行结果为true,这表示<bean>对象没有实现任何接口或者实现的接口是SpringProxy接口
在进入第2行的if判断之后再根据目标<bean>的类型决定返回哪种AopProxy。简单总结起来就是:
- proxy-target-class没有配置或者proxy-target-class=”false”,返回JdkDynamicAopProxy
- proxy-target-class=”true”或者<bean>对象没有实现任何接口或者只实现了SpringProxy接口,返回Cglib2AopProxy
当然,不管是JdkDynamicAopProxy还是Cglib2AopProxy,AdvisedSupport都是作为构造函数参数传入的,里面存储了具体的Advisor。
代理对象实例化—-通过getProxy方法获取<bean>对应的代理
其实代码已经分析到了JdkDynamicAopProxy和Cglib2AopProxy,剩下的就没什么好讲的了,无非就是看对这两种方式生成代理的熟悉程度而已。
Cglib2AopProxy生成代理的代码就不看了,对Cglib不熟悉的朋友可以看Cglib及其基本使用一文。
JdkDynamicAopProxy生成代理的方式稍微看一下:
1
2
3
4
5
6
7
8
|
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);
findDefinedEqualsAndHashCodeMethods(proxiedInterfaces);
return
Proxy.newProxyInstance(classLoader, proxiedInterfaces, this );
}
|
这边解释一下第5行和第6行的代码,第5行代码的作用是拿到所有要代理的接口,第6行代码的作用是尝试寻找这些接口方法里面有没有equals方法和hashCode方法,同时都有的话打个标记,寻找结束,equals方法和hashCode方法有特殊处理。
最终通过第7行的Proxy.newProxyInstance方法获取接口/类对应的代理对象,Proxy是JDK原生支持的生成代理的方式。
代理方法调用原理
前面已经详细分析了为接口/类生成代理的原理,生成代理之后就要调用方法了,这里看一下使用JdkDynamicAopProxy调用方法的原理。
由于JdkDynamicAopProxy本身实现了InvocationHandler接口,因此具体代理前后处理的逻辑在invoke方法中:
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
|
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.
return
equals(args[ 0 ]);
}
if
(! this .hashCodeDefined
&& AopUtils.isHashCodeMethod(method)) {
//
The target does not implement the hashCode() method itself.
return
hashCode();
}
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;
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.
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.
retVal
= AopUtils.invokeJoinpointUsingReflection(target, method, args);
}
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.
if
(retVal != null
&& retVal == target && method.getReturnType().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;
}
return
retVal;
}
finally
{
if
(target != null
&& !targetSource.isStatic()) {
//
Must have come from TargetSource.
targetSource.releaseTarget(target);
}
if
(setProxyContext) {
//
Restore old proxy.
AopContext.setCurrentProxy(oldProxy);
}
}
}
|
第11行~第18行的代码,表示equals方法与hashCode方法即使满足expression规则,也不会为之产生代理内容,调用的是JdkDynamicAopProxy的equals方法与hashCode方法。至于这两个方法是什么作用,可以自己查看一下源代码。
第19行~第23行的代码,表示方法所属的Class是一个接口并且方法所属的Class是AdvisedSupport的父类或者父接口,直接通过反射调用该方法。
第27行~第30行的代码,是用于判断是否将代理暴露出去的,由<aop:config>标签中的expose-proxy=”true/false”配置。
第41行的代码,获取AdvisedSupport中的所有拦截器和动态拦截器列表,用于拦截方法,具体到我们的实际代码,列表中有三个Object,分别是:
- chain.get(0):ExposeInvocationInterceptor,这是一个默认的拦截器,对应的原Advisor为DefaultPointcutAdvisor
- chain.get(1):MethodBeforeAdviceInterceptor,用于在实际方法调用之前的拦截,对应的原Advisor为AspectJMethodBeforeAdvice
- chain.get(2):AspectJAfterAdvice,用于在实际方法调用之后的处理
第45行~第50行的代码,如果拦截器列表为空,很正常,因为某个类/接口下的某个方法可能不满足expression的匹配规则,因此此时通过反射直接调用该方法。
第51行~第56行的代码,如果拦截器列表不为空,按照注释的意思,需要一个ReflectiveMethodInvocation,并通过proceed方法对原方法进行拦截,proceed方法感兴趣的朋友可以去看一下,里面使用到了递归的思想对chain中的Object进行了层层的调用。