类装入问题解密，第 2 部分: 基本的类装入异常

最新推荐文章于 2018-04-18 09:48:57 发布

wonder4

最新推荐文章于 2018-04-18 09:48:57 发布

阅读量1.5k

点赞数

分类专栏： java理论与实践文章标签：解密 classloader integer ibm java class

本文链接：https://blog.csdn.net/wonder4/article/details/582159

版权

java理论与实践专栏收录该内容

97 篇文章 0 订阅

订阅专栏

类装入问题解密，第 2 部分: 基本的类装入异常

深入观察一些简单的类装入问题

文档选项

将此页作为电子邮件发送

对此页的评价

帮助我们改进这些内容

级别: 中级

Simon Burns , Java 技术中心开发团队, IBM Hursley 实验室
Lakshmi Shankar , Java 技术中心开发团队, IBM Hursley 实验室

2006 年 1 月 16 日

这个四部分构成的文章系列研究 Java™ 的类装入问题，帮助应用程序开发人员理解和调试可能遇到的问题。在第 2 部分中，来自 IBM Hursley 实验室的作者 Lakshmi Shankar 和 Simon Burns 处理的一些异常，虽然相当简单，但是却常常困扰着新老 Java 开发人员。

本文是系列中四篇文章的第二篇，它考察了一般在运行应用程序时抛出的各种类装入异常。这些异常虽然常见，但是 Java 程序员对它们的理解通常不深。本文将逐个提供能够突出这些异常行为特点的详细示例，解释造成异常的原因，并介绍一些可行的解决技术。文章从非常常见的 ClassNotFoundException 开始，逐渐转移到不太常见的异常，例如 ExceptionInInitializerError。

在开始这篇文章之前，应当熟悉类装入委托模型，以及类链接的阶段和过程。我们强烈建议您从阅读这个系列的第一篇文章开始。

ClassNotFoundException

ClassNotFoundException 是最常见的类装入异常类型。它发生在装入阶段。Java 规范对 ClassNotFoundException 的描述是这样的：

当应用程序试图通过类的字符串名称，使用以下三种方法装入类，但却找不到指定名称的类定义时抛出该异常。

类 Class 中的 forName() 方法。
类 ClassLoader 中的 findSystemClass() 方法。
类 ClassLoader 中的 loadClass() 方法。

所以，如果显式地装入类的尝试失败，那么就抛出 ClassNotFoundException。清单 1 中的测试用例提供的示例代码抛出了一个 ClassNotFoundException：

清单 1. ClassNotFoundExceptionTest.java


import java.net.MalformedURLException;
import java.net.URL;
import java.net.URLClassLoader;

public class ClassNotFoundExceptionTest {

    public static void main(String args[]) {
        try {
            URLClassLoader loader = new URLClassLoader(new URL[] { new URL(
                "file://C:/CL_Article/ClassNotFoundException/")});
            loader.loadClass("DoesNotExist");
        } catch (ClassNotFoundException e) {
            e.printStackTrace();
        } catch (MalformedURLException e) {
            e.printStackTrace();
        }
    }
}

这个测试用例定义了一个类装入器（MyClassLoader），用于装入一个不存在的类（DoesNotExist）。当它运行时，会出现以下异常：


java.lang.ClassNotFoundException: DoesNotExist
    at java.net.URLClassLoader.findClass(URLClassLoader.java:376)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:572)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:504)
    at ClassNotFoundExceptionTest.main(ClassNotFoundExceptionTest.java:11)

因为这个测试试图使用对 loadClass() 的显式调用来进行装入，所以抛出 ClassNotFoundException。

通过抛出 ClassNotFoundException，类装入器提示，定义类时所需要的字节码在类装入器所查找的位置上不存在。这些异常修复起来通常比较简单。可以用 IBM 的 verbose 选项检查类路径，确保使用的类路径设置正确（要获得 verbose 的更多信息，请参阅本系列的第一篇文章）。如果类路径设置正确，但是仍然看到这个错误，那么就是需要的类在类路径中不存在。要修复这个问题，可以把类移动到类路径中指定的目录或 JAR 文件中，或者把类所在的位置添加到类路径中。

回页首

NoClassDefFoundError

NoClassDefFoundError 是类装入器在装入阶段抛出的另一个常见异常。JVM 规范对 NoClassDefFoundError 的定义如下：

