Jvm ：类加载的时机问题！静态方法中使用的类型为何在未调用时尝试加载？

Question

Jvm ：类加载的时机问题！静态方法中使用的类型为何在未调用时尝试加载？

Himmelt

14443648

发布于
2020-01-26

更新于
2020-01-26

代码：https://gitee.com/himmelt/Cla...

我只调用了Helper.init()这一个静态方法，为什么会尝试加载 TheClass这个类？

假如我把编译后的 TheClass.clss删除，就会报错：

Exception in thread "main" java.lang.NoClassDefFoundError: org/soraworld/b/TheClass
        at org.soraworld.Main.main(Main.java:7)
Caused by: java.lang.ClassNotFoundException: org.soraworld.b.TheClass
        at java.net.URLClassLoader.findClass(URLClassLoader.java:382)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
        ... 1 more

但是删除 BC.class和BD.class 就不会报错。

请教这一现象的原理，以及 类何时会被加载 ！

感谢！！

补充：

为什么？？参数类型的类，在没调用的时候也会被加载吗？
为什么偏偏只加载了 TheClass 这一个类？

[Loaded org.soraworld.Main from file:/D:/Desktop/Projects/ClassLoadTest/out/production/Test/]
[Loaded sun.launcher.LauncherHelper$FXHelper from D:\tools\jdk1.8\jre\lib\rt.jar]
[Loaded java.lang.Class$MethodArray from D:\tools\jdk1.8\jre\lib\rt.jar]
[Loaded java.lang.Void from D:\tools\jdk1.8\jre\lib\rt.jar]
[Loaded org.soraworld.c.Helper from file:/D:/Desktop/Projects/ClassLoadTest/out/production/Test/]
class org.soraworld.c.Helper
[Loaded org.soraworld.b.TheClass from file:/D:/Desktop/Projects/ClassLoadTest/out/production/Test/]
Helper#init
[Loaded java.lang.Shutdown from D:\tools\jdk1.8\jre\lib\rt.jar]
[Loaded java.lang.Shutdown$Lock from D:\tools\jdk1.8\jre\lib\rt.jar]

再补充：
这样就没问题了，不会加载相关类。Why ?

类加载机制 classloader

java jvm

阅读 4.4k

1 个回答

✓ 已被采纳

最近正好在看JVM相关的机制，这个现象挺有意思，研究了一下。首先你的代码比较乱，有很多无用信息，我整理了一下：

public class Main {
    static {
        System.out.println("Main static block");
    }

    public static void main(String[] args) {
        Helper.staticMethod();
    }
}

public class Helper {
    static {
        System.out.println("Helper static block");
    }

    public static void staticMethod() {
        System.out.println("Helper#staticMethod");
    }

    public void test(XXXManager ab, XXXSubInterface xxxSubInterface) {
        ab.setXXX(xxxSubInterface);
    }
}

public interface XXX {}

public interface XXXSubInterface extends XXX {}

public interface XXXManager {
    void setXXX(XXX xxx);
}

添加JVM -varbose参数，输出是：

[Loaded Main from file:/Users/mazhibin/project/java/loadclasstest/target/classes/]
Main static block
[Loaded Helper from file:/Users/mazhibin/project/java/loadclasstest/target/classes/]
[Loaded XXX from file:/Users/mazhibin/project/java/loadclasstest/target/classes/]
Helper static block
Helper#staticMethod

main方法执行Helper.staticMethod()，而staticMethod方法里面只有打印语句，所以理论上应该只要加载Helper就够了，为了什么会加载到XXX类，好，即使接受可以加载类的情况，为什么是XXX，而不是直接使用到的XXXManager或者XXXSubInterface。你提的问题大概是这个场景。

在说探索过程之前先说下最终结论：在验证Helper类时，校验到setXXX方法，会验证XXXSubInterface类型是否可以赋值到XXX类型，这个时候就会去加载XXX类，然后因为XXX是一个接口，代码中认为接口和Object类是一样的，什么类型都可以赋值给接口类型，所以就直接校验成功，就没有去加载XXXSubInterface类了。

