为什么NoClassDefFoundError由静态字段初始化失败引起?

| 这是一个有趣的Java问题。 以下简单的Java程序包含由方法静态初始化的静态字段。实际上,我强迫计算intiailize值的方法引发NullPointException,当我访问这样的静态字段时,将引发NoClassDefFoundError。看来VM对待Class不完整。 但是当我访问该类时,它仍然可用; 有谁知道为什么?
class TestClass {
    public static TestClass instance = init();

    public static TestClass init() {
       String a = null;
       a.charAt(0); //force a null point exception;
       return new TestClass();
    }
}

class MainClass {
    static public void main(String[] args) {
       accessStatic(); // a ExceptionInInitializerError raised cause by NullPointer
       accessStatic(); //now a NoClassDefFoundError occurs;

       // But the class of TestClass is still available; why?
       System.out.println(\"TestClass.class=\" + TestClass.class);
    }

    static void accessStatic() {
        TestClass a;

        try {
            a = TestClass.instance; 
        } catch(Throwable e) {
            e.printStackTrace();
        }
    }   
}
    
已邀请:
        这些问题的答案通常埋在规范中的某个位置...(第12.4.2节) 初始化类时会发生什么: 步骤1-4与此问题无关。这是引发异常的步骤5:   
5
。如果Class对象处于错误状态,则无法进行初始化。释放对Class对象的锁定,并引发NoClassDefFoundError。 6-8继续初始化,8执行初始化程序,通常发生在步骤9中:   
9
。如果初始化程序的执行正常完成,则锁定此Class对象,将其标记为完全初始化,通知所有等待的线程,释放锁,然后正常完成此过程。 但是我们在初始化器中出现了一个错误,因此:   
10
否则,初始化器必须通过抛出一些异常E来突然完成。如果E的类不是Error或其子类之一,则以E作为参数创建ExceptionInInitializerError类的新实例,并在适当的位置使用此对象E在接下来的步骤中。但是,如果由于发生OutOfMemoryError而无法创建ExceptionInInitializerError的新实例,请在后续步骤中使用OutOfMemoryError对象代替E。 是的,我们看到了空指针异常的4/5 b / c。   
11
。锁定Class对象,将其标记为错误,通知所有正在等待的线程,释放锁定,并以原因E或其上一步中所述的替换突然结束此过程。 (由于某些早期实现中的缺陷,类初始化期间的异常被忽略,而不是引起此处所述的ExceptionInInitializerError。) 然后将该类标记为错误,这就是为什么我们第二次从步骤5中获得异常。   令人惊讶的部分是第三份打印输出,显示出
MainClass
中的
TestClass.class
实际上持有对物理
Class
对象的引用。 可能是因为ѭ9仍然存在,所以它被标记为错误。它已经被加载和验证。     
        是的,这通常就是为什么加10英镑的原因。它的名字很邪恶,仅此而已。它应该被命名为“类初始化失败的异常”。 由于名称的误导,导致此错误的Java程序员浪费了数百个人的年头,试图弄清为什么找不到该类。 每当您看到此异常时,都应该向上检查日志,并尝试找出类初始化失败时的根本原因。     
           当我访问这样的静态字段时,将引发NoClassDefFoundError。看来VM对待Class不完整。 那是对的 ...   但是当我访问课程时,它仍然可用 是。 该类加载器尚未尝试删除损坏的类,因为: 很难做到的 安全地做是非常困难的, 它将使JVM处于一种状态,在这种状态下,应用程序很容易浪费大量时间重复加载和重新加载损坏的代码,并且 规格说明(或至少暗示)它不应该;有关详细信息,请参见其他答案。 要进入可见此不一致的状态,您的应用程序必须捕获ѭ11(或超类)并尝试从中恢复。众所周知,“ 12”个例外通常无法恢复;即,如果您尝试恢复,则JVM可能最终处于不一致状态。这就是在这里发生的……关于正在加载/初始化的类。     
        它是受限制的 http://psc.informatik.uni-jena.de/languages/Java/javaspec-3.pdf的8.3.2.2     

要回复问题请先登录注册