如果 Java 虚拟机或 ClassLoader 实例试图装入类定义（作为正常的方法调用的一部分，或者作为使用 new 表达式创建新实例的一部分），但却没有找到类定义时抛出该异常。

当目前执行的类已经编译，但是找不到它的定义时，会存在 searched-for 类定义。

实际上，这意味着 NoClassDefFoundError 的抛出，是不成功的隐式类装入的结果。

清单 2 到清单 4 的测试用例产生了 NoClassDefFoundError，因为类 B 的隐式装入会失败：

清单 2. NoClassDefFoundErrorTest.java


public class NoClassDefFoundErrorTest {
	public static void main(String[] args) {
		A a = new A();
	}
}

清单 3. A.java


public class A extends B {
}

清单 4. B.java


public class B {
}

这几个清单中的代码编译好之后，删除 B 的类文件。当代码执行时，就会出现以下错误：


Exception in thread "main" java.lang.NoClassDefFoundError: B
    at java.lang.ClassLoader.defineClass0(Native Method)
    at java.lang.ClassLoader.defineClass(ClassLoader.java:810)
    at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:147)
    at java.net.URLClassLoader.defineClass(URLClassLoader.java:475)
    at java.net.URLClassLoader.access$500(URLClassLoader.java:109)
    at java.net.URLClassLoader$ClassFinder.run(URLClassLoader.java:848)
    at java.security.AccessController.doPrivileged1(Native Method)
    at java.security.AccessController.doPrivileged(AccessController.java:389)
    at java.net.URLClassLoader.findClass(URLClassLoader.java:371)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:572)
    at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:442)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:504)
    at NoClassDefFoundErrorTest.main(NoClassDefFoundErrorTest.java:3)

类 A 扩展了类 B；所以，当类 A 装入时，类装入器会隐式地装入类 B。因为类 B 不存在，所以抛出 NoClassDefFoundError。如果显式地告诉类装入器装入类 B（例如通过 loadClass("B") 调用），那么就会抛出 ClassNotFoundException。

显然，要修复这个特殊示例中的问题，在对应的类装入器的类路径中，必须存在类 B。这个示例看起来可能价值不大、也不真实，但是，在复杂的有许多类的真实系统中，会因为类在打包或部署期间的遗失而发生这类情况。

在这个例子中，A 扩展了 B；但是，即使 A 用其他方式引用 B，也会出现同样的问题 —— 例如，以方法参数引用或作为实例字段。如果两个类之间的关系是引用关系而不是继承关系，那么会在第一次使用 A 时抛出错误，而不是在装入 A 时抛出。

回页首

ClassCastException

类装入器能够抛出的另一个异常是 ClassCastException。它是在类型比较中发现不兼容类型的时候抛出的。JVM 规范指定 ClassCastException 是：

该异常的抛出，表明代码企图把对象的类型转换成一个子类，而该对象并不是这个子类的实例。

清单 5 演示的代码示例会产生一个 ClassCastException：

清单 5. ClassCastException.java


public class ClassCastExceptionTest {
    public ClassCastExceptionTest() {
    }

    private static void storeItem(Integer[] a, int i, Object item) {
        a[i] = (Integer) item;
    }

    public static void main(String args[]) {
        Integer[] a = new Integer[3];
        try {
            storeItem(a, 2, new String("abc"));
        } catch (ClassCastException e) { 
            e.printStackTrace();
        }
    }
}

在清单 5 中，调用了 storeItem() 方法，使用一个 Integer 数组、一个 int 和一个字符串作为参数。但是在内部，该方法做了两件事：

隐式地把 String 对象类型转换成 Object 类型（用于参数列表）。
显式地把这个 Object 类型转换成 Integer 类型（在方法定义中）。

当程序运行时，会出现以下异常：


java.lang.ClassCastException: java.lang.String
    at ClassCastExceptionTest.storeItem(ClassCastExceptionTest.java:6)
    at ClassCastExceptionTest.main(ClassCastExceptionTest.java:12)

这个异常是由显式类型转换抛出的，因为测试用例试图把类型为 String 的东西转换成 Integer。

当检查对象（例如清单 5 中的 item）并把类型转换成目标类（Integer）时，类装入器会检查以下规则：

对于普通对象（非数组）：对象必须是目标类的实例或目标类的子类的实例。如果目标类是接口，那么会把它当作实现了该接口的一个子类。
对于数组类型：目标类必须是数组类型或 java.lang.Object、java.lang.Cloneable 或 java.io.Serializable。