然后在介绍一下类加载的过程。首先要清楚一点，“类加载”和“加载”是两个概念，“加载”是“类加载”（Class Loading）的一个步骤。类加载包含加载、链接、初始化这三个步骤，其中链接又分为验证、准备、解析这三个子步骤。加载是根据特定名称查找类或接口类型的二进制表示（Binary Representation），并由此二进制表示创建类或接口的过程。链接是为了让类或接口可以被 Java 虚拟机执行，而将类或接口并入虚拟机运行时状态的过程。类或接口的初始化是指执行类或接口的初始化方法<clinit>。

WX20200204-230905@2x.png

类加载复杂就复杂在这些步骤执行的时机，并且其中的子步骤还不一定按顺序执行，加载、验证、准备、初始化和卸载这5个阶段的顺序是固定的，需要按这个顺序开始（允许交叉），而解析则不一定，有可能在初始化之后才进行。

那什么时候会开始加载步骤？Java虚拟机规范没有强制要求，但是对于初始化阶段，则明确规定了5种情况需要对类进行初始化，分别是：

在执行下列需要引用类或接口的Java虚拟机指令时：new，getstatic，putstatic或invokestatic。这些指令通过字段或方法引用来直接或间接地引用其它类。执行上面所述的new指令，在类或接口没有被初始化过时就初始化它。执行上面的getstatic，putstatic或invokestatic指令时，那些解析好的字段或方法中的类或接口如果还没有被初始化那就初始化它。
在初次调用java.lang.invoke.MethodHandle实例时，它的执行结果为通过Java虚拟机解析出类型是2（REF_getStatic）、4（REF_putStatic）或者6（REF_invokeStatic）的方法句柄（§5.4.3.5）。
在调用JDK核心类库中的反射方法时，例如，Class类或java.lang.reflect包。
在对于类的某个子类的初始化时。
在它被选定为Java虚拟机启动时的初始类（§5.2）时。

结合上面说的，加载、验证、准备、初始化和卸载这5个阶段的顺序是固定的，需要按这个顺序开始（允许交叉），我们确定了初始化的时机，那么在初始化时或者之前，就要开始加载了。同时还有一点，也就是这个问题涉及到的场景，一个类在验证这个步骤时，会验证A类的字节码，其中可能会涉及到所以来的其他类，根据验证的具体需求，可能需要加载其他类。而这个问题具体的校验过程就是一个方法调用，涉及到类型转换赋值（传入子接口类型，需要转为父接口类型），这种情况下需要加载类型来判断是否可以进行赋值，按理是需要加载赋值左右两边的类型的，但是因为左边类型是接口，被认为都可以赋值，所以没有加载右边类型。

接下来说下是如何得到上述结论的，首先类加载的流程是Java虚拟机规范中有写的，可以看看。而具体为什么只加载了XXX类，则要调试JVM源码才能知道了。最近因为有看JVM源码，所以编译了并可以进行GDB调试，然后添加条件断点：break SystemDictionary::load_instance_class if strncmp(class_name._body, "XXX", 3) == 0，表示在加载XXX类的时候停下来，接着分析调用堆栈：

// 加载Main类
[Loaded Main from file:/root/jvm/openjdk/build/linux-amd64-debug/hotspot/outputdir/linux_amd64_compiler2/jvmg/mzb/]

// 执行Main的初始化方法
Main static block

// 因为要执行Helper.staticMethod()语句，触发加载Helper流程
[Loaded Helper from file:/root/jvm/openjdk/build/linux-amd64-debug/hotspot/outputdir/linux_amd64_compiler2/jvmg/mzb/]

// 接着断点停在了加载XXX接口的函数调用上
Breakpoint 1, SystemDictionary::load_instance_class (class_name=0x7ffff01a5338, class_loader=..., __the_thread__=
    0x7ffff0028000) at /root/jvm/openjdk/hotspot/src/share/vm/classfile/systemDictionary.cpp:1345
1345    instanceKlassHandle nh = instanceKlassHandle(); // null Handle

// 查看函数调用栈，分析为什么会需要加载XXX类（要从下往上看）
(gdb) bt
#0  SystemDictionary::load_instance_class (class_name=0x7ffff01a5338, class_loader=...,
    __the_thread__=0x7ffff0028000) at /root/jvm/openjdk/hotspot/src/share/vm/classfile/systemDictionary.cpp:1345
