一、AOP 的本质：代理与织入

要理解 AOP 的底层，首先要抓住两个核心概念：代理和织入。

代理，是 AOP 最根本的实现手段。它不修改你的原始代码，而是在你和目标对象之间插入一个"中间商"。所有对目标对象的调用，都必须先经过这个中间商。中间商在转发请求之前或之后，执行额外的逻辑——这就是增强。

织入，则是将增强逻辑插入到目标代码中的过程。根据发生时机不同，织入分为三种：编译期织入、类加载期织入、运行期织入。Spring AOP 采用的是运行期织入，而 AspectJ 则提供了更全面的织入能力。

理解了这两个概念，就能看清 AOP 底层的三条技术路线：JDK 动态代理、CGLIB 字节码生成、AspectJ 字节码增强。

二、JDK 动态代理：反射的艺术

JDK 动态代理是 AOP 最基础的实现方式，它完全依赖 Java 反射机制，不需要引入任何第三方库。

其核心类是 java.lang.reflect.Proxy。当你调用 Proxy.newProxyInstance() 时，JVM 会在运行时动态生成一个新的类。这个新类实现了目标对象的所有接口，并且将所有方法调用都委托给一个 InvocationHandler 实例。

InvocationHandler 的 invoke 方法是整个机制的心脏。当代理对象的某个方法被调用时，invoke 方法会接收到三个参数：代理对象自身、被调用的方法对象、方法参数。在这个方法内部，你可以决定是否执行增强逻辑，然后通过反射调用目标对象的真实方法。

这种方式的优势在于：它是 Java 原生支持的，不需要额外依赖，生成代理的速度也很快。但它有一个硬性限制——目标类必须实现至少一个接口。如果一个类没有实现任何接口，JDK 动态代理就无能为力了。

从性能角度看，JDK 动态代理在创建代理对象时速度较快，因为它不需要操作字节码。但在方法调用时，由于每次都要经过反射层，调用开销会比直接调用大不少。

三、CGLIB 字节码生成：继承的力量

当目标类没有实现接口时，CGLIB 登场了。

CGLIB（Code Generation Library）的实现思路与 JDK 动态代理截然不同。它不是通过实现接口来代理，而是通过生成目标类的子类来实现代理。这个子类重写了父类的所有非 final 方法，在重写的方法中插入增强逻辑，然后调用父类的原始方法。

CGLIB 的核心类是 Enhancer。使用时，你需要设置父类和一个 Callback 回调。Enhancer 会在运行时通过 ASM 框架生成目标类的子类字节码，然后通过自定义类加载器加载这个子类，最终创建出代理对象。

这里的关键技术是 ASM——一个直接操作字节码的框架。ASM 可以在不生成完整类结构的情况下，以流式方式逐条修改字节码指令。CGLIB 正是借助 ASM，在目标方法的开头插入增强逻辑的字节码指令，在方法结尾插入调用父类方法的指令。

CGLIB 的优势很明显：不要求目标类实现接口，几乎可以代理任何类。但它也有代价：创建代理对象时需要生成字节码，速度比 JDK 动态代理慢；而且由于是基于继承，目标类和目标方法都不能是 final 的，否则无法生成子类或重写方法。

从方法调用性能来看，CGLIB 反而优于 JDK 动态代理。因为子类方法是直接调用，不需要经过反射层。所以在调用频繁的场景下，CGLIB 的整体表现往往更好。

四、字节码增强：更底层的控制力

如果说动态代理是在"外部"包了一层壳，那么字节码增强就是直接在"内部"动手术。

字节码增强技术允许在类加载之前或之后，直接修改类的字节码结构。常见的字节码操作框架有 ASM、Javassist 和 Byte Buddy。

ASM 是最底层、最高效的字节码操作框架。它提供了两种 API：Core API 和 Tree API。Core API 类似于 SAX 解析 XML，以流式方式逐条处理字节码指令，内存占用小但编程难度高。Tree API 类似于 DOM，将整个类结构加载到内存中形成树形结构，编程简单但消耗内存。在 AOP 场景中，通常使用 Core API，因为性能更优。

Javassist 则走了另一条路。它不直接操作字节码，而是提供了一套高级 API，让你用类似 Java 语法的方式来修改类。虽然性能不如 ASM，但上手难度低很多。

