20

我们有一个由 Jetty 运行的非常小的 Web 服务（少于 1K 行代码）。即使在我们的压力测试阶段，该服务也始终运行良好。但是，在运行 13 天后，我们在同一天在两个节点中遇到了 ClassNotFoundException。

奇怪的是，没有找到的类已经存在（它是启动例程的一部分，并且经常用于服务先前的请求）。实际上，只需重新启动该过程即可解决问题。两个节点都在不同的机器中，并且彼此独立。它们不依赖于外部资源，除了一个 JMS 连接。

我在谷歌搜索时找不到相关信息，因为大多数报告的问题与启动 Java 进程时类路径中缺少类有关，这不是我们的情况。我们怀疑可能存在以某种方式破坏 JVM 内存的内存泄漏，但这无法解释为什么相同的问题会同时在两个节点中发生。在过去的五天里，我们一直在运行密集的压力测试，附加了一个 JVM 监视器和一个内存泄漏分析器，一切似乎都很好。对于这个测试，我们将进程内存从 2GB 减少到 512MB。

细节：

  • 使用 Java HotSpot(TM) 64 位服务器 VM（内部版本 16.3-b01，混合模式）
  • 使用 jetty-runner-8.1.0.RC5.jar
  • 原cmd行：java -Xmx2048M -jar jetty-runner-8.1.0.RC5.jar --port 5000 webapp.war
  • 英特尔至强 E5-2680 8 核 (x2) + 16GB RAM
  • 红帽企业 Linux 6
  • 一些正在使用的框架：JBoss Resteasy、Spring IoC、Guava。

您能否就什么可能使 JVM 突然“忘记”先前加载的类的存在而无法再次加载它提供一些想法？

Caused by: java.lang.ClassNotFoundException: com.a.b.c.SomeClass
    at java.net.URLClassLoader$1.run(URLClassLoader.java:202) ~[na:1.6.0_37]
    at java.security.AccessController.doPrivileged(Native Method) ~[na:1.6.0_37]
    at java.net.URLClassLoader.findClass(URLClassLoader.java:190) ~[na:1.6.0_37]
    at java.lang.ClassLoader.loadClass(ClassLoader.java:306) ~[na:1.6.0_37]
    at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301) ~[na:1.6.0_37]
    at java.lang.ClassLoader.loadClass(ClassLoader.java:247) ~[na:1.6.0_37]
    at org.eclipse.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoader.java:424) ~[na:na]
    at org.eclipse.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoader.java:377) ~[na:na]
    at java.lang.Class.forName0(Native Method) ~[na:1.6.0_37]
    at java.lang.Class.forName(Class.java:247) ~[na:1.6.0_37]
    at sun.reflect.generics.factory.CoreReflectionFactory.makeNamedType(CoreReflectionFactory.java:95) ~[na:1.6.0_37]
    at sun.reflect.generics.visitor.Reifier.visitClassTypeSignature(Reifier.java:107) ~[na:1.6.0_37]
    at sun.reflect.generics.tree.ClassTypeSignature.accept(ClassTypeSignature.java:31) ~[na:1.6.0_37]
    at sun.reflect.annotation.AnnotationParser.parseSig(AnnotationParser.java:370) ~[na:1.6.0_37]
    at sun.reflect.annotation.AnnotationParser.parseClassValue(AnnotationParser.java:351) ~[na:1.6.0_37]
    at sun.reflect.annotation.AnnotationParser.parseMemberValue(AnnotationParser.java:280) ~[na:1.6.0_37]
    at sun.reflect.annotation.AnnotationParser.parseAnnotation(AnnotationParser.java:222) ~[na:1.6.0_37]
    at sun.reflect.annotation.AnnotationParser.parseAnnotations2(AnnotationParser.java:69) ~[na:1.6.0_37]
    at sun.reflect.annotation.AnnotationParser.parseAnnotations(AnnotationParser.java:52) ~[na:1.6.0_37]
    at java.lang.reflect.Field.declaredAnnotations(Field.java:1014) ~[na:1.6.0_37]
    at java.lang.reflect.Field.getDeclaredAnnotations(Field.java:1007) ~[na:1.6.0_37]

编辑：

有人提到我在 Win 下使用 NFS 挂载时，可能会发生 JVM 决定卸载一个类，然后在需要时重新加载它。如果在此过程中 NFS 连接中断，则文件句柄将无效，并且重新加载将失败并出现类似的堆栈跟踪。在我们的例子中，我们使用的是 Linux，所有涉及的文件都在同一个挂载中，这是一个本地硬盘。只是为了进行更多测试，我已经 CD 到 Jetty 临时目录并手动删除了一个众所周知的特定服务类。如果 JVM 卸载它然后尝试从 classes 目录重新加载它，它将失败。虽然这并不能解释最初的问题，但它可能会将更多信息放在桌面上......

4

2 回答 2

8

这是正在发生的事情：

  1. 当使用上面详述的 cmd 启动服务时，Jetty 在“/tmp”下创建一个子目录，其中包含 JVM 加载的应用程序类和资源。
  2. 在一段时间不活动后（在我们的特定场景中，13 到 20 天之间），该目录就会消失。结果，JVM 无法加载该文件。我们仍然不知道 JVM 是否在此错误之前卸载了该类，或者它为什么尝试重新读取 *.class 文件。查看源代码并了解这一点会很有趣，但这不在我们的短期待办事项列表中。
  3. 简单地重新启动 Jetty 会导致丢失的目录被重新创建，并且服务再次启动。

我们得到的一个很好的提示是，有些人在 Windows 上通过 NFS 加载 JAR 中的资源时报告了类似的问题（如果网络连接在短时间内丢失，NFS 句柄变得无效并且 JVM 失败并出现类似错误）。这不是我们的情况（/tmp 是本地存储），但非常相似。

感谢大家的帮助。

于 2013-09-17T01:11:35.343 回答
0

堆栈跟踪告诉我们它是关于处理注释而不是与加载类以执行代码有关。似乎注释处理器试图通过注释元素的来解析注释成员的值。ClassLoader

换句话说，您有一个具有类类型值的注释，@Foo(xyz=ABC.class)以及一个使用此构造注释的类或成员，但在运行时ABC无法通过ClassLoader注释元素访问该类。

这与这个类已经通过另一个加载的事实不冲突ClassLoader。

于 2013-09-12T09:16:41.670 回答