#1  0x00007ffff7578062 in SystemDictionary::resolve_instance_class_or_null (name=0x7ffff01a5338,
    class_loader=..., protection_domain=..., __the_thread__=0x7ffff0028000)
    at /root/jvm/openjdk/hotspot/src/share/vm/classfile/systemDictionary.cpp:755
#2  0x00007ffff7576a17 in SystemDictionary::resolve_or_null (class_name=0x7ffff01a5338, class_loader=...,
    protection_domain=..., __the_thread__=0x7ffff0028000)
    at /root/jvm/openjdk/hotspot/src/share/vm/classfile/systemDictionary.cpp:203
#3  0x00007ffff75765ad in SystemDictionary::resolve_or_fail (class_name=0x7ffff01a5338, class_loader=...,
    protection_domain=..., throw_error=true, __the_thread__=0x7ffff0028000)
    at /root/jvm/openjdk/hotspot/src/share/vm/classfile/systemDictionary.cpp:145
// 上面就开始了加载流程了

// 下文分析了这里是在校验XXXSubInterface类型是否可以赋值到XXX
// 下文分析了为什么需要加载XXX接口，而不需要加载XXXSubInterface接口
#4  0x00007ffff75df854 in VerificationType::is_reference_assignable_from (this=0x7ffff7fe5770, from=..., context=
    0x7ffff7fe60e0, __the_thread__=0x7ffff0028000)
    at /root/jvm/openjdk/hotspot/src/share/vm/classfile/verificationType.cpp:62
#5  0x00007ffff753bc37 in VerificationType::is_assignable_from (this=0x7ffff7fe5770, from=...,
    context=0x7ffff7fe60e0, __the_thread__=0x7ffff0028000)
    at /root/jvm/openjdk/hotspot/src/share/vm/classfile/verificationType.hpp:289
#6  0x00007ffff75eba80 in StackMapFrame::pop_stack (this=0x7ffff7fe5e20, type=..., __the_thread__=0x7ffff0028000)
    at /root/jvm/openjdk/hotspot/src/share/vm/classfile/stackMapFrame.hpp:181
#7  0x00007ffff75ea155 in ClassVerifier::verify_invoke_instructions (this=0x7ffff7fe60e0, bcs=0x7ffff7fe5dc0,
    code_length=18, current_frame=0x7ffff7fe5e20, this_uninit=0x7ffff7fe5f1f, return_type=..., cp=...,
    __the_thread__=0x7ffff0028000) at /root/jvm/openjdk/hotspot/src/share/vm/classfile/verifier.cpp:2064

// 下文分析了这里是因为验证Helper.test(LXXXManager;)V这个方法导致的加载XXX接口
#8  0x00007ffff75e64ea in ClassVerifier::verify_method (this=0x7ffff7fe60e0, m=...,
    __the_thread__=0x7ffff0028000) at /root/jvm/openjdk/hotspot/src/share/vm/classfile/verifier.cpp:1237
#9  0x00007ffff75e0e75 in ClassVerifier::verify_class (this=0x7ffff7fe60e0, __the_thread__=0x7ffff0028000)
    at /root/jvm/openjdk/hotspot/src/share/vm/classfile/verifier.cpp:312
#10 0x00007ffff75e04b1 in Verifier::verify (klass=..., mode=Verifier::ThrowException, should_verify_class=true,
    __the_thread__=0x7ffff0028000) at /root/jvm/openjdk/hotspot/src/share/vm/classfile/verifier.cpp:127
#11 0x00007ffff71f5d8c in instanceKlass::verify_code (this_oop=..., throw_verifyerror=true,
    __the_thread__=0x7ffff0028000) at /root/jvm/openjdk/hotspot/src/share/vm/oops/instanceKlass.cpp:214
// 上面的方法是验证的过程，也就是校验字节码是否正确，是否合法

#12 0x00007ffff71f6425 in instanceKlass::link_class_impl (this_oop=..., throw_verifyerror=true,
    __the_thread__=0x7ffff0028000) at /root/jvm/openjdk/hotspot/src/share/vm/oops/instanceKlass.cpp:321
#13 0x00007ffff71f5e73 in instanceKlass::link_class (this=0xfb01ab80, __the_thread__=0x7ffff0028000)

