Spring AOP源码分析（八）SpringAOP要注意的地方

SpringAOP要注意的地方有很多，下面就举一个，之后想到了再列出来： 
（1）SpringAOP对于最外层的函数只拦截public方法，不拦截protected和private方法，另外不会对最外层的public方法内部调用的其他方法也进行拦截，即只停留于代理对象所调用的方法。如下案例： 
B类有两个public方法，foo1（）和foo2(),foo1内部调用了foo2，简单如下： 

?


1

2

3

4

5

6

7

8

public void foo2() { 

        System.out.println("foo2"); 

    } 

     

    public void foo1(){

        System.out.println("foo1");

        this.foo2();

    }

假如都对这两个方法进行拦截。当你调用,B对象.foo1()仅仅对foo1整个方法拦截，对于它内部调用的foo2()方法不会进行拦截。 
源码分析： 
判断上述this.foo2()方法是否被拦截的最本质的东西是看this到底是谁？有如下对象B类的对象b,和cglib生成的代理对象bProxy，代理对象bProxy内部拥有b。如果调用b对象的任何方法，肯定不会发生任何拦截，当调用bProxy的方法则都会进入拦截函数。 

当我们调用bProxy对象的foo1()方法时，先执行cglib之前设置的callback对象的intercept拦截函数，如下： 

?


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

public Object intercept(Object proxy, Method method, Object[] args, MethodProxy methodProxy) throws Throwable {

            Object oldProxy = null;

            boolean setProxyContext = false;

            Class<?> targetClass = null;

            Object target = null;

            try {

                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 = getTarget();

                if (target != null) {

                    targetClass = target.getClass();

                }

                List<Object> chain = this.advised.getInterceptorsAndDynamicInterceptionAdvice(method, targetClass);

                Object retVal;

                // Check whether we only have one InvokerInterceptor: that is,

                // no real advice, but just reflective invocation of the target.

                if (chain.isEmpty() && Modifier.isPublic(method.getModifiers())) {

                    // 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 = methodProxy.invoke(target, args);

                }

                else {

                    // We need to create a method invocation...

                    retVal = new CglibMethodInvocation(proxy, target, method, args, targetClass, chain, methodProxy).proceed();

                }

                retVal = processReturnType(proxy, target, method, retVal);

                return retVal;

            }

            finally {

                if (target != null) {

                    releaseTarget(target);

                }

                if (setProxyContext) {

                    // Restore old proxy.

                    AopContext.setCurrentProxy(oldProxy);

                }

            }

        }

这个过程之前的文章已经分析过，这里就是首先取出拦截器链List<Object> chain，当foo1方法不符合我们所配置的pointcut时，拦截器链必然为空,然后就是直接执行目标对象的方法。 
当foo1方法符合所配置的pointcut时，拦截器链不为空，执行相应的通知advice，currentInterceptorIndex 从-1开始，如下： 

?


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

public Object proceed() throws Throwable {

        //  We start with an index of -1 and increment early.

        if (this.currentInterceptorIndex == this.interceptorsAndDynamicMethodMatchers.size() - 1) {

            return invokeJoinpoint();

        }

 

        Object interceptorOrInterceptionAdvice =

                this.interceptorsAndDynamicMethodMatchers.get(++this.currentInterceptorIndex);

        if (interceptorOrInterceptionAdvice instanceof InterceptorAndDynamicMethodMatcher) {

            // Evaluate dynamic method matcher here: static part will already have

            // been evaluated and found to match.

            InterceptorAndDynamicMethodMatcher dm =

                    (InterceptorAndDynamicMethodMatcher) interceptorOrInterceptionAdvice;

            if (dm.methodMatcher.matches(this.method, this.targetClass, this.arguments)) {

                return dm.interceptor.invoke(this);

            }

            else {

                // Dynamic matching failed.

                // Skip this interceptor and invoke the next in the chain.

                return proceed();

            }

        }

        else {

            // It's an interceptor, so we just invoke it: The pointcut will have

            // been evaluated statically before this object was constructed.

            return ((MethodInterceptor) interceptorOrInterceptionAdvice).invoke(this);

        }

    }

随着通知不断的传递执行，最终this.currentInterceptorIndex == this.interceptorsAndDynamicMethodMatchers.size() - 1将会满足条件，将会来到执行目标对象的方法invokeJoinpoint()： 

?


1

2

3

4

5

6

7

8

protected Object invokeJoinpoint() throws Throwable {

            if (this.publicMethod) {

                return this.methodProxy.invoke(this.target, this.arguments);

            }

            else {

                return super.invokeJoinpoint();

            }

        }

在这里不管要拦截的目标方法是不是public方法，最终所传递的对象都是this.target，他是目标对象而不是代理对象，即执行上述foo1()函数的对象是目标对象而不是代理对象，所以它内部所调用的this.foo2()也是目标对象,因此不会发生拦截，如果是执行的是代理对象.foo2（）则必然会进入intercept拦截过程。所以上述调用foo1函数，其内部调用的foo2函数是不会发生拦截的，因为this指的是目标对象，不是代理对象。 

如果你想实现foo1调用时内部的foo2也进行拦截，就必须把this换成代理对象。这时就要用到了，xml配置中的expose-proxy="true",即暴露出代理对象，它使用的是ThreadLocal设计模式，我们可以这样获取代理对象,AopContext.currentProxy()就是代理对象，然后转换成目标对象或者目标接口，执行相应的方法： 

?


1

2

3

4

5

public void foo1(){

        System.out.println("run foo1");

        BServiceImpl proxy=(BServiceImpl) AopContext.currentProxy();

        proxy.foo2();

    }

