java - 不活动后调用 java.beans.Introspector.getBeanInfo 时出现性能问题

Question

我正在使用第 3 方库动态创建 Java 类的实例并在 Introspector.getBeanInfo 的帮助下填充这些实例。某些请求可能会导致对 Introspector.getBeanInfo 进行 5 或 6 次连续调用。我发现当应用程序空闲大约一个小时左右时，第一次调用 Introspector.getBeanInfo 与后续调用(< 100毫秒)。在接下来的几分钟内调用的电话继续花费 < 100 毫秒，但当我再等一个小时时，第一个电话再次花费 20-60 秒。

在尝试使用简单的测试应用程序重新创建行为时，我发现当 Java 应用程序本身未运行一个小时时会出现类似的行为。例如，如果我运行以下控制台应用程序，可能需要 15 毫秒才能完成。如果我然后等待一个小时并重新运行该应用程序，则需要 20 秒才能完成。

long start = System.currentTimeMillis();
System.out.println("Start");
Introspector.getBeanInfo(MyClass.class, Object.class);
long end = System.currentTimeMillis();
System.out.println("End: " + (end-start));

我最初认为这个问题可能与以下事实有关:Introspector 类试图根据我的应用程序中不存在的标准命名约定(例如，MyClassBeanInfo)创建类的实例，扫描 jar 文件以尝试找到这些类需要很长时间(我的 java 应用程序有 100 多个引用的 jar 文件)，但我调用了 Introspector.getBeanInfo(MyClass.class, Object.class , Introspector.IGNORE_ALL_BEANINFO) 使用反射(它是 Sun 的 JRE 中的私有(private)方法，从代码来看似乎跳过了 BeanInfo 类的查找)，我仍然能够重现延迟。

我还搜索了有关任何类型的 JRE/JVM jar 缓存的信息，但尚未找到任何似乎可以解释此行为的信息。任何人都知道为什么会这样，如果有什么我可以解决的？

作为旁注，我在 Windows XP 上使用 JDK 1.6.0_21。我使用的第 3 方库是 BlazeDS。我的应用程序使用 Spring/BlazeDS 集成托管在 Tomcat 中。我重写了一些 BlazeDS 类，以便准确指出延迟的位置(这是 flex.messaging 的 getPropertyDescriptorCacheEntry 方法中对 Introspector.getBeanInfo 的调用.io.BeanProxy)。此外，BlazeDS 会缓存 BeanInfo，因此仅当 Blaze 反序列化映射到尚未处理的 Java 类的对象时才会调用 Introspector.getBeanInfo。所以，我确实有其他方法可以解决这个问题，但我真的很想知道是否有针对此行为的有效解释。

编辑:我在重现问题时多次在进程上运行 jstack(感谢@Tom)并确认它与加载 jar 文件有关。我在 20 秒的时间范围内(延迟的总时间)转储线程 5 次，每次都产生以下结果:

"http-8080-exec-6" daemon prio=6 tid=0x65cae800 nid=0x1a50 runnable [0x67a3d000]
   java.lang.Thread.State: RUNNABLE
    at java.util.zip.ZipFile.open(Native Method)
    at java.util.zip.ZipFile.<init>(Unknown Source)
    at java.util.jar.JarFile.<init>(Unknown Source)
    at java.util.jar.JarFile.<init>(Unknown Source)
    at org.apache.catalina.loader.WebappClassLoader.openJARs(WebappClassLoader.java:2704)
    at org.apache.catalina.loader.WebappClassLoader.findResourceInternal(WebappClassLoader.java:2945)
    - locked <0x1804cc18> (a [Ljava.util.jar.JarFile;)
    at org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappClassLoader.java:2739)
    at org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoader.java:1144)
    at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1639)
    - locked <0x1803dd38> (a org.apache.catalina.loader.WebappClassLoader)
    at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1517)
    at java.beans.Introspector.instantiate(Unknown Source)
    at java.beans.Introspector.findExplicitBeanInfo(Unknown Source)
    - locked <0x434649a0> (a java.lang.Class for java.beans.Introspector)
    at java.beans.Introspector.<init>(Unknown Source)
    at java.beans.Introspector.getBeanInfo(Unknown Source)
    - locked <0x181bed70> (a java.lang.Object)

我不禁想到有某种 JRE/JVM jar 缓存在一小时后过期并强制重新扫描 jar 文件，但我在网上找不到任何概述此类行为的内容。

编辑:事实证明，Tomcat WebappClassLoader 会缓存 JAR 文件并定期清除该缓存。现在看看该缓存是否可以配置...

编辑:Tomcat 在最后一次访问 jar 文件后 90 秒关闭所有 JAR 文件。我覆盖了 WebappClassLoader 以在 jar 文件关闭时打印出来。关闭 jar 文件后，我试图重现延迟，但无法重现。所以，这告诉我有一个 JRE/JVM jar 文件缓存，或者只是操作系统(或我的机器、防病毒等)中固有的东西导致长时间延迟后加载时间变慢。仍在努力......

Answer 1

在我的雇主，我们也严重依赖动态生成的类。由于 Introspector 的问题及其行为方式(例如，依赖 ClassLoader 行为)并尝试加载许多我们没有的 *BeanInfo 类，这是一个不-为我们而去，我们决定不使用 Introspector 并自行重新实现该功能。

不确定您真正需要多少 BeanInfo，但使用反射和本地开发的属性元数据信息组件可能更容易，您可以更好地控制这些组件。更简单的意思是，一旦您将应用程序部署到其他应用程序服务器上，您将不再紧张，这些应用程序服务器具有自己的 ClassLoader 行为，并且比 Tomcat 上的行为更加繁重且不可配置。

BeanInfo 和相关组件是接口(interface)，因此您甚至可能只需要重新实现 Introspector 本身，而不是使用它的所有代码。