// 在类或接口被初始化之前，它必须被链接过，也就是经过验证、准备阶段，且有可能已经被解析完成了。所以上面是链接的流程
    at /root/jvm/openjdk/hotspot/src/share/vm/oops/instanceKlass.cpp:230
#14 0x00007ffff71f691f in instanceKlass::initialize_impl (this_oop=..., __the_thread__=0x7ffff0028000)
    at /root/jvm/openjdk/hotspot/src/share/vm/oops/instanceKlass.cpp:397
#15 0x00007ffff71f5cca in instanceKlass::initialize (this=0xfb01ab80, __the_thread__=0x7ffff0028000)
    at /root/jvm/openjdk/hotspot/src/share/vm/oops/instanceKlass.cpp:199

// 从下面几个调用栈，可以看出Helper.staticMethod()语句对应的invoke_static指令触发了解析流程
// 因为JVM规范说了，在执行new，getstatic，putstatic或invokestatic这些指令时，需要确保已经进行初始化流程
#16 0x00007ffff7383903 in LinkResolver::resolve_static_call (result=..., resolved_klass=...,
    method_name=0x7ffff01a4908, method_signature=0x7ffff0051f28, current_klass=..., check_access=true,
    initialize_class=true, __the_thread__=0x7ffff0028000)
    at /root/jvm/openjdk/hotspot/src/share/vm/interpreter/linkResolver.cpp:629
#17 0x00007ffff738599f in LinkResolver::resolve_invokestatic (result=..., pool=..., index=65537,
    __the_thread__=0x7ffff0028000) at /root/jvm/openjdk/hotspot/src/share/vm/interpreter/linkResolver.cpp:1077
#18 0x00007ffff738575c in LinkResolver::resolve_invoke (result=..., recv=..., pool=..., index=65537,
    byte=Bytecodes::_invokestatic, __the_thread__=0x7ffff0028000)
    at /root/jvm/openjdk/hotspot/src/share/vm/interpreter/linkResolver.cpp:1050
#19 0x00007ffff7239c58 in InterpreterRuntime::resolve_invoke (thread=0x7ffff0028000,
    bytecode=Bytecodes::_invokestatic)
    at /root/jvm/openjdk/hotspot/src/share/vm/interpreter/interpreterRuntime.cpp:686
#20 0x00007fffed039d15 in ?? ()
#21 0x00007fffed039bc3 in ?? ()
#22 0x00007ffff7fe6868 in ?? ()
#23 0x00000000fb01a170 in ?? ()
#24 0x00007ffff7fe68b8 in ?? ()
#25 0x00000000fb01a538 in ?? ()
#26 0x0000000000000000 in ?? ()

// 我们到第16号栈帧中，可以看出的确是正要执行Helper.staticMethod()方法
(gdb) f 16
#16 0x00007ffff7383903 in LinkResolver::resolve_static_call (result=..., resolved_klass=...,
    method_name=0x7ffff01a4908, method_signature=0x7ffff0051f28, current_klass=..., check_access=true,
    initialize_class=true, __the_thread__=0x7ffff0028000)
    at /root/jvm/openjdk/hotspot/src/share/vm/interpreter/linkResolver.cpp:629
629       resolved_klass->initialize(CHECK);
(gdb) p Klass::cast(current_klass.obj())->external_name()
$1 = 0x7fffcc002548 "Main"
(gdb) p *method_name._body@method_name._length
$5 = "staticMethod"

// 我们到第8号栈帧中，可以看出是因为验证Helper.test(LXXXManager;)V这个方法导致的加载XXX接口
(gdb) f 8
#8  0x00007ffff75e64ea in ClassVerifier::verify_method (this=0x7ffff7fe60e0, m=...,
    __the_thread__=0x7ffff0028000) at /root/jvm/openjdk/hotspot/src/share/vm/classfile/verifier.cpp:1237
1237                &this_uninit, return_type, cp, CHECK_VERIFY(this));
(gdb) p m->name_and_sig_as_C_string()
$6 = 0x7fffcc002568 "Helper.test(LXXXManager;)V"

// 我们到第4号栈帧中，可以看出是在校验XXXSubInterface类型是否可以赋值到XXX
(gdb) f 4
#4  0x00007ffff75df854 in VerificationType::is_reference_assignable_from (this=0x7ffff7fe5770, from=...,
    context=0x7ffff7fe60e0, __the_thread__=0x7ffff0028000)
    at /root/jvm/openjdk/hotspot/src/share/vm/classfile/verificationType.cpp:62
