1. 介绍
当前有多个可用的AOP库，这些库必须能够回答许多问题：
- 它与我现有的或新的应用程序兼容吗？
- 在哪里可以实施AOP？
- 它与我的应用程序集成的速度有多快？
- 性能开销是多少？
在本文中，我们将着眼于回答这些问题，并介绍Spring AOP和AspectJ（这两种最流行的Java AOP框架）。
2. AOP 概念
在开始之前，让我们对术语和核心概念进行快速的高层次审查：
- 切面–一种标准代码/功能，分散在应用程序的多个位置，通常与实际的业务逻辑（例如，事务管理）不同。每个方面都专注于特定的跨领域功能
- 连接点–这是程序执行过程中的特定点，例如方法执行，构造函数调用或字段分配
- 通知–方面在特定联接点中采取的操作
- 切入点–与联接点匹配的正则表达式。每当任何连接点与切入点匹配时，都会执行与该切入点关联的指定建议
- 编织–将方面与目标对象链接以创建建议对象的过程
3.Spring AOP 和AspectJ
现在，让我们从多个角度讨论Spring AOP和AspectJ，例如功能，目标，编织，内部结构，连接点和简单性
3.1 能力和目标
简而言之，Spring AOP和AspectJ具有不同的目标。 Spring AOP旨在在Spring IoC上提供一个简单的AOP实现，以解决程序员面临的最常见问题。它不打算用作完整的AOP解决方案-只能应用于由Spring容器管理的bean。 另一方面，AspectJ是原始的AOP技术，旨在提供完整的AOP解决方案。它比Spring AOP更强大，但也更复杂。还值得注意的是，AspectJ可以应用于所有域对象。
3.2 编织
AspectJ和Spring AOP都使用不同类型的编织，这会影响它们在性能和易用性方面的行为。 AspectJ使用三种不同的编织方式：
- 编译时编织：AspectJ编译器将方面和应用程序的源代码都作为输入，并生成编织类文件作为输出
- 编译后编织：这也称为二进制编织。它用于与我们的方面编织现有的类文件和JAR文件
- 加载时编织：这与以前的二进制编织完全一样，不同之处在于编织被推迟到类加载器将类文件加载到JVM为止
有关AspectJ本身的更多信息，请继续阅读本文。 由于AspectJ使用编译时和类加载时编织，因此Spring AOP使用运行时编织。 通过运行时编织，可以在应用程序执行期间使用目标对象的代理来编织各方面–使用JDK动态代理或CGLIB代理（将在下一部分中进行讨论）：
3.3 内部结构与应用
Spring AOP是基于代理的AOP框架。这意味着要实现目标对象的各个方面，它将创建该对象的代理。这可以通过以下两种方式之一来实现：
- JDK动态代理– Spring AOP的首选方式。每当目标对象实现一个接口时，都将使用JDK动态代理
- CGLIB代理–如果目标对象未实现接口，则可以使用CGLIB代理
我们可以从官方文档中了解有关Spring AOP代理机制的更多信息。 另一方面，AspectJ在运行时不执行任何操作，因为类是直接用方面编译的。 因此，与Spring AOP不同，它不需要任何设计模式。为了将代码的各个方面编织起来，它引入了称为AspectJ编译器（ajc）的编译器，通过它我们可以编译程序，然后通过提供一个小的（<100K）运行时库来运行它。
3.4 连接点
在3.3节中，我们展示了Spring AOP基于代理模式。因此，它需要对目标Java类进行子类化，并相应地应用跨领域关注点。 但是它有一个局限性。我们不能跨“最终”类应用跨领域关注点（或方面），因为它们不能被覆盖，因此会导致运行时异常。 静态方法和最终方法也是如此。 Spring方面不能应用于它们，因为它们不能被覆盖。因此，由于这些限制，Spring AOP仅支持方法执行连接点。 但是，AspectJ在运行时之前将横切关注点直接编织到实际代码中。与Spring AOP不同，它不需要子类化目标对象，因此也支持许多其他连接点。以下是受支持的连接点的摘要：
| Joinpoint | Spring AOP Supported | AspectJ Supported |
|---|---|---|
| Method Call | No | Yes |
| Method Execution | Yes | Yes |
| Constructor Call | No | Yes |
| Constructor Execution | No | Yes |
| Static initializer execution | No | Yes |
| Object initialization | No | Yes |
| Field reference | No | Yes |
| Field assignment | No | Yes |
| Handler execution | No | Yes |
| Advice execution | No | Yes |
还值得注意的是，在Spring AOP中，方面未应用于同一类中调用的方法。 显然，这是因为当我们在同一类中调用方法时，便没有调用Spring AOP提供的代理方法。如果需要此功能，则必须在不同的bean中定义一个单独的方法，或使用AspectJ。
3.5 简单
Spring AOP显然更简单，因为它在构建过程之间没有引入任何额外的编译器或编织器。它使用运行时编织，因此可以与我们通常的构建过程无缝集成。尽管看起来很简单，但是它仅适用于Spring管理的bean。 但是，要使用AspectJ，我们需要引入AspectJ编译器（ajc）并重新打包所有库（除非我们切换到后编译或加载时编织）。 当然，这比前者要复杂得多，因为它引入了AspectJ Java工具（包括编译器（ajc），调试器（ajdb），文档生成器（ajdoc），程序结构浏览器（ajbrowser）），需要与我们的IDE或构建工具集成。
3.6 性能
就性能而言，编译时编织比运行时编织快得多。 Spring AOP是基于代理的框架，因此在应用程序启动时会创建代理。此外，每个方面还有更多方法调用，这会对性能产生负面影响。 另一方面，AspectJ在应用程序执行之前将各方面编织到主代码中，因此与Spring AOP不同，没有额外的运行时开销。 由于这些原因，基准测试表明AspectJ几乎比Spring AOP快8到35倍。
4. 摘要
下表概述了Spring AOP和AspectJ之间的主要区别：
| Spring AOP | AspectJ |
|---|---|
| Implemented in pure Java-- 用纯Java实现 | Implemented using extensions of Java programming language-- 使用Java编程语言的扩展实现 |
| No need for separate compilation process-- 无需单独的编译过程 | Needs AspectJ compiler (ajc) unless LTW is set up-- 除非设置了LTW，否则需要AspectJ编译器（ajc） |
| Only runtime weaving is available-- 仅需运行时编织 | Runtime weaving is not available. Supports compile-time, post-compile, and load-time Weaving-- 运行时编织不可用。支持编译时，后编译和加载时编织 |
| Less Powerful – only supports method level weaving-- 不足–仅支持方法级编织 | More Powerful – can weave fields, methods, constructors, static initializers, final class/methods, etc…–更强大–可以编织字段，方法，构造函数，静态初始值设定项，最终类/方法等… |
| Can only be implemented on beans managed by Spring container-- 只能在Spring容器管理的bean上实现 | Can be implemented on all domain objects-- 可以在所有领域对象上实施 |
| Supports only method execution pointcuts-- 仅支持方法执行切入点 | Support all pointcuts-- 支持所有切入点 |
| Proxies are created of targeted objects, and aspects are applied on these proxies-- 代理是针对目标对象创建的，并且方面已应用于这些代理 | Aspects are weaved directly into code before application is executed (before runtime)–在应用程序执行之前（运行时之前）将方面直接编织到代码中 |
| Much slower than AspectJ-- 比AspectJ慢得多 | Better Performance-- 更好的性能 |
| Easy to learn and apply-- 易于学习和应用 | Comparatively more complicated than Spring AOP-- 比Spring AOP复杂得多 |
5. 选择正确的框架
如果我们分析本节中提出的所有论点，就会开始理解，一个框架根本不比另一个框架更好。 简而言之，选择很大程度上取决于我们的要求：
- 框架：如果应用程序未使用Spring框架，那么我们别无选择，只能放弃使用Spring AOP的想法，因为它无法管理Spring容器无法达到的任何功能。但是，如果我们的应用程序是完全使用Spring框架创建的，那么我们可以使用Spring AOP，因为它易于学习和应用
- 灵活性：鉴于有限的连接点支持，Spring AOP并不是完整的AOP解决方案，但它解决了程序员面临的最常见问题。尽管如果我们想更深入地挖掘和利用AOP的最大功能，并希望获得广泛的可用连接点的支持，那么AspectJ是一个不错的选择
- 性能：如果我们使用的方面有限，则性能上将存在微不足道的差异。但是有时在应用程序具有成千上万个方面的情况下。在这种情况下，我们不想使用运行时编织，因此最好选择AspectJ。已知AspectJ比Spring AOP快8到35倍
- 两者兼有：这两个框架彼此完全兼容。我们总是可以尽可能利用Spring AOP，并且仍然使用AspectJ来获得前者不支持的连接点的支持。
6. 结论
在本文中，我们在几个关键领域分析了Spring AOP和AspectJ。 我们比较了两种AOP方法的灵活性以及它们与我们的应用的适应性。