Spring源码-5.aop代理

• 作者简介：大家好，我是爱吃芝士的土豆倪，24届校招生Java选手，很高兴认识大家
• 系列专栏：Spring源码、JUC源码
• 如果感觉博主的文章还不错的话，请三连支持一下博主哦
• 博主正在努力完成2023计划中：源码溯源，一探究竟
• 联系方式：nhs19990716，加我进群，大家一起学习，一起进步，一起对抗互联网寒冬

编译器增强

ConfigurableApplicationContext context = SpringApplication.run(A.class, args);
MyService service = context.getBean(MyService.class);

log.debug("service class: {}", service.getClass());
service.foo();

context.close();

@Service
public class MyService {

    private static final Logger log = LoggerFactory.getLogger(MyService.class);

    public static void foo() {
        log.debug("foo()");
    }
}

@Aspect // ⬅️注意此切面并未被 Spring 管理
public class MyAspect {

    private static final Logger log = LoggerFactory.getLogger(MyAspect.class);

    @Before("execution(* com.itheima.service.MyService.foo())")
    public void before() {
        log.debug("before()");
    }
}

当我们运行的时候，实际上，相当于foo方法就被代理增强了

输出：

before()
foo()

而看到 MyAspect类，其实并没有被Spring管理，但是还是能实现代理的能力，这是怎么回事呢？

这说明aop的实现不仅仅只有动态一种。

其实这里是使用aspectj编译器来进行的增强，编译器的原理其实就是把我们的myService类改写了

在编译好的target中可以看到，实际上foo方法是被编译器改写了的。

其父方法的class当中加入了前置增强，当目标文件都被改写了的时候，就不需要被代理了。

而前面所将的@aspect 其实和spring没什么关系，实现这个只需要在编译器中加入 aspectj-maven-plugin 插件

			<plugin>
                <groupId>org.codehaus.mojogroupId>
                <artifactId>aspectj-maven-pluginartifactId>
                <version>1.14.0version>
                <configuration>
                    <complianceLevel>1.8complianceLevel>
                    <source>8source>
                    <target>8target>
                    <showWeaveInfo>trueshowWeaveInfo>
                    <verbose>trueverbose>
                    <Xlint>ignoreXlint>
                    <encoding>UTF-8encoding>
                configuration>
                <executions>
                    <execution>
                        <goals>
                            
                            <goal>compilegoal>
                            
                            <goal>test-compilegoal>
                        goals>
                    execution>
                executions>
            plugin>

这种增强其实是有好处的，能够突破代理的限制，因为代理的增强其实是通过方法重写来实现的。

jdk是 实现了 接口，而cglib是重写了父方法，本质上都是重写

但是如果该方法是静态方法呢？那么其实是不能增强的，而我们的编译增强其实是可以做到的。

静态方法

动态代理无法直接代理静态方法，是因为静态方法是属于类级别的，而不是属于实例级别的。

在java中，动态代理是通过创建一个实现了特定接口的代理对象来实现的。由于静态方法不属于任何实例，所以无法通过动态代理来代理静态方法。

而我们的编译增强就可以对静态方法进行代理！

	public static void foo() {
        log.debug("foo()");
    }

如果 运行不能实现，需要先clean，然后重新运行。

构造方法

动态代理同样无法修改构造方法，因为构造方法是在对象创建时被调用的，而代理对象只能在对象创建后才能被创建。 在Java中，代理对象是通过调用java.lang.reflect.Proxy.newProxyInstance()方法来创建的，该方法需要一个接口列表作为参数，并使用这些接口来创建代理对象。由于构造方法是在对象创建时被调用的，因此代理对象无法修改构造方法。

以一段例子来解释：

public class Person {
    private String name;

    public Person(String name) {
        this.name = name;
    }
}

@Aspect
public class PersonAspect {
    @Before("execution(Person.new(String)) && args(name)")
    public void beforeConstruct(String name) {
        System.out.println("Creating a new person with name " + name);
    }
}

public class Test {
    public static void main(String[] args) {
        Person person = new Person("Alice");
    }
}

输出：

Creating a new person with name Alice

可以看到，编译增强也可以对构造方法增强。

类加载增强

在类加载阶段，是把你原始的字节码进行了一个增强

同理：

ConfigurableApplicationContext context = SpringApplication.run(A10.class, args);
        MyService service = context.getBean(MyService.class);

        // ⬇️MyService 并非代理, 但 foo 方法也被增强了, 做增强的 java agent, 在加载类时, 修改了 class 字节码
        log.debug("service class: {}", service.getClass());
        service.foo();
        
@Service
public class MyService {

    private static final Logger log = LoggerFactory.getLogger(MyService.class);

    final public void foo() {
        log.debug("foo()");
        this.bar();
    }

    public void bar() {
        log.debug("bar()");
    }
}

@Aspect // ⬅️注意此切面并未被 Spring 管理
public class MyAspect {

    private static final Logger log = LoggerFactory.getLogger(MyAspect.class);

    @Before("execution(* com.itheima.service.MyService.*())")
    public void before() {
        log.debug("before()");
    }


}

运行时需要在 VM options 里加入 -javaagent:C:/Users/manyh/.m2/repository/org/aspectj/aspectjweaver/1.9.7/aspectjweaver-1.9.7.jar
把其中 C:/Users/manyh/.m2/repository 改为你自己 maven 仓库起始地址

输出：

before
foo
before
bar

一个方法调用另一个方法

