为什么使用 aspectjweaver javaagent 进行加载时间编织对我来说这么慢？

Question

我正在进行的项目相当大。在尝试让这个 spring 项目的加载时间编织工作时，我被指示同时使用 spring-instrument javaagent 和 aspectjweaver javaagent。但是，我注意到当使用 aspectjweaver 代理时，我的启动时间增加了 4-6 倍。我还可以看到来自 ContextOverridingClassLoader 的相同编织消息 4-6 次。

但是，如果我删除 aspectjweaver，并且只使用 spring-instrument，我注意到我的启动时间显着减少，每个连接点只有一条来自 AppClassLoader 的编织消息。

唯一的问题是某些特定的类没有被编织（我发现这是由于在类加载器加载错误的类之前尚未加载 spring 应用程序上下文，因为 spring 是启用编织的机制）。我通过创建一个自定义 javaagent 找到了自己的解决方案，该 javaagent 以与 spring-instrument 相同的方式进行编织，只是它在 premain 中而不是在应用程序上下文加载时这样做。它现在可以在合理的时间内编织所有类。

但是，我不想走这条老生常谈的道路，因为我只能假设这两个代理的设计方式是有原因的。

我想知道是否有其他人在 aspectjweaver javaagent 中看到过类似的问题，是否有人可能知道为什么该代理与仅使用 spring-instrument 相比如此缓慢。

Answer 1

如果答案让任何人感兴趣，我已经找到了问题所在。

Spring 使用临时类加载器 ContextOverridingClassLoader 来获取有关 bean 类的元数据，然后再将它们实际加载到上下文中。

spring-instrument javaagent（或者更准确地说，可能使用也可能不使用spring-instrument javaagent的spring框架代码）专门只编织由用于加载应用程序上下文的类加载器加载的类。

InstrumentationLoadTimeWeaver$FilteringClassFileTransformer 内的代码：

        if (!this.targetClassLoader.equals(loader)) {
            return null;
        }
        return this.targetTransformer.transform(
                loader, className, classBeingRedefined, protectionDomain, classfileBuffer);

另一方面，aspectjweaver 没有这样的过滤机制，因此即使是那些由 s​​pring 的临时 ContextOverridingClassLoader 加载的类也会编织。幸运的是，aspectjweaver 有一个基本上没有记录的系统属性（或者至少我找不到任何关于此的文档），称为 aj.weaving.loadersToSkip。通过将其设置为：

-Daj.weaving.loadersToSkip=org.springframework.context.support.ContextTypeMatchClassLoader$ContextOverridingClassLoader

我能够跳过该类加载器的编织，并极大地加快了我的应用程序上下文的加载速度。

顺便说一句，我发现 spring-instrument 和 aspectjweaver 最终都使用 ClassPreProcessorAgentAdapter 来编织类，因此可能没有必要同时使用这两个代理（aspectjweaver 将编织 spring-instrument 类的超集将要）。但是，根据您的配置，应用程序可能会在启动时抱怨缺少代理，因此您不妨将其包括在内（以增加一些不必要的开销为代价）。