与 AspectJ 相同的是，Spring AOP 同样需要对目标类进行增强，也就是生成新的 AOP 代理类；与 AspectJ 不同的是，Spring AOP 无需使用任何特殊
命令对 Java 源代码进行编译，它采用运行时动态地、在内存中临时生成“代理类”的方式来生成 AOP 代理。
Spring 允许使用 AspectJ Annotation 用于定义方面（Aspect）、切入点（Pointcut）和增强处理（Advice），Spring 框架则可识别并根据这些
Annotation 来生成 AOP 代理。Spring 只是使用了和 AspectJ 5 一样的注解，但并没有使用 AspectJ 的编译器或者织入器（Weaver），底层依然使用
的是 Spring AOP，依然是在运行时动态生成 AOP 代理，并不依赖于 AspectJ 的编译器或者织入器。
简单地说，Spring 依然采用运行时生成动态代理的方式来增强目标对象，所以它不需要增加额外的编译，也不需要 AspectJ 的织入器支持；而 AspectJ
在采用编译时增强，所以 AspectJ 需要使用自己的编译器来编译 Java 文件，还需要织入器。
为了启用 Spring 对 @AspectJ 方面配置的支持，并保证 Spring 容器中的目标 Bean 被一个或多个方面自动增强，必须在 Spring 配置文件中配置如下
片段：
<?xml version="1.0" encoding="GBK"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:aop="http://www.springframework.org/schema/aop"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
http://www.springframework.org/schema/aop http://www.springframework.org/schema/aop/spring-aop-3.0.xsd">
<!-- 启动 @AspectJ 支持 -->
<aop:aspectj-autoproxy/>
</beans>
当然，如果我们希望完全启动 Spring 的“零配置”功能，则还需要启用 Spring 的“零配置”支持，让 Spring 自动搜索指定路径下 Bean 类。
所谓自动增强，指的是 Spring 会判断一个或多个方面是否需要对指定 Bean 进行增强，并据此自动生成相应的代理，从而使得增强处理在合适的时候
被调用。
如果不打算使用 Spring 的 XML Schema 配置方式，则应该在 Spring 配置文件中增加如下片段来启用 @AspectJ 支持。
<!-- 启动 @AspectJ 支持 --> <bean class="org.springframework.aop.aspectj.annotation.AnnotationAwareAspectJAutoProxyCreator"/>
上面配置文件中的 AnnotationAwareAspectJAutoProxyCreator 是一个 Bean 后处理器（BeanPostProcessor），该 Bean 后处理器将会为容器中
Bean 生成 AOP 代理，
当启动了 @AspectJ 支持后，只要我们在 Spring 容器中配置一个带 @Aspect 注释的 Bean，Spring 将会自动识别该 Bean，并将该Bean 作为方面
Bean 处理。
在 Spring 容器中配置方面 Bean（即带 @Aspect 注释的 Bean），与配置普通 Bean 没有任何区别，一样使用 <bean.../> 元素进行配置，一样支持使
用依赖注入来配置属性值；如果我们启动了 Spring 的“零配置”特性，一样可以让 Spring 自动搜索，并装载指定路径下的方面 Bean。
使用 @Aspect 标注一个 Java 类，该 Java 类将会作为方面 Bean，如下面代码片段所示：
// 使用 @Aspect 定义一个方面类
@Aspect
public class LogAspect {
// 定义该类的其他内容
...
}
方面类（用 @Aspect 修饰的类）和其他类一样可以有方法、属性定义，还可能包括切入点、增强处理定义。
当我们使用 @Aspect 来修饰一个 Java 类之后，Spring 将不会把该 Bean 当成组件 Bean 处理，因此负责自动增强的后处理 Bean 将会略过该 Bean，
不会对该 Bean 进行任何增强处理。
开发时无须担心使用 @Aspect 定义的方面类被增强处理，当 Spring 容器检测到某个 Bean 类使用了 @Aspect 标注之后，Spring 容器不会对该 Bean
类进行增强。
下面将会考虑采用 Spring AOP 来改写前面介绍的例子：
下面例子使用一个简单的 Chinese 类来模拟业务逻辑组件：
@Component
public class Chinese {
// 实现 Person 接口的 sayHello() 方法
public String sayHello(String name) {
System.out.println("-- 正在执行 sayHello 方法 --");
// 返回简单的字符串
return name + " Hello , Spring AOP";
}
// 定义一个 eat() 方法
public void eat(String food) {
System.out.println("我正在吃 :"+ food);
}
}
提供了上面 Chinese 类之后，接下来假设同样需要为上面 Chinese 类的每个方法增加事务控制、日志记录，此时可以考虑使用 Around、
AfterReturning 两种增强处理。
先看 AfterReturning 增强处理代码。
// 定义一个方面
@Aspect
public class AfterReturningAdviceTest {
// 匹配 org.crazyit.app.service.impl 包下所有类的、
// 所有方法的执行作为切入点
@AfterReturning(returning="rvt",pointcut="execution(* org.crazyit.app.service.impl.*.*(..))")
public void log(Object rvt) {
System.out.println("获取目标方法返回值 :" + rvt);
System.out.println("模拟记录日志功能 ...");
}
}
上面 Aspect 类使用了 @Aspect 修饰，这样 Spring 会将它当成一个方面 Bean 进行处理。其中程序中粗体字代码指定将会在调用
org.crazyit.app.service.impl 包下的所有类的所有方法之后织入 log(Object rvt) 方法。
再看 Around 增强处理代码：
// 定义一个方面
@Aspect
public class AroundAdviceTest {
// 匹配 org.crazyit.app.service.impl 包下所有类的、
// 所有方法的执行作为切入点
@Around("execution(* org.crazyit.app.service.impl.*.*(..))")
public Object processTx(ProceedingJoinPoint jp) throws java.lang.Throwable {
System.out.println("执行目标方法之前，模拟开始事务 ...");
// 执行目标方法，并保存目标方法执行后的返回值
Object rvt = jp.proceed(new String[]{"被改变的参数"});
System.out.println("执行目标方法之后，模拟结束事务 ...");
return rvt + " 新增的内容";
}
}
与前面的 AfterReturning 增强处理类似的，此处同样使用了 @Aspect 来修饰前面 Bean，其中粗体字代码指定在调用
org.crazyit.app.service.impl 包下的所有类的所有方法的“前后（Around）” 织入 processTx(ProceedingJoinPoint jp) 方法
需要指出的是，虽然此处只介绍了 Spring AOP 的 AfterReturning、Around 两种增强处理，但实际上 Spring 还支持 Before、After、
AfterThrowing 等增强处理，关于 Spring AOP 编程更多、更细致的编程细节，可以参考《轻量级 Java EE 企业应用实战》一书。
本示例采用了 Spring 的零配置来开启 Spring AOP，因此上面 Chinese 类使用了 @Component 修饰，而方面 Bean 则使用了@Aspect 修饰，方面
Bean 中的 Advice 则分别使用了 @AfterReturning、@Around 修饰。接下来只要为 Spring 提供如下配置文件即可：
<?xml version="1.0" encoding="GBK"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:context="http://www.springframework.org/schema/context"
xmlns:aop="http://www.springframework.org/schema/aop"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-3.0.xsd
http://www.springframework.org/schema/aop http://www.springframework.org/schema/aop/spring-aop-3.0.xsd">
<!-- 指定自动搜索 Bean 组件、自动搜索方面类 -->
<context:component-scan base-package="org.crazyit.app.service ,org.crazyit.app.advice">
<context:include-filter type="annotation" expression="org.aspectj.lang.annotation.Aspect"/>
</context:component-scan>
<!-- 启动 @AspectJ 支持 -->
<aop:aspectj-autoproxy/>
</beans>
接下来按传统方式来获取 Spring 容器中 chinese Bean、并调用该 Bean 的两个方法，程序代码如下：
public class BeanTest {
public static void main(String[] args) {
// 创建 Spring 容器
ApplicationContext ctx = new ClassPathXmlApplicationContext("bean.xml");
Chinese p = ctx.getBean("chinese" ,Chinese.class);
System.out.println(p.sayHello("张三"));
p.eat("西瓜");
}
}
从上面开发过程可以看出，对于 Spring AOP 而言，开发者提供的业务组件、方面 Bean 并没有任何特别的地方。只是方面 Bean 需要使用 @Aspect
修饰即可。程序不需要使用特别的编译器、织入器进行处理。
运行上面程序，将可以看到如下执行结果：
执行目标方法之前，模拟开始事务 ... -- 正在执行 sayHello 方法 -- 执行目标方法之后，模拟结束事务 ... 获取目标方法返回值 : 被改变的参数 Hello , Spring AOP 新增的内容 模拟记录日志功能 ... 被改变的参数 Hello , Spring AOP 新增的内容 执行目标方法之前，模拟开始事务 ... 我正在吃 : 被改变的参数 执行目标方法之后，模拟结束事务 ... 获取目标方法返回值 :null 新增的内容 模拟记录日志功能 ...
虽然程序是在调用 Chinese 对象的 sayHello、eat 两个方法，但从上面运行结果不难看出：实际执行的绝对不是 Chinese 对象的方法，而是 AOP 代理的方法。也就是
说，Spring AOP 同样为 Chinese 类生成了 AOP 代理类。这一点可通过在程序中增加如下代码看出：
System.out.println(p.getClass());
上面代码可以输出 p 变量所引用对象的实现类，再次执行程序将可以看到上面代码产生 class
org.crazyit.app.service.impl.Chinese$$EnhancerByCGLIB$$290441d2 的输出，这才是 p 变量所引用的对象的实现类，这个类也就是 Spring AOP 动
态生成的 AOP 代理类。从 AOP 代理类的类名可以看出，AOP 代理类是由 CGLIB 来生成的。
如果将上面程序程序稍作修改：只要让上面业务逻辑类 Chinese 类实现一个任意接口——这种做法更符合 Spring 所倡导的“面向接口编程”的原则。假
设程序为 Chinese 类提供如下 Person 接口，并让 Chinese 类实现该接口：
public interface Person {
String sayHello(String name);
void eat(String food);
}
接下来让 BeanTest 类面向 Person 接口、而不是 Chinese 类编程。即将 BeanTest 类改为如下形式：
public class BeanTest {
public static void main(String[] args) {
// 创建 Spring 容器
ApplicationContext ctx = new ClassPathXmlApplicationContext("bean.xml");
Person p = ctx.getBean("chinese" ,Person.class);
System.out.println(p.sayHello("张三"));
p.eat("西瓜");
System.out.println(p.getClass());
}
}
原来的程序是将面向 Chinese 类编程，现在将该程序改为面向 Person 接口编程，再次运行该程序，程序运行结果没有发生改变。只是
System.out.println(p.getClass()); 将会输出 class $Proxy7，这说明此时的 AOP 代理并不是由 CGLIB 生成的，而是由 JDK 动态代理生成的。
Spring AOP 框架对 AOP 代理类的处理原则是：如果目标对象的实现类实现了接口，Spring AOP 将会采用 JDK 动态代理来生成 AOP 代理类；如果目
标对象的实现类没有实现接口，Spring AOP 将会采用 CGLIB 来生成 AOP 代理类——不过这个选择过程对开发者完全透明、开发者也无需关心。
Spring AOP 会动态选择使用 JDK 动态代理、CGLIB 来生成 AOP 代理，如果目标类实现了接口，Spring AOP 则无需 CGLIB 的支持，直接使用 JDK
提供的 Proxy 和 InvocationHandler 来生成 AOP 代理即可。
Spring AOP 原理剖析
通过前面介绍可以知道：AOP 代理其实是由 AOP 框架动态生成的一个对象，该对象可作为目标对象使用。AOP 代理包含了目标对象的全部方法，但
AOP 代理中的方法与目标对象的方法存在差异：AOP 方法在特定切入点添加了增强处理，并回调了目标对象的方法。
AOP 代理所包含的方法与目标对象的方法示意图如图 3 所示。
图 3.AOP 代理的方法与目标对象的方法
Spring 的 AOP 代理由 Spring 的 IoC 容器负责生成、管理，其依赖关系也由 IoC 容器负责管理。因此，AOP 代理可以直接使用容器中的其他 Bean 实
例作为目标，这种关系可由 IoC 容器的依赖注入提供。
纵观 AOP 编程，其中需要程序员参与的只有 3 个部分：
- 定义普通业务组件。
- 定义切入点，一个切入点可能横切多个业务组件。
- 定义增强处理，增强处理就是在 AOP 框架为普通业务组件织入的处理动作。
上面 3 个部分的第一个部分是最平常不过的事情，无须额外说明。那么进行 AOP 编程的关键就是定义切入点和定义增强处理。一旦定义了合适的切入
点和增强处理，AOP 框架将会自动生成 AOP 代理，而 AOP 代理的方法大致有如下公式：
代理对象的方法 = 增强处理 + 被代理对象的方法
在上面这个业务定义中，不难发现 Spring AOP 的实现原理其实很简单：AOP 框架负责动态地生成 AOP 代理类，这个代理类的方法则由 Advice 和回
调目标对象的方法所组成。
对于前面提到的图 2 所示的软件调用结构：当方法 1、方法 2、方法 3 ……都需要去调用某个具有“横切”性质的方法时，传统的做法是程序员去手动修
改方法 1、方法 2、方法 3 ……、通过代码来调用这个具有“横切”性质的方法，但这种做法的可扩展性不好，因为每次都要改代码。
于是 AOP 框架出现了，AOP 框架则可以“动态的”生成一个新的代理类，而这个代理类所包含的方法 1、方法 2、方法 3 ……也增加了调用这个具有“横
切”性质的方法——但这种调用由 AOP 框架自动生成的代理类来负责，因此具有了极好的扩展性。程序员无需手动修改方法 1、方法 2、方法 3 的代
码，程序员只要定义切入点即可—— AOP 框架所生成的 AOP 代理类中包含了新的方法 1、访法2、方法 3，而 AOP 框架会根据切入点来决定是否要
在方法 1、方法 2、方法 3 中回调具有“横切”性质的方法。
简而言之：AOP 原理的奥妙就在于动态地生成了代理类.