深入Spring原理-5.aop代理

简介: 深入Spring原理-5.aop代理

编译器增强


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.mojo</groupId>
                <artifactId>aspectj-maven-plugin</artifactId>
                <version>1.14.0</version>
                <configuration>
                    <complianceLevel>1.8</complianceLevel>
                    <source>8</source>
                    <target>8</target>
                    <showWeaveInfo>true</showWeaveInfo>
                    <verbose>true</verbose>
                    <Xlint>ignore</Xlint>
                    <encoding>UTF-8</encoding>
                </configuration>
                <executions>
                    <execution>
                        <goals>
                            <!-- use this goal to weave all your main classes -->
                            <goal>compile</goal>
                            <!-- use this goal to weave all your test classes -->
                            <goal>test-compile</goal>
                        </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;
        });

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

目录
相关文章
|
2月前
|
缓存 Java 开发者
【Spring】原理:Bean的作用域与生命周期
本文将围绕 Spring Bean 的作用域与生命周期展开深度剖析,系统梳理作用域的类型与应用场景、生命周期的关键阶段与扩展点,并结合实际案例揭示其底层实现原理,为开发者提供从理论到实践的完整指导。
|
2月前
|
人工智能 Java 开发者
【Spring】原理解析:Spring Boot 自动配置
Spring Boot通过“约定优于配置”的设计理念,自动检测项目依赖并根据这些依赖自动装配相应的Bean,从而解放开发者从繁琐的配置工作中解脱出来,专注于业务逻辑实现。
|
2月前
|
XML 安全 Java
使用 Spring 的 @Aspect 和 @Pointcut 注解简化面向方面的编程 (AOP)
面向方面编程(AOP)通过分离横切关注点,如日志、安全和事务,提升代码模块化与可维护性。Spring 提供了对 AOP 的强大支持,核心注解 `@Aspect` 和 `@Pointcut` 使得定义切面与切入点变得简洁直观。`@Aspect` 标记切面类,集中处理通用逻辑;`@Pointcut` 则通过表达式定义通知的应用位置,提高代码可读性与复用性。二者结合,使开发者能清晰划分业务逻辑与辅助功能,简化维护并提升系统灵活性。Spring AOP 借助代理机制实现运行时织入,与 Spring 容器无缝集成,支持依赖注入与声明式配置,是构建清晰、高内聚应用的理想选择。
406 0
|
1月前
|
XML Java 数据格式
《深入理解Spring》:AOP面向切面编程深度解析
Spring AOP通过代理模式实现面向切面编程,将日志、事务等横切关注点与业务逻辑分离。支持注解、XML和编程式配置,提供五种通知类型及丰富切点表达式,助力构建高内聚、低耦合的可维护系统。
|
1月前
|
XML Java 测试技术
《深入理解Spring》:IoC容器核心原理与实战
Spring IoC通过控制反转与依赖注入实现对象间的解耦,由容器统一管理Bean的生命周期与依赖关系。支持XML、注解和Java配置三种方式,结合作用域、条件化配置与循环依赖处理等机制,提升应用的可维护性与可测试性,是现代Java开发的核心基石。
|
1月前
|
XML Java 应用服务中间件
【SpringBoot(一)】Spring的认知、容器功能讲解与自动装配原理的入门,带你熟悉Springboot中基本的注解使用
SpringBoot专栏开篇第一章,讲述认识SpringBoot、Bean容器功能的讲解、自动装配原理的入门,还有其他常用的Springboot注解!如果想要了解SpringBoot,那么就进来看看吧!
354 2
|
3月前
|
人工智能 监控 安全
Spring AOP切面编程颠覆传统!3大核心注解+5种通知类型,让业务代码纯净如初
本文介绍了AOP(面向切面编程)的基本概念、优势及其在Spring Boot中的使用。AOP作为OOP的补充,通过将横切关注点(如日志、安全、事务等)与业务逻辑分离,实现代码解耦,提升模块化程度、可维护性和灵活性。文章详细讲解了Spring AOP的核心概念,包括切面、切点、通知等,并提供了在Spring Boot中实现AOP的具体步骤和代码示例。此外,还列举了AOP在日志记录、性能监控、事务管理和安全控制等场景中的实际应用。通过本文,开发者可以快速掌握AOP编程思想及其实践技巧。
|
3月前
|
Java 关系型数据库 数据库
深度剖析【Spring】事务:万字详解,彻底掌握传播机制与事务原理
在Java开发中,Spring框架通过事务管理机制,帮我们轻松实现了这种“承诺”。它不仅封装了底层复杂的事务控制逻辑(比如手动开启、提交、回滚事务),还提供了灵活的配置方式,让开发者能专注于业务逻辑,而不用纠结于事务细节。
|
3月前
|
人工智能 监控 安全
如何快速上手【Spring AOP】?核心应用实战(上篇)
哈喽大家好吖~欢迎来到Spring AOP系列教程的上篇 - 应用篇。在本篇,我们将专注于Spring AOP的实际应用,通过具体的代码示例和场景分析,帮助大家掌握AOP的使用方法和技巧。而在后续的下篇中,我们将深入探讨Spring AOP的实现原理和底层机制。 AOP(Aspect-Oriented Programming,面向切面编程)是Spring框架中的核心特性之一,它能够帮助我们解决横切关注点(如日志记录、性能统计、安全控制、事务管理等)的问题,提高代码的模块化程度和复用性。
|
3月前
|
设计模式 Java 开发者
如何快速上手【Spring AOP】?从动态代理到源码剖析(下篇)
Spring AOP的实现本质上依赖于代理模式这一经典设计模式。代理模式通过引入代理对象作为目标对象的中间层,实现了对目标对象访问的控制与增强,其核心价值在于解耦核心业务逻辑与横切关注点。在框架设计中,这种模式广泛用于实现功能扩展(如远程调用、延迟加载)、行为拦截(如权限校验、异常处理)等场景,为系统提供了更高的灵活性和可维护性。
下一篇
oss云网关配置