如果违反了以上任何一条规则，那么类装入器就会抛出 ClassCastException。修复这类异常的最简单方式就是仔细检查对象要转换到的类型是否符合以上提到的规则。在某些情况下，在做类型转换之前用 instanceof 进行检查是有意义的。

回页首

UnsatisfiedLinkError

在把本机调用链接到对应的本机定义时，类装入器扮演着重要角色。如果程序试图装入一个不存在或者放错的本机库时，在链接阶段的解析过程会发生 UnsatisfiedLinkError。JVM 规范指定 UnsatisfiedLinkError 是：

对于声明为 native 的方法，如果 Java 虚拟机找不到和它对应的本机语言定义，就会抛出该异常。

当调用本机方法时，类装入器会尝试装入定义了该方法的本机库。如果找不到这个库，就会抛出这个错误。

清单 6 演示了抛出 UnsatisfiedLinkError 的测试用例：

清单 6. UnsatisfiedLinkError.java


public class UnsatisfiedLinkErrorTest {

    public native void call_A_Native_Method();

    static {
        System.loadLibrary("myNativeLibrary");
    }

    public static void main(String[] args) {
        new UnsatisfiedLinkErrorTest().call_A_Native_Method();
    }
}

这段代码调用本机方法 call_A_Native_Method()，该方法是在本机库 myNativeLibrary 中定义的。因为这个库不存在，所以在程序运行时会发生以下错误：


The java class could not be loaded. java.lang.UnsatisfiedLinkError:
  Can't find library myNativeLibrary  (myNativeLibrary.dll)
  in sun.boot.library.path or java.library.path
sun.boot.library.path=D:/sdk/jre/bin
java.library.path= D:/sdk/jre/bin

at java.lang.ClassLoader$NativeLibrary.load(Native Method)
    at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:2147)
    at java.lang.ClassLoader.loadLibrary(ClassLoader.java:2006)
    at java.lang.Runtime.loadLibrary0(Runtime.java:824)
    at java.lang.System.loadLibrary(System.java:908)
    at UnsatisfiedLinkErrorTest.<clinit>(UnsatisfiedLinkErrorTest.java:6)

本机库的装入由调用 System.loadLibrary() 方法的类的类装入器启动 —— 在清单 6 中，就是 UnsatisfiedLinkErrorTest 的类装入器。根据使用的类装入器，会搜索不同的位置：

对于由 bootstrap 类装入器装入的类，搜索 sun.boot.library.path。
对于由扩展类装入器装入的类，先搜索 java.ext.dirs，然后是 sun.boot.library.path，然后是 java.library.path。
对于由系统类装入器装入的类，搜索 sun.boot.library.path，然后是 java.library.path。

在清单 6 中，UnsatisfiedLinkErrorTest 类是由系统类装入器装入的。要装入所引用的本机库，这个类装入器先查找 sun.boot.library.path，然后查找 java.library.path。因为在两个位置中都没有需要的库，所以类装入器抛出 UnsatisfiedLinkageError。

一旦理解了库装入过程所涉及的类装入器，就可以通过把库放在合适位置来解决这类问题。

回页首

ClassCircularityError

JVM 规范指定 ClassCircularityError 的抛出条件是：

类或接口由于是自己的超类或超接口而不能被装入。

这个错误是在链接阶段的解析过程中抛出的。这个错误有点奇怪，因为 Java 编译器不允许发生这种循环情况。但是，如果独立地编译类，然后再把它们放在一起，就可能发生这个错误。请设想以下场景。首先，编译清单 7 和清单 8 中的类：

清单 7. A.java


public class A extends B {
}

清单 8. B.java


public class B {
}

然后，分别编译清单 9 和清单 10 中的类：

清单 9. A.java


public class A {
}

清单 10. B.java


public class B extends A {
}

最后，采用清单 7 的类 A 和清单 10 的类 B，并运行一个应用程序，试图装入 A 或者 B。这个情况看起来可能不太可能，但是在复杂的系统中，在把不同部分放在一起的时候，可能会发生类似的情况。

显然，要修复这个问题，必须避免循环的类层次结构。

回页首

ClassFormatError

JVM 规范指出，抛出 ClassFormatError 的条件是：

负责指定所请求的编译类或接口的二进制数据形式有误。

