比较Spring AOP和AspectJ

Dear 丶 2023-10-01 08:51 39阅读 0赞

### 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使用三种不同的编织方式：

1.  编译时编织：AspectJ编译器将方面和应用程序的源代码都作为输入，并生成编织类文件作为输出
2.  编译后编织：这也称为二进制编织。它用于与我们的方面编织现有的类文件和JAR文件
3.  加载时编织：这与以前的二进制编织完全一样，不同之处在于编织被推迟到类加载器将类文件加载到JVM为止

有关AspectJ本身的更多信息，请继续阅读本文。 由于AspectJ使用编译时和类加载时编织，因此Spring AOP使用运行时编织。 通过运行时编织，可以在应用程序执行期间使用目标对象的代理来编织各方面–使用JDK动态代理或CGLIB代理（将在下一部分中进行讨论）：

![在这里插入图片描述][watermark_type_d3F5LXplbmhlaQ_shadow_50_text_Q1NETiBAQXJjaGllX2phdmE_size_20_color_FFFFFF_t_70_g_se_x_16]

#### 3.3 内部结构**与应用** ####

Spring AOP是基于代理的AOP框架。这意味着要实现目标对象的各个方面，它将创建该对象的代理。这可以通过以下两种方式之一来实现：

1.  JDK动态代理– Spring AOP的首选方式。每当目标对象实现一个接口时，都将使用JDK动态代理
2.  CGLIB代理–如果目标对象未实现接口，则可以使用CGLIB代理

我们可以从官方文档中了解有关Spring AOP代理机制的更多信息。 **另一方面，AspectJ在运行时不执行任何操作，因为类是直接用方面编译的。** 因此，与Spring AOP不同，它不需要任何设计模式。为了将代码的各个方面编织起来，它引入了称为AspectJ编译器（ajc）的编译器，通过它我们可以编译程序，然后通过提供一个小的（<100K）运行时库来运行它。

#### 3.4 连接点 ####

在3.3节中，我们展示了Spring AOP基于代理模式。因此，它需要对目标Java类进行子类化，并相应地应用跨领域关注点。 但是它有一个局限性。我们不能跨“最终”类应用跨领域关注点（或方面），因为它们不能被覆盖，因此会导致运行时异常。 静态方法和最终方法也是如此。 Spring方面不能应用于它们，因为它们不能被覆盖。因此，由于这些限制，Spring AOP仅支持方法执行连接点。 但是，AspectJ在运行时之前将横切关注点直接编织到实际代码中。与Spring AOP不同，它不需要子类化目标对象，因此也支持许多其他连接点。以下是受支持的连接点的摘要：

<table> 
 <thead> 
  <tr> 
   <th>Joinpoint</th> 
   <th>Spring AOP Supported</th> 
   <th>AspectJ Supported</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>Method Call</td> 
   <td>No</td> 
   <td>Yes</td> 
  </tr> 
  <tr> 
   <td>Method Execution</td> 
   <td>Yes</td> 
   <td>Yes</td> 
  </tr> 
  <tr> 
   <td>Constructor Call</td> 
   <td>No</td> 
   <td>Yes</td> 
  </tr> 
  <tr> 
   <td>Constructor Execution</td> 
   <td>No</td> 
   <td>Yes</td> 
  </tr> 
  <tr> 
   <td>Static initializer execution</td> 
   <td>No</td> 
   <td>Yes</td> 
  </tr> 
  <tr> 
   <td>Object initialization</td> 
   <td>No</td> 
   <td>Yes</td> 
  </tr> 
  <tr> 
   <td>Field reference</td> 
   <td>No</td> 
   <td>Yes</td> 
  </tr> 
  <tr> 
   <td>Field assignment</td> 
   <td>No</td> 
   <td>Yes</td> 
  </tr> 
  <tr> 
   <td>Handler execution</td> 
   <td>No</td> 
   <td>Yes</td> 
  </tr> 
  <tr> 
   <td>Advice execution</td> 
   <td>No</td> 
   <td>Yes</td> 
  </tr> 
 </tbody> 
</table>

还值得注意的是，在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之间的主要区别：

<table> 
 <thead> 
  <tr> 
   <th>Spring AOP</th> 
   <th>AspectJ</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>Implemented in pure Java-- 用纯Java实现</td> 
   <td>Implemented using extensions of Java programming language-- 使用Java编程语言的扩展实现</td> 
  </tr> 
  <tr> 
   <td>No need for separate compilation process-- 无需单独的编译过程</td> 
   <td>Needs AspectJ compiler (ajc) unless LTW is set up-- 除非设置了LTW，否则需要AspectJ编译器（ajc）</td> 
  </tr> 
  <tr> 
   <td>Only runtime weaving is available-- 仅需运行时编织</td> 
   <td>Runtime weaving is not available. Supports compile-time, post-compile, and load-time Weaving-- 运行时编织不可用。支持编译时，后编译和加载时编织</td> 
  </tr> 
  <tr> 
   <td>Less Powerful – only supports method level weaving-- 不足–仅支持方法级编织</td> 
   <td>More Powerful – can weave fields, methods, constructors, static initializers, final class/methods, etc…–更强大–可以编织字段，方法，构造函数，静态初始值设定项，最终类/方法等…</td> 
  </tr> 
  <tr> 
   <td>Can only be implemented on beans managed by Spring container-- 只能在Spring容器管理的bean上实现</td> 
   <td>Can be implemented on all domain objects-- 可以在所有领域对象上实施</td> 
  </tr> 
  <tr> 
   <td>Supports only method execution pointcuts-- 仅支持方法执行切入点</td> 
   <td>Support all pointcuts-- 支持所有切入点</td> 
  </tr> 
  <tr> 
   <td>Proxies are created of targeted objects, and aspects are applied on these proxies-- 代理是针对目标对象创建的，并且方面已应用于这些代理</td> 
   <td>Aspects are weaved directly into code before application is executed (before runtime)–在应用程序执行之前（运行时之前）将方面直接编织到代码中</td> 
  </tr> 
  <tr> 
   <td>Much slower than AspectJ-- 比AspectJ慢得多</td> 
   <td>Better Performance-- 更好的性能</td> 
  </tr> 
  <tr> 
   <td>Easy to learn and apply-- 易于学习和应用</td> 
   <td>Comparatively more complicated than Spring AOP-- 比Spring AOP复杂得多</td> 
  </tr> 
 </tbody> 
</table>

### 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方法的灵活性以及它们与我们的应用的适应性。

[watermark_type_d3F5LXplbmhlaQ_shadow_50_text_Q1NETiBAQXJjaGllX2phdmE_size_20_color_FFFFFF_t_70_g_se_x_16]: https://img-blog.csdnimg.cn/622c6c8d85ef4d208365bd30f34cb902.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBAQXJjaGllX2phdmE=,size_20,color_FFFFFF,t_70,g_se,x_16