Byte Buddy 是近年来崛起的新一代字节码操作库，它在性能和易用性之间取得了很好的平衡，Spring 近年来也在逐步将底层字节码操作从 CGLIB 迁移到 Byte Buddy。

字节码增强的威力在于：它不受代理模式的限制。动态代理只能增强方法调用，而字节码增强可以修改字段、拦截构造方法、甚至修改类的结构。这也是 AspectJ 比 Spring AOP 功能更全面的根本原因。

五、AspectJ：编译期与类加载期的织入

AspectJ 是 AOP 领域的"重武器"。与 Spring AOP 的运行期织入不同，AspectJ 支持编译期织入和类加载期织入。

编译期织入：在 Java 源码编译成字节码的阶段，AspectJ 编译器（ajc）就会将切面逻辑直接写入目标类的字节码中。这意味着生成的字节码已经包含了增强逻辑，运行时没有任何性能开销。但代价是编译过程变复杂了，需要引入专门的编译器插件。

类加载期织入（LTW）：在类被加载到 JVM 之前，通过 Java Agent 机制修改字节码。这种方式不需要特殊的编译器，只需在 JVM 启动参数中指定 agent jar 包即可。它在灵活性和性能之间取得了折中。

AspectJ 的切点表达式也比 Spring AOP 强大得多。Spring AOP 仅支持方法执行这一种连接点，而 AspectJ 可以拦截字段访问、构造方法调用、异常抛出等多种场景。这使得 AspectJ 在某些对性能要求极高或需要精细控制的场景中不可替代。

但 AspectJ 的侵入性也更高。它需要学习一套独立的语法和配置方式，不像 Spring AOP 那样只需要几个注解就能搞定。

六、Spring AOP 的决策逻辑

回到日常开发中最常接触的 Spring AOP，它的底层是如何选择代理方式的？

Spring 通过 DefaultAopProxyFactory 来做决策。核心判断逻辑如下：如果目标类实现了接口，默认使用 JDK 动态代理；如果没有实现接口，或者通过配置强制指定，则使用 CGLIB。

具体来说，createAopProxy 方法会检查三个条件：是否开启了强制使用 CGLIB 的配置、目标类是否实现了接口、是否存在用户自定义的代理接口。如果满足任一条件，就创建 CGLIB 代理；否则创建 JDK 动态代理。

在拦截器链的执行上，Spring 使用了责任链模式。所有通知（Before、After、Around 等）被统一转换为 MethodInterceptor，按照顺序组成一条拦截器链。当调用代理对象的方法时，会依次经过这条链上的每一个拦截器，每个拦截器决定是否执行增强逻辑以及是否继续向下传递。

环绕通知是这条链的驱动核心。它拥有完全的控制权——可以选择不执行目标方法，可以修改参数，可以替换返回值。其他类型的通知都是在环绕通知的框架内被动执行的。

七、三条路线的终极对比

从实现机制看，JDK 动态代理基于接口和反射，CGLIB 基于继承和字节码生成，AspectJ 基于字节码增强。三者并非替代关系，而是各有适用场景。

从性能维度看：创建代理对象时，JDK 动态代理最快，CGLIB 最慢；方法调用时，CGLIB 最快，JDK 动态代理因反射调用而较慢；AspectJ 的编译期织入在运行时零开销，类加载期织入略有损耗。

从能力维度看：JDK 动态代理只能代理接口方法；CGLIB 可以代理普通类但不能处理 final 方法；AspectJ 几乎无所不能，包括构造方法、字段访问都能拦截。

从侵入性看：Spring AOP 几乎零侵入，只需加注解；AspectJ 需要专门的编译器或 agent 配置，侵入性更高。

八、写在最后

AOP 的底层世界，本质上是一场关于"如何在不修改原始代码的前提下改变程序行为"的技术探索。从 JDK 动态代理的反射之美，到 CGLIB 的字节码生成之巧，再到 AspectJ 的编译期织入之深，每一条技术路线都在性能、能力和易用性之间做出了不同的取舍。

作为开发工程师，理解这些底层原理不是为了造轮子，而是为了在遇到代理失效、切面不生效、性能瓶颈等问题时，能够迅速定位根源。知道刀是怎么磨的，才能在关键时刻让它砍得更准。