类加载阶段代理也突破了一个限制，就是 如果目标类中 在一个方法内调用了自己的另外的方法，内部的方法调用是不会走动态代理的增强的。

这是因为动态代理是基于接口或父类进行代理的，它是通过生成一个代理类来实现对目标类方法的代理。 当目标类内部调用自己的方法时，实际上是在目标类的内部方法中直接调用，而不经过代理类。**因此，动态代理无法拦截这种内部方法调用。（换一句话话说，动态代理是一种重写，无论jdk实现接口还是cglib重写父类，所以其内部方法的调用不经过代理类）

如果你需要在目标类的内部方法调用时也应用代理的增强逻辑，可以考虑将内部方法提取到一个独立的类中，并通过代理来调用该独立类的方法。 这样就能确保内部方法的调用也经过代理的增强。

类加载阶段代理是指在类加载的过程中，通过一些技术手段来替换原始类的定义，从而实现对原始类行为的控制和修改。在这个过程中，可以利用代理技术来使一个方法调用另一个方法被代理。

AOP实现之proxy

JdkProxy

public class JdkProxyDemo {

    interface Foo {
        void foo();
    }

    /**
     * 准备了一个代增强的目标类
     *
     * 这是一个静态代理
     */
    static class Target implements Foo {
        public void foo() {
            System.out.println("target foo");
        }
    }
}

以上实际上就是一个接口的实现类，实现了这个接口，如果将其进行增强呢？

接下来介绍jdk自带的一种代理方法 ， 但是其也有一个弊端，就是只能针对接口进行代理

首先介绍对应Proxy.newProxyInstance 方法的参数：

创建一个新的代理实例 一共有三个参数、第一个参数 是类加载器

类加载器可以用当前的类加载器，为什么需要一个类加载器呢？

其实我们的代理类 和 普通类是有差别的，普通类先写java源代码、然后编译成Java的字节码，最后经过类加载，然后可以使用。

而代理类没有源代码，是在运行期间直接生成了代理类的字节码，生成的字节码也需要加载后才可以运行。

所以类加载器的作用主要是用来加载运行期间动态生成的字节码。

参数二 就是你将来要生成的代码，要实现什么接口，这是个数组，也就代表着将来可以一次性实现多个接口

参数三 是一个 InvocationHandler 的接口，因为代理也创建出来了，也实现了我们的接口，接下来就是实现接口中的抽象方法
其中还有三个参数，分别代表 代理对象自己、正在执行的方法对象、方法传过来的实际参数

ClassLoader loader = JdkProxyDemo.class.getClassLoader();// 用来加载在运行期间动态生成的字节码

Foo proxy = (Foo) Proxy.newProxyInstance(loader, new Class[]{Foo.class}, (p, method, args) -> {
            System.out.println("before...");
            Object result = method.invoke(target, args);
            System.out.println("after....");
            return result; 
        });

至此一个jdk版本的动态代理其实也就讲解完成了

但是需要注意的一点就是 jdk 动态代理要求目标必须实现接口，生成的代理类实现相同接口，因此代理与目标之间是平级兄弟关系,所以哪怕将Target 改成final也没关系，因为不是子类（这个和cglib有很大的区别！！！）

System.out.println(proxy.getClass());

proxy.foo();

static final class Target implements Foo {
        public void foo() {
            System.out.println("target foo");
        }
    }

在接口代理中，代理对象实现了被代理接口，并且通过重写接口中的方法来实现增强逻辑。当调用代理对象的方法时，实际上是调用了代理对象中重写的方法，从而实现了增强功能。

CglibProxy

public class CglibProxyDemo {

    static class Target {
        public void foo() {
            System.out.println("target foo");
        }
    }
}

接下来介绍的这个CglibProxy 和 jdk的有很大的不同，前面提到的jdk代理其实是 平行关系，而 cglib是父子继承关系。

其中 Enhancer.create 方法共有两个参数

参数一 代理的父类
参数二 共有四个参数 代理类自己、代理类中的方法、参数、方法对象

Target proxy = (Target) Enhancer.create(Target.class, (MethodInterceptor) (p, method, args, methodProxy) -> {
            System.out.println("before...");
            Object result = method.invoke(target, args); // 用方法反射调用目标
            System.out.println("after...");
            return result;
        });

// 最后使用的时候，再转换成父类型

proxy.foo();

cglib 不要求目标实现接口，它生成的代理类是目标的子类，因此代理与目标之间是子父关系 限制⛔：根据上述分析 final 类无法被 cglib 增强。如果方法是final的话，也不能增强,因为是子父的关系，必然是通过方法重写来实现的，因为final是不能被继承 和 重写的。而jdk中是平级的兄弟关系

但是其实可以观察到，参数二还有四个参数，其中method 和 methodProxy很像，它们两个具体有什么不同呢？

//        Target target = new Target();

Target proxy = (Target) Enhancer.create(Target.class, (MethodInterceptor) (p, method, args, methodProxy) -> {
            System.out.println("before...");
//            Object result = method.invoke(target, args); // 用方法反射调用目标
            // methodProxy 它可以避免反射调用
//            Object result = methodProxy.invoke(target, args); // 内部没有用反射, 需要目标 （spring）
            Object result = methodProxy.invokeSuper(p, args); // 内部没有用反射, 需要代理
            System.out.println("after...");
            return result;
        });

具体如下，主要是内部需不需要反射的问题，更加详细的解释将会在后续文章中进行介绍。