NoClassDefFoundError java.lang包中的类的“错误名称”

时间:2017-10-26 00:09:17

标签: java reflection classloading

我在主机上运行Cassandra 2.2.11(并且不会升级)。我在cron作业中定期运行nodetool命令进行监控。 nodetool实现为另一个使用JMX与Cassandra java进程通信的java进程。我每分钟发出五个左右的命令。

偶尔(不是任何可识别的模式),nodetool的执行将失败,NoClassDefFoundError引用java.lang中的一个类。例如,

java.lang.NoClassDefFoundError: java/lang/Thread (wrong name: java/lang/Thread)
    at java.lang.Class.getDeclaredFields0(Native Method)
    at java.lang.Class.privateGetDeclaredFields(Class.java:2583)
    at java.lang.Class.getDeclaredField(Class.java:2068)
    at java.util.concurrent.FutureTask.<clinit>(FutureTask.java:476)
    at java.util.concurrent.ScheduledThreadPoolExecutor.scheduleWithFixedDelay(ScheduledThreadPoolExecutor.java:590)
    at sun.rmi.transport.tcp.TCPChannel.free(TCPChannel.java:347)
    at sun.rmi.server.UnicastRef.free(UnicastRef.java:431)
    at sun.rmi.server.UnicastRef.done(UnicastRef.java:448)
    at sun.rmi.registry.RegistryImpl_Stub.lookup(Unknown Source)
    at com.sun.jndi.rmi.registry.RegistryContext.lookup(RegistryContext.java:132)
    at com.sun.jndi.toolkit.url.GenericURLContext.lookup(GenericURLContext.java:205)
    at javax.naming.InitialContext.lookup(InitialContext.java:417)
    at javax.management.remote.rmi.RMIConnector.findRMIServerJNDI(RMIConnector.java:1955)
    at javax.management.remote.rmi.RMIConnector.findRMIServer(RMIConnector.java:1922)
    at javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:287)
    at javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:270)
    at org.apache.cassandra.tools.NodeProbe.connect(NodeProbe.java:183)
    at org.apache.cassandra.tools.NodeProbe.<init>(NodeProbe.java:150)
    at org.apache.cassandra.tools.NodeTool$NodeToolCmd.connect(NodeTool.java:302)
    at org.apache.cassandra.tools.NodeTool$NodeToolCmd.run(NodeTool.java:242)
    at org.apache.cassandra.tools.NodeTool.main(NodeTool.java:158)

在此堆栈跟踪中,在FutureTask的类初始化期间发生错误。我也见过

java.lang.NoClassDefFoundError: java/lang/Object (wrong name: java/lang/Object)
    at java.lang.Class.getDeclaredMethods0(Native Method)
    at java.lang.Class.privateGetDeclaredMethods(Class.java:2701)
    at java.lang.Class.getDeclaredMethod(Class.java:2128)
    at java.lang.invoke.MethodHandleImpl$Lazy.<clinit>(MethodHandleImpl.java:614)
    [...]

但也

java.lang.NoClassDefFoundError: java/lang/String (wrong name: java/lang/String)
    at java.lang.Class.getDeclaredFields0(Native Method)
    at java.lang.Class.privateGetDeclaredFields(Class.java:2583)
    at java.lang.Class.getDeclaredField(Class.java:2068)
    at java.io.ObjectStreamClass.getDeclaredSUID(ObjectStreamClass.java:1703)
    at java.io.ObjectStreamClass.access$700(ObjectStreamClass.java:72)
    at java.io.ObjectStreamClass$2.run(ObjectStreamClass.java:484)
    at java.io.ObjectStreamClass$2.run(ObjectStreamClass.java:472)
    [...]

所以它不仅发生在类初始化期间,而且,在我收集的少量样本中,反射实现中的某些内容似乎确实是罪魁祸首。

Java版本为8

java version "1.8.0_144"

nodetool启动程序始终使用相同的类路径。并且没有奇怪的类(或其他类加载器)。相同的安装在数百个相同的节点上完成(在Linux上)。

我对NoClassDefFoundError wrong name的热门搜索结果是指使用简化的类名称来启动java而不是完全限定名称的执行。这不是问题所在。此外,错误消息中的名称是相同的。

那么什么会导致“bootstrap”类的“错误名称”NoClassDefFoundError错误?

3 个答案:

答案 0 :(得分:1)

我认为缺少资源导致连接器超时等问题。你看到你的例子中的日志吗? nodeprobe是通过jmx连接还是尝试连接然后发生错误? 这些是非常典型的错误,也可能导致其他间歇性错误。(通常是OS / netowrk OS shit)因此: 包括你的字符串,甚至基于对象的错误;总之,它是有道理的。 可能是您应该在错误发生时检查您的资源。 我知道资源监视器导致缺乏资源,这有点像22;但它发生了嘿嘿

答案 1 :(得分:1)

由于没有找到基本的java库,我认为你的java安装存在问题,或者你没有设置CLASSPATHJAVA_HOME环境变量。尝试设置CLASSPATHJAVA_HOME环境变量。

export JAVA_HOME="/usr/lib/jvm/java-8-oracle/bin"
export CLASSPATH="/usr/lib/jvm/java-8-oracle/lib"

如果不起作用,请尝试重新安装java并设置环境变量。

答案 2 :(得分:1)

根据堆栈跟踪,在getDeclaredFields0的调用中抛出异常ID。但是,这不是最初的例外。根据OpenJDK源代码,代码库中没有任何内容在异常消息中抛出“错误名称”的异常。消息来自其他地方。

我强烈怀疑这实际上是在重新报告第一次加载或初始化某个类时发生的问题。会发生的是,类加载器第一次发现问题,将违规的内部类对象标记为“坏”,然后抛出错误。根据javadoc,应用程序不应该尝试从中恢复。但如果有人这样做,然后尝试以某种方式使用“坏”类,原始问题将再次作为NoClassDefFoundError报告原因。

那么原因是什么意思?

很难分辨,因为我们没有原始异常的堆栈跟踪;即然后是类加载/初始化首次失败的那个。如果你能找到那个堆栈跟踪,我们可以找到执行它的第三方库。它几乎肯定发生在类加载器中。

明显的含义是类文件中的类名与类字节码中的名称不匹配。但是,我们需要检查类加载器代码以确保。

那为什么会间歇性地发生呢?

可能是因为应用程序JVM有许多类加载器,并且只有它们的一部分用这个坏类“污染”了它们的类命名空间。

这可能是坏消息。它表明应用程序的核心可能存在某种同步问题。

无论如何,没有足够的证据可以得出合理的结论。

底线

根据证据,我会猜测这是某种“代码编织”或“字节码工程”出错的结果。作为进一步猜测,我会说一些子类加载器没有正确委托,并错误地尝试处理内置类。 (甚至可能是有问题的类加载器知道它永远不应该处理“java.lang。*”类,并且它有一种模糊的说法。)

为什么呢?可能是因为有人/某事物明确地将“rt.jar”添加到了一些不应该出现的类路径中。

为了进一步诊断,我们首先需要的是原始的堆栈跟踪,它告诉我们哪个类加载器做了初始损坏。