最后再给出Spring的文档说明： 
Due to the proxy-based nature of Spring’s AOP framework, protected methods are by definition not intercepted, neither for JDK proxies (where this isn’t applicable) nor for CGLIB proxies (where this is technically possible but not recommendable for AOP purposes). As a consequence, any given pointcut will be matched against public methods only! 

If your interception needs include protected/private methods or even constructors, consider the use of Spring-driven native AspectJ weaving instead of Spring’s proxy-based AOP framework. This constitutes a different mode of AOP usage with different characteristics, so be sure to make yourself familiar with weaving first before making a decision. 

时间： 2024-02-19 14:41:15

Spring AOP源码分析（八）SpringAOP要注意的地方的相关文章

Spring AOP源码分析（七）ProxyFactoryBean介绍

这篇文章里面就要说说Spring自己的AOP,搞清楚哪种方式是Spring自己实现的AOP,哪种方式是Spring引入aspectj的AOP.  Spring自己的AOP实现在于ProxyFactoryBean.先看下使用案例(仍和之前的案例是一样的):接口AService.实现类AServiceImpl.通知MyBeforeAdvice  ? 1 2 3 4 5 6 public interface AService {       public void fooA(String _msg);

Spring AOP源码分析（一）AOP介绍和aspectj、SpringAOP入门

首先说说三个名词,面向对象.面向接口编程.面向切面编程(Aspect Oriented Programming 即AOP).  针对java来说  面向对象:是对现实世界的描述,是后两者的基础,大前提.  面向接口编程:接口就是一组规则的集合,这组规则可以有不同的实现方式.如JDBC,它本身仅仅是接口规范,不同的数据库有不同的实现,我们通过JDBC这样的接口编程,就无需关心我们使用的是哪种数据库,可以方便的实现数据库的切换而不必改动代码.  面向切面编程:是对面向对象的补充,主要应用的场景为: 

Spring AOP源码分析（四）Spring AOP的JDK动态代理

本篇文章将会介绍上一个例子中的源码执行情况,从中熟悉整个SpringAOP的一些概念和接口设计.  首先整个SpringAOP的分两大过程.  第一个过程:根据xml文件或者注解中配置的拦截信息,生成相应的代理对象,这个代理对象包含了对应的拦截器.  第二个过程:执行所拦截的方法时,就是调用代理对象的执行逻辑,完成各种拦截.  本文章先对第二个过程进行源码解析.  对第一个过程先做简单概述,如果拦截的类的对应方法是接口方法,则使用JDK的Proxy进行代理对象的创建否则使用CGLIB进行代理对象

Spring AOP源码分析（五）Spring AOP的Cglib代理

上一篇文章介绍了Spring AOP的JDK动态代理的过程,这一篇文章就要介绍下Spring AOP的Cglib代理过程,仍然是使用上一篇文章的工程案例.  JDK动态代理是由JdkDynamicAopProxy来生成代理对象的,Cglib则是由CglibAopProxy来生成代理对象的.JdkDynamicAopProxy.CglibAopProxy实现了AopProxy接口,如下:  ? 1 2 3 4 5 6 7 public interface AopProxy {       Obje

Spring AOP源码分析（三）Spring AOP中的一些基本接口及其概念

本文章对一些SpringAOP的接口设计进行下介绍,主要是区分三者的关系,AOP联盟.Aspectj.SpringAOP所做的工作.  主要内容:  (1)Advice接口设计  (2)MethodInterceptor接口设计  (3)Advisor和Pointcut接口设计  第一个:Advice接口设计  Advice:AOP联盟定义的通知接口,即拦截到相应的方法后执行的动作.  先看下它的类图:    (1)BeforeAdvice.AfterAdvice:SpringAOP自定义的通知

Spring AOP源码分析（二）JDK动态代理和CGLIB介绍

本篇是介绍java实现代理对象的两种方法,JDK动态代理和CGLIB.  JDK动态代理:针对你所调用的方法是接口所定义的方法.动态的创建一个类,通过实现目标类的接口来实现代理.  CGLIB:没有限制.通过继承目标类来创建代理类,实现代理.  下面看案例:  案例一,JDK动态代理:  Person和Animals都实现了Say接口sayHello方法.现在就需要对他们的sayHello方法进行拦截.  Say接口如下:  ? 1 2 3 4 public interface Say {  

Spring事务源码分析（一）Spring事务入门

有时为了保证一些操作要么都成功,要么都失败,这就需要事务来保证.  传统的jdbc事务如下:  ? 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 @Test     public void testAdd(){         Connection con=null;         try {             con=DriverManager.getConnection(url , username

spring cloud源码分析-zuul路由的部分源码解析

版本:spring-boot:1.5.3.RELEASE:spring cloud:Dalston.RELEASE(1.3.0.RELEASE) 路由定位器 配置所在jar包:spring-cloud-netflix-core-1.3.0.RELEASE.jar 顶层接口:RouteLocator 可刷新的路由:RefreshableRouteLocator extends RouteLocator 路由处理器:CompositeRouteLocator implements Refreshab

Spring Actuator源码分析

Actuator Endpoint Actuator模块通过Endpoint暴露一些接口,可以是Rest方式,也可以是JMX等其他方式. 如果使用Rest方式,通常SpringMVC是使用@RequestMapping,以及@Controller标注一个控制器方法,如果不使用SpringMVC,即没引入SpringMVC的包,那么Springboot就会出错.所以为了不走正常的SpringMVC机制,Actuator用EndpointHandlerMapping重写了RequestMapping