我在“aspectj”模式下使用 Spring 的声明式事务(@Transactional 注释)。它在大多数情况下都能正常工作，但在某些情况下却不能。我们可以称它为 Lang(因为这就是它的实际名称)。

我已经能够将问题精确定位到加载时间编织器。通过在 aop.xml 中打开调试和详细日志记录，它会列出所有正在编织的类。日志中确实根本没有提到有问题的类 Lang。

然后我在Lang的顶部打了一个断点，导致Eclipse在加载Lang类时挂起线程。这个断点是在 LTW 编织其他类时命中的!所以我猜它要么尝试编织 Lang 并失败并且不输出它，要么其他一些类有一个引用强制它在实际获取之前加载 Lang有机会编织它。

但是我不确定如何继续调试它，因为我无法以较小的规模重现它。关于如何继续的任何建议？

更新:也欢迎提供其他线索。例如，LTW 实际上是如何运作的？似乎发生了很多魔法。是否有任何选项可以从 LTW 获得更多调试输出？我目前有:

<weaver options="-XnoInline -Xreweavable -verbose -debug -showWeaveInfo">

我忘了之前提到它:spring-agent 被用来允许 LTW，即 InstrumentationLoadTimeWeaver。

根据 Andy Clement 的建议，我决定检查 AspectJ 转换器是否曾经通过类(class)。我在 ClassPreProcessorAgent.transform(..) 中放置了一个断点，看起来 Lang 类甚至从未到达该方法，尽管它是由与其他类(Jetty 的 WebAppClassLoader 的实例)。

然后我继续在 InstrumentationLoadTimeWeaver$FilteringClassFileTransformer.transform(..) 中放置一个断点。 Lang 甚至连那个都没有命中。而且我认为应该为所有 加载的类调用该方法，而不管它们使用的是什么类加载器。这开始看起来像:

1. 我的调试有问题。可能 Lang 在 Eclipse 报告加载时未加载
2. Java 错误？牵强附会，但我想它确实发生了。

下一条线索:我打开了 -verbose:class 并且看起来好像 Lang is 被过早地加载了——可能在转换器加载之前添加到仪器。奇怪的是，我的 Eclipse 断点没有捕捉到这个加载。

这意味着 Spring 是新的嫌疑人。 ConfigurationClassPostProcessor 中似乎有一些处理加载类以检查它们。这可能与我的问题有关。

ConfigurationClassBeanDefinitionReader 中的这些行导致读取 Lang 类:

else if (metadata.isAnnotated(Component.class.getName()) ||
        metadata.hasAnnotatedMethods(Bean.class.getName())) {
    beanDef.setAttribute(CONFIGURATION_CLASS_ATTRIBUTE, CONFIGURATION_CLASS_LITE);
    return true;
}

特别是，metadata.hasAnnotatedMethods() 调用类上的getDeclaredMethods()，加载该类中所有方法的所有参数类。我猜这可能不是问题的结束，因为我认为这些类应该被卸载。 JVM 是否会出于不可知的原因缓存类实例？

最佳答案

好的，我已经解决了这个问题。本质上，它是与某些自定义扩展相关的 Spring 问题。如果有人遇到类似的事情，我会尝试逐步解释发生了什么。

首先，我们的项目中有一个自定义的BeanDefintionParser。此类具有以下定义:

private static class ControllerBeanDefinitionParser extends AbstractSingleBeanDefinitionParser {

    protected Class<?> getBeanClass(Element element) {
        try {
            return Class.forName(element.getAttribute("class"));
        } catch (ClassNotFoundException e) {
            throw new RuntimeException("Class " + element.getAttribute("class") + "not found.", e);
        }
    }

// code to parse XML omitted for brevity

}

现在，问题发生在所有 bean 定义都被读取并且 BeanDefinitionRegistryPostProcessor 开始启动之后。在这个阶段，一个名为 ConfigurationClassPostProcessor 的类开始查看所有 bean 定义, 搜索用 @Configuration 注释或具有 @Bean 方法的 bean 类。

在为bean 读取注解的过程中，它使用了AnnotationMetadata 接口(interface)。对于大多数常规 bean，使用一个名为 AnnotationMetadataVisitor 的子类。但是，在解析 bean 定义时，如果您重写了 getBeanClass() 方法以返回类实例，就像我们所做的那样，则会使用 StandardAnnotationMetadata 实例。当 StandardAnnotationMetadata.hasAnnotatedMethods(..) 被调用时，它会调用 Class.getDeclaredMethods()，这反过来会导致类加载器加载所有用作该类参数的类.以这种方式加载的类没有正确卸载，因此永远不会编织，因为这发生在 AspectJ 转换器注册之前。

现在，我的问题是我有这样一个类:

public class Something {
    private Lang lang;
    public void setLang(Lang lang) {
        this.lang = lang;
    }
}

然后，我有一个 Something 类的 bean，它使用我们的自定义 ControllerBeanDefinitionParser 进行了解析。这触发了错误的注解检测过程，进而触发了意外的类加载，这意味着 AspectJ 永远没有机会编织 Lang。

解决方案是不覆盖 getBeanClass(..)，而是覆盖 getBeanClassName(..)，根据文档，这是更可取的:

private static class ControllerBeanDefinitionParser extends AbstractSingleBeanDefinitionParser {

    protected String getBeanClassName(Element element) {
        return element.getAttribute("class");
    }

// code to parse XML omitted for brevity

}

今天的教训:不要重写 getBeanClass 除非你是认真的。实际上，除非您知道自己在做什么，否则不要尝试编写自己的 BeanDefinitionParser。

鳍。

关于java - AspectJ 加载时间编织器未检测到所有类，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/3619519/