这个异常是在类装入的链接阶段的校验过程中抛出。如果字节码发生了更改，例如主版本号或次版本号发生了更改，那么二进制数据的形式就会有误。例如，如果对字节码故意做了更改，或者在通过网络传送类文件时现出了错误，那么就可能发生这个异常。

修复这个问题的惟一方法就是获得字节码的正确副本，可能需要重新进行编译。

回页首

ExceptionInInitializerError

根据 JVM 规范，抛出 ExceptionInInitializer 的情况是：

如果初始化器突然完成，抛出一些异常 E，而且 E 的类不是 Error 或者它的某个子类，那么就会创建 ExceptionInInitializerError 类的一个新实例，并用 E 作为参数，用这个实例代替 E。
如果 Java 虚拟机试图创建类 ExceptionInInitializerError 的新实例，但是因为出现 Out-Of-Memory-Error 而无法创建新实例，那么就抛出 OutOfMemoryError 对象作为代替。

清单 8 中的代码抛出 ExceptionInInitializerError：

清单 8. ExceptionInInitializerErrorTest.java


public class ExceptionInInitializerErrorTest {
    public static void main(String[] args) {
        A a = new A();
    }
}

class A {
    // If the SecurityManager is not turned on, a 
    // java.lang.ExceptionInInitializerError will be thrown 
    static {
        if(System.getSecurityManager() == null)
            throw new SecurityException();
    }
}

当静态代码块中发生异常时，会被自动捕捉并用 ExceptionInInitializerError 包装该异常。在下面的输出中可以看到这点：


Exception in thread "main" java.lang.ExceptionInInitializerError
   at ExceptionInInitializerErrorTest.main(ExceptionInInitializerErrorTest.java:3)
Caused by: java.lang.SecurityException
   at A.<clinit>(ExceptionInInitializerErrorTest.java:12)
   ... 1 more

这个错误在类装入的初始化阶段抛出。修复这个错误的方法是检查造成 ExceptionInInitializerError 的异常（在堆栈跟踪的 Caused by: 下显示）并寻找阻止抛出这个异常的方式。

回页首

下期预告

在这篇文章中，学习了不同的类装入异常，从最基本的错误到一些更神秘的错误。在本系列的下一篇文章中，将研究其他一些在运行更复杂的应用程序时可能会遇到的类装入问题。

回页首

参考资料

学习

您可以参阅本文在 developerWorks 全球站点上的英文原文。
Demystifying class loading problems：阅读完整系列。
“了解 Java ClassLoader”（Greg Travis developerWorks，2001 年 4 月）：类装入介绍
“Java 编程的动态性，第 1 部分: 类和类装入”（Dennis Sosnoski developerWorks，2003 年 4 月）：理解各种类装入问题，范围从运行简单 Java 应用程序所需要的大量的类一直到可能在 J2EE 和类似的复杂架构中造成问题的类装入器冲突。
JVM 规范：从起源开始全面介绍了 JVM 类文件的格式和指令集。
IBM Diagnostics Guides：学习关于调试的更多知识。
Persistent Reusable JVM：在线图书，介绍 Persistent Reusable JVM 的概念，并提供编写在它们上面运行的中间件和应用程序的技术指南。
Java 技术专区：数百份 Java 编程各方面的文章。

获得产品和技术

IBM Java developer kits：在 IBM 的一些最流行的平台上创建和运行 J2SE 应用程序。

讨论

加入本文的论坛。(您也可以通过点击文章顶部或者底部的论坛链接参加讨论。)
developerWorks blogs：加入 developerWorks 社区。

回页首

作者简介

Simon Burns 是 Shiraz（可重置 JVM 和 IBM Java 共享类）组件的所有人，也是 IBM Hursley 实验室的 Java 技术团队负责人。他在 JVM 开发上工作了三年，专攻 Shiraz 组件和 z/OS 平台。他和 CICS 紧密合作，帮助他们利用这项技术。Simon 开发的 OSGi 框架是开放源码的 Eclipse Equinox 项目的一部分，已经集成到 Eclipse 3.1 中。他现在正在进行组件化的工作。


	Lakshmi Shankar 是英国 IBM Hursley 实验室的软件工程师。他为 IBM 工作两年多了，有广泛的经验，一直在 Hursley 实验室从事 Java 性能、测试和开发工作。他目前是 IBM Java 技术的类装入组件的所有人。他现在是信息管理团队的一名开发人员。