Spring @Configurable with Compile Time Weaving 的启动性能答案

【问题标题】：Startup performance of Spring @Configurable with Compile Time WeavingSpring @Configurable with Compile Time Weaving 的启动性能
【发布时间】：2010-11-11 07:35:40
【问题描述】：

这是我关于堆栈溢出的第一个问题，请善待。

我正在运行一个应用程序

春天 2.5.x
可配置的注释
编译时编织 (CTW)
行家
eclipse/ajdt

我使用 CTW，一切正常。但是如果我第一次实例化一个带注释的类需要很长时间。第二次非常快。

查看分析器堆栈跟踪的第一个调用，我看到 93% 的时间被 org.aspectj.weaver.internal.tools.PointcutExpressionImpl.matchesMethodExecution(Method)

在第二次调用的堆栈跟踪中，只有 1% 的时间用于此方法。更糟糕的是：第一次调用的时间大约是第二次调用的 10 倍。

我想知道，因为我认为 CTW 不再需要织布工。

但似乎只有当有人在这个类上调用 new 时，Spring 才开始分析原型 bean。它使用 aspectj weaver 分析需要完成的工作，并为下一次调用做好准备以加快此过程。

有没有人有任何加速初始化注释类的第一次调用的经验？

这是我的 pom 的 sn-p：

 <plugin>
 <groupId>org.codehaus.mojo</groupId>
 <artifactId>aspectj-maven-plugin</artifactId>
 <executions>
    <execution>
      <goals>
        <goal>test-compile</goal>
        <goal>compile</goal>
      </goals>
</execution>
 </executions>
 <dependencies>
   <dependency>
     <groupId>org.aspectj</groupId>
     <artifactId>aspectjtools</artifactId>
     <version>1.6.1</version>
   </dependency>
 </dependencies>
 <configuration>
 <verbose>true</verbose>
 <complianceLevel>1.5</complianceLevel>
 <source>1.5</source>
 <showWeaveInfo>true</showWeaveInfo>
 <outxml>true</outxml>
 <aspectLibraries>
   <aspectLibrary>
     <groupId>org.springframework</groupId>
     <artifactId>spring-aspects</artifactId>
   </aspectLibrary>
 </aspectLibraries>
 </configuration>
 </plugin>

【问题讨论】：

我认为这是 CTW 固有的。第一次调用必须完成所有繁重的工作来分析、编织和生成运行时类，而且非常昂贵。
它应该是 Load-time-weaving (LTW) 所固有的，而不是 CTW 所固有的！

标签： spring performance spring-aop configurable compile-time-weaving

【解决方案1】：

当我分析堆栈跟踪时，我自己找到了答案。

除了带有 CTW 的 @Configurable 之外，我还用于事务管理。当我第一次加载带有 @Configurable 注释的原型 bean 时，spring bean 工厂会检查我们的任何 aop:advices 是否匹配。因此它使用了一个aspectj库。

所以我最初的问题在某种程度上具有误导性。我们将 CTW 用于 @Configurable，但同时使用 LTW 进行事务和安全管理。在编译时编织的 bean 必须在加载时再次编织。

我现在将寻找一种完全避免 LTW 的方法，因为启动时间在我们的开发过程中至关重要。

感谢您的 cmets 和回答。他们很有帮助，因为他们把我推向了正确的方向。

【讨论】：

【解决方案2】：

使用 Spring 的 aop 配置，您可以获得一定程度的抽象性和便利性，但另一方面，Spring 需要在类加载期间做大量工作来生成动态代理和编织类。这在启动时总是会产生开销。

但是服务器启动时间很少是一个关键因素，您倾向于以天为单位来衡量正常运行时间，因此在我看来，为了方便起见，慢一分钟左右的启动是一个公平的交易，尽管它可能会令人讨厌调试目的。

如果您在服务器启动时添加一些进程来运行应用程序，您可以在一定程度上减轻首次加载的开销。这有助于确保服务器已准备就绪，因此您的第一个真正请求不会受到打击。

如果您确实必须更快地启动或发现开销不可接受，您可以考虑使用编译时编织来实现切入点。使用这种方法，所有繁重的工作都在编译时完成，因此类的加载时间与未编织版本的加载时间相当（当然取决于编织的作用）。

【讨论】：