62          Handle(THREAD, klass->protection_domain()), true, CHECK_false);
(gdb) p *from.name()._body@from.name()._length
$10 = "XXXSubInterface"
(gdb) p *name()._body@name()._length
$11 = "XXX"

上面分析出了加载是因为验证的流程，具体触发加载的验证代码如下，是验证赋值操作是否可以成功的：

// hotspot/src/share/vm/classfile/verificationType.cpp
bool VerificationType::is_reference_assignable_from(
    const VerificationType& from, ClassVerifier* context, TRAPS) const {
  instanceKlassHandle klass = context->current_class();
  if (from.is_null()) {
    // null is assignable to any reference
    return true;
  } else if (is_null()) {
    return false;
  } else if (name() == from.name()) {
    return true;
  } else if (is_object()) {
    // 如果赋值语句左边类型是对象，判断是否是Object，如果是那都可以赋值成功，返回true
    // We need check the class hierarchy to check assignability
    if (name() == vmSymbols::java_lang_Object()) {
      // any object or array is assignable to java.lang.Object
      return true;
    }

    // 否则需要把左边类型加载进来 <=========================== 加载行为发生在这里
    klassOop obj = SystemDictionary::resolve_or_fail(
        name(), Handle(THREAD, klass->class_loader()),
        Handle(THREAD, klass->protection_domain()), true, CHECK_false);
    KlassHandle this_class(THREAD, obj);

    // 如果左边类型是接口
    if (this_class->is_interface()) {
      // 这里注释说明了，认为接口和Object一样，都可以赋值成功所以返回true
      // We treat interfaces as java.lang.Object, including
      // java.lang.Cloneable and java.io.Serializable
      return true;
    } else if (from.is_object()) {
      // 否则要把赋值赋予右边的类型也加载进来
      klassOop from_class = SystemDictionary::resolve_or_fail(
          from.name(), Handle(THREAD, klass->class_loader()),
          Handle(THREAD, klass->protection_domain()), true, CHECK_false);
      return instanceKlass::cast(from_class)->is_subclass_of(this_class());
    }
  } else if (is_array() && from.is_array()) {
    VerificationType comp_this = get_component(context, CHECK_false);
    VerificationType comp_from = from.get_component(context, CHECK_false);
    if (!comp_this.is_bogus() && !comp_from.is_bogus()) {
      return comp_this.is_assignable_from(comp_from, context, CHECK_false);
    }
  }
  return false;
}

这样就分析完了，你尝试把XXX和XXXSubInterface改成class，可以发现两个都会被加载，符合上面这个代码的逻辑。

撰写回答

你尚未登录，登录后可以

和开发者交流问题的细节
关注并接收问题和回答的更新提醒
参与内容的编辑和改进，让解决方法与时俱进

被 1 篇内容引用

JVM源码分析-类加载场景实例分析

推荐问题

Jvm ：类加载的时机问题！静态方法中使用的类型为何在未调用时尝试加载？

你尚未登录，登录后可以

小网站有必要将图片放到阿里云OSS存储吗？

post http重定向到https会改变请求的method类型吗?

Mybatis+查询的结果集难道还要经过二次处理？不会吧？怎么优化？

在计算机中如何翻译`pattern`？

Spring中的两个疑惑?

Redis 如何有效防止缓存穿透、击穿和雪崩问题？

springboot业务代码能否动态加载和更新？

Jvm ：类加载的时机问题！静态方法中使用的类型为何在未调用时尝试加载 ？

你尚未登录，登录后可以

小网站有必要将图片放到阿里云OSS存储吗？

post http重定向到https会改变 请求的method类型吗?

Mybatis+查询的结果集难道还要经过二次处理？不会吧？怎么优化？

在计算机中如何翻译`pattern`？

Spring中的两个疑惑?

Redis 如何有效防止缓存穿透、击穿和雪崩问题？

springboot业务代码能否动态加载和更新？

Jvm ：类加载的时机问题！静态方法中使用的类型为何在未调用时尝试加载？

post http重定向到https会改变请求的method类型吗?