上一节咱们在分析解析AOP标签的时候,第一步就是注册了一个类AspectJAwareAdvisorAutoProxyCreator
,咱们说它是AOP的入口类。为何这样说呢? 来看它父类的父类AbstractAutoProxyCreator
,它继承了BeanPostProcessor接口。 那么,有两个方法确定要被调用到postProcessBeforeInitialization、postProcessAfterInitialization
。一个在依赖注入完成以前调用,一个在以后调用。spring
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方法则是真正产生代理的地方,咱们先看下它的内部实现。bash
protected Object wrapIfNecessary(Object bean, String beanName, Object cacheKey) {
// Create proxy if we have advice.
//先看它的注释,大意说:若是有通知,就建立代理。
//其实就是在bean.getClass()找到全部的通知和advisor
//这里面其实又分为两个步骤:
//第一,在Bean工厂找到全部的Advisor 第二,根据beanClass和Pointcut去作匹配
Object[] specificInterceptors = getAdvicesAndAdvisorsForBean(bean.getClass(), beanName, null);
if (specificInterceptors != DO_NOT_PROXY) {
this.advisedBeans.put(cacheKey, Boolean.TRUE);
//真正建立代理并返回,这时候返回的就是代理类了,把真实的bean替换掉
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;
}
复制代码
看到上面的源码,整个过程就分为了两步,匹配和建立返回。这样就完成了代理类的替换,是否是有点偷梁换柱的感受。post
先是找到全部的Advisor,这个比较简单。由于咱们知道,在解析的时候就把配置的通知封装成advisor注册了进去。首先拿到beanDefinitionNames容器全部beanName,循环判断bean的类型是否是advisor接口的类型,符合条件返回。ui
public List<Advisor> findAdvisorBeans() {
// Determine list of advisor bean names, if not cached already.
String[] advisorNames = null;
//先拿到beanName
advisorNames = BeanFactoryUtils.beanNamesForTypeIncludingAncestors(
this.beanFactory, Advisor.class, true, false);
List<Advisor> advisors = new LinkedList<Advisor>();
for (String name : advisorNames) {
if (isEligibleBean(name)) {
try {
//再从Bean工厂中拿bean的实例
advisors.add(this.beanFactory.getBean(name, Advisor.class));
}
}
}
//返回的advisors就是配置文件中全部的advice和advisor
return advisors;
}
复制代码
找到advisors并未结束,还要跟pointcut作匹配,看这些advisor符不符合表达式条件。它最终调用到Pointcut的match方法。这个方法嵌套的太深,就不贴代码了,核心思想就是判断class和class对应的method是否与pointcut表达式匹配。this
通过上面查找匹配后,肯定当前的bean确实须要代理,就调用createProxy方法。lua
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);
//将beanClass上的接口设置到代理工厂
evaluateProxyInterfaces(beanClass, proxyFactory);
//设置Advisor到代理工厂
Advisor[] advisors = buildAdvisors(beanName, specificInterceptors);
for (Advisor advisor : advisors) {
proxyFactory.addAdvisor(advisor);
}
//设置目标对象
proxyFactory.setTargetSource(targetSource);
return proxyFactory.getProxy(this.proxyClassLoader);
}
复制代码
建立代理分为JDK的代理和Cglib的代理,这里咱们先关注JDK的代理。getProxy方法就调用到JdkDynamicAopProxy
类的方法。这个类还实现了InvocationHandler接口,说明它同时仍是调用处理程序。即在调用代理类的invoke方法时,实际上就会调用到JdkDynamicAopProxy.invoke()
。spa
public Object getProxy(ClassLoader classLoader) {
//这里又给代理工厂加了两个接口 SpringProxy和Advised
Class<?>[] proxiedInterfaces = AopProxyUtils.completeProxiedInterfaces(this.advised);
//这个方法就比较熟悉了,正是JDK动态代理的方法
//这里的this就是JdkDynamicAopProxy实例。
return Proxy.newProxyInstance(classLoader, proxiedInterfaces, this);
}
复制代码
在实例化Bean和完成依赖注入后,会判断当前的Bean是否须要代理,若是须要,就生成代理类把原始类替换掉。在业务方法里面调用的时候,就会调用到JdkDynamicAopProxy.invoke()
。debug
在执行invoke的时候,咱们又能够分为两个步骤...-_-||,是否是跟二颇有缘,每次都是两个步骤。。代理
首先从代理工厂中拿到全部的advisor,而后判断是否是PointcutAdvisor类型,其次先matches一下targetClass,再matches一下method,证实这个类的方法在pointcut范围内,加入interceptorList,最后返回。code
public List<Object> getInterceptorsAndDynamicInterceptionAdvice(
Advised config, Method method, Class<?> targetClass) {
List<Object> interceptorList = new ArrayList<Object>(config.getAdvisors().length);
//config就是代理工厂的实例
for (Advisor advisor : config.getAdvisors()) {
if (advisor instanceof PointcutAdvisor) {
PointcutAdvisor pointcutAdvisor = (PointcutAdvisor) advisor;
if (config.isPreFiltered() || pointcutAdvisor.getPointcut().getClassFilter().matches(targetClass)) {
MethodInterceptor[] interceptors = registry.getInterceptors(advisor);
MethodMatcher mm = pointcutAdvisor.getPointcut().getMethodMatcher();
if (MethodMatchers.matches(mm, method, targetClass, hasIntroductions)) {
interceptorList.addAll(Arrays.asList(interceptors));
}
}
}
}
return interceptorList;
}
复制代码
拿到方法的拦截链,而后调用。调用的时候有个地方比较有意思。它先建立了一个对象ReflectiveMethodInvocation
。这个对象有两个参数
currentInterceptorIndex //当前调用的拦截器的索引,默认值-1
interceptorsAndDynamicMethodMatchers //拦截器的列表
复制代码
而后看它的调用方法。
public Object proceed() throws Throwable {
//若是俩个变量相等,说明已经调用完了全部的拦截器
if (this.currentInterceptorIndex == this.interceptorsAndDynamicMethodMatchers.size() - 1) {
//执行被代理方法
return invokeJoinpoint();
}
//从-1开始,每次累加1。interceptorOrInterceptionAdvice就是对应的每个通知
//好比before、after、after-returning...
//对应的实例类分别是:
//MethodBeforeAdviceInterceptor、AspectJAfterAdvice、AfterReturningAdviceInterceptor
Object interceptorOrInterceptionAdvice =
this.interceptorsAndDynamicMethodMatchers.get(++this.currentInterceptorIndex);
//在调用具体通知的invoke方法时,把当前对象当参数传了过去。
//由于在具体的通知执行以后还要回调回来,执行当前对象的proceed().
//这样就造成了一个通知调用链,当全部的通知执行完毕,调用上面的invokeJoinpoint()
return ((MethodInterceptor) interceptorOrInterceptionAdvice).invoke(this);
}
复制代码
看完它的调用流程,咱们还有一个疑问。通知一共有5种类型,前置通知、后置通知、方法返回后通知、环绕通知、异常通知。那么,它是怎么保证调用顺序的呢? 咱们来看两个通知类里面具体的实现。
public Object invoke(MethodInvocation mi) throws Throwable {
//这个比较简单,执行完before就回调
this.advice.before(mi.getMethod(), mi.getArguments(), mi.getThis() );
return mi.proceed();
}
复制代码
public Object invoke(MethodInvocation mi) throws Throwable {
//这个就比较有趣了,它先执行回调
//经过finally机制再执行本身的通知方法
try {
return mi.proceed();
}
finally {
invokeAdviceMethod(getJoinPointMatch(), null, null);
}
}
复制代码
//环绕通知会调用到切面类的自定义方法
public Object aroundAdvice(ProceedingJoinPoint joinPoint) throws Throwable {
System.out.println("环绕通知以前");
//能够本身判断还要不要回调回去。
//回调回去的话,接着循环调用链
//若是再也不回调,就要看链的顺序了,在它以后的就再也不执行
Object result = joinPoint.proceed();
System.out.println("环绕通知以后");
return result;
}
复制代码
若是想使用注解AOP,须要开启一个配置。<aop:aspectj-autoproxy />
。Spring解析配置标签的时候,调用到AspectJAutoProxyBeanDefinitionParser.parse()
。 这个方法主要就干了一件事:注册入口类AnnotationAwareAspectJAutoProxyCreator
。 XML配置方式的AOP,Spring注册的入口类叫作AspectJAwareAdvisorAutoProxyCreator
。
它们的调用流程是同样的,都是在实例化以后调用爷爷类的AbstractAutoProxyCreator.postProcessAfterInitialization()
。回忆一下,wrapIfNecessary方法是真正产生代理的地方。它先获取全部的通知并与当前的bean class匹配,若是有,就说明当前的Bean须要代理,则产生代理类。咱们知道,在XML配置方式的AOP中,Spring把配置的通知都封装成advisor注册到容器里,因此在获取的时候,直接在Bean工厂中匹配Advisor类型的Bean就行。 可是,在解析注解AOP的时候,咱们看到它只是注册了一个入口类而已呀,并无注册advisor,那么,在这里怎么获取呢?
目光回到查询advisor的方法。
protected List<Advisor> findCandidateAdvisors() {
// Add all the Spring advisors found according to superclass rules.
// 这个是查询XML配置方式的advoisor
List<Advisor> advisors = super.findCandidateAdvisors();
// Build Advisors for all AspectJ aspects in the bean factory.
// 这个就是查询注解方式的advisor
advisors.addAll(this.aspectJAdvisorsBuilder.buildAspectJAdvisors());
return advisors;
}
复制代码
在buildAspectJAdvisors
方法查询advisor的时候,它大体能够分3个步骤。
String[] beanNames = BeanFactoryUtils.beanNamesForTypeIncludingAncestors(this.beanFactory, Object.class, true, false);
for (String beanName : beanNames) {
Class<?> beanType = this.beanFactory.getType(beanName);
if (this.advisorFactory.isAspect(beanType)) {
aspectNames.add(beanName);
......
}
}
复制代码
先拿到Class对象上的全部Method对象,根据Method对象的Annotation类型,返回不一样的Advice对象。这个跟XML方式返回的Advice对象是同样的。
switch (aspectJAnnotation.getAnnotationType()) {
case AtBefore:
springAdvice = new AspectJMethodBeforeAdvice(candidateAdviceMethod, ajexp, aif);
break;
case AtAfter:
springAdvice = new AspectJAfterAdvice(candidateAdviceMethod, ajexp, aif);
break;
case AtAfterReturning:
springAdvice = new AspectJAfterReturningAdvice(candidateAdviceMethod, ajexp, aif);
AfterReturning afterReturningAnnotation = (AfterReturning) aspectJAnnotation.getAnnotation();
if (StringUtils.hasText(afterReturningAnnotation.returning())) {
springAdvice.setReturningName(afterReturningAnnotation.returning());
}
break;
case AtAfterThrowing:
springAdvice = new AspectJAfterThrowingAdvice(candidateAdviceMethod, ajexp, aif);
AfterThrowing afterThrowingAnnotation = (AfterThrowing) aspectJAnnotation.getAnnotation();
if (StringUtils.hasText(afterThrowingAnnotation.throwing())) {
springAdvice.setThrowingName(afterThrowingAnnotation.throwing());
}
break;
case AtAround:
springAdvice = new AspectJAroundAdvice(candidateAdviceMethod, ajexp, aif);
break;
case AtPointcut:
if (logger.isDebugEnabled()) {
logger.debug("Processing pointcut '" + candidateAdviceMethod.getName() + "'");
}
return null;
default:
throw new UnsupportedOperationException(
"Unsupported advice type on method " + candidateAdviceMethod);
}
复制代码
最后将advice和pointcut封装成InstantiationModelAwarePointcutAdvisorImpl对象返回。返回以后,建立代理类进行替换。
由此看来,注解方式的AOP,是在查询Advisors的时候才去解析并生成的,其余的与XML的配置方式处理流程都是同样的。
本章节咱们重点阐述了3个问题。即怎样产生代理类、代理类的执行过程、AnnotationAOP的处理流程。结合本章节和上一章节的内容,可能使咱们对Spring AOP的内部处理流程加深了印象。
怎样产生代理类? 经过循环beanNames实例化Bean对象,判断此对象是否与pointcut表达式匹配。若是匹配就根据advice生成不一样的advisor对象,而后调用JDK或者CGLIB的方法生成代理类返回。
代理类执行 调用JDK或者CGLIB的invoke方法,查询advisor的调用链。链式调用,根据通知类型调用不一样的advice实现加强。