JVM类加载机制

Posted 打瞌睡的布偶猫

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了JVM类加载机制相关的知识,希望对你有一定的参考价值。

类加载机制

当需要某个类的时候,Java虚拟机会加载 .class 文件,并创建对应的class对象,将class文件加载到虚拟机的内存,这个过程被称为类的加载。

类加载的时机

  • 隐式加载 new 创建类的实例,
  • 显式加载:loaderClass,forName等
  • 访问类的静态变量,或者为静态变量赋值
  • 调用类的静态方法
  • 使用反射方式创建某个类或者接口对象的Class对象
  • 初始化某个类的子类
  • 直接使用java.exe命令来运行某个主类

类加载过程

下图展示了一个类的完整生命周期,虚线框内的部分为类加载的过程。

image-20210320164851353

  • 加载——在这个阶段,JVM 的主要目的是将字节码转化为二进制字节流加载到内存中,接着会为这个类在 JVM 的方法区创建一个对应的 Class 对象,这个 Class 对象就是这个类各种数据的访问入口。这一阶段主要完成以下三件事:
    • 通过全类名获取定义此类的二进制字节流(比较常见的就是从 ZIP 包中读取(日后出现的JAR、EAR、WAR格式的基础)、其他文件生成(典型应用就是JSP)等等)
    • 将字节流所代表的静态存储结构转换为方法区的运行时数据结构
    • 在内存中生成一个代表该类的 Class 对象,作为方法区这些数据的访问入口
  • 验证 —— 确保class文件的字节流中包含信息符合当前虚拟机要求,不会危害虚拟机自身的安全,主要包括四种验证:文件格式的验证,元数据的验证,字节码验证,符号引用验证。
  • 准备 —— 该阶段是正式为类变量分配内存并设置类变量初始值的阶段,这些内存都将在方法区中分配
    • 这时候进行内存分配的仅包括类变量(static),而不包括实例变量,实例变量会在对象实例化时随着对象一块分配在 Java 堆中。
    • 这里所设置的初始值"通常情况"下是数据类型默认的零值(如0、0L、null、false等),比如我们定义了public static int value=111 ,那么 value 变量在准备阶段的初始值就是 0 而不是111(初始化阶段才会赋值)。特殊情况:比如给 value 变量加上了 final 关键字public static final int value=111 ,那么准备阶段 value 的值就被赋值为 111。
  • 解析 —— 解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程。解析动作主要针对类或接口、字段、类方法、接口方法、方法类型、方法句柄和调用限定符7类符号引用进行。得到类或者字段、方法在内存中的指针或者偏移量。
  • 初始化 —— 初始化是类加载的最后一步,也是真正执行类中定义的 Java 程序代码(字节码),初始化阶段是执行初始化方法 <clinit> ()的过程。只有主动去使用类才会初始化类,类初始化的触发条件:
    • 当遇到 new 、 getstatic、putstatic或invokestatic 这4条字节码指令时,比如 new 一个类,读取一个静态字段(未被 final 修饰)、或调用一个类的静态方法时。
    • 使用 java.lang.reflect 包的方法对类进行反射调用时如Class.forname("..."),newInstance()等等。 如果类没初始化,需要触发其初始化。
    • 初始化一个类,如果其父类还未初始化,则先触发该父类的初始化。
    • 当虚拟机启动时,用户需要定义一个要执行的主类 (包含 main 方法的那个类),虚拟机会先初始化这个类。
    • MethodHandle和VarHandle可以看作是轻量级的反射调用机制,而要想使用这2个调用, 就必须先使用findStaticVarHandle来初始化要调用的类。
    • 「补充」 当一个接口中定义了JDK8新加入的默认方法(被default关键字修饰的接口方法)时,如果有这个接口的实现类发生了初始化,那该接口要在其之前被初始化。

类加载器

JVM 中内置了三个重要的 ClassLoader,除了BootstrapClassLoader 其他类加载器均由 Java 实现且全部继承自java.lang.ClassLoader

  1. BootstrapClassLoader(启动类加载器) :最顶层的加载类,由C++实现,负责加载 %JAVA_HOME%/lib目录下的jar包和类或者被 -Xbootclasspath参数指定的路径中的所有类。
  2. ExtensionClassLoader(扩展类加载器) :主要负责加载目录 %JRE_HOME%/lib/ext 目录下的jar包和类,或被 java.ext.dirs 系统变量所指定的路径下的jar包。
  3. AppClassLoader(应用程序类加载器) :面向我们用户的加载器,负责加载当前应用classpath下的所有jar包和类。
  4. 自定义类加载器,除了 BootstrapClassLoader ,其他类加载器均由 Java 实现且全部继承自java.lang.ClassLoader。如果我们要自定义自己的类加载器,很明显需要继承 ClassLoader

双亲委派模型

原理

每一个类都有一个对应它的类加载器。系统中的类加载器在协同工作的时候会默认使用 双亲委派模型 。即在类加载的时候,系统会首先判断当前类是否被加载过。已经被加载的类会直接返回,否则才会尝试加载。如果一个类加载器收到了类加载请求,它并不会自己先去加载,而是把这个请求委托给父类的加载器去执行,如果父类加载器还存在其父类加载器,则进一步向上委托,依次递归,请求最终将到达顶层的引导类加载器,如果父类加载器可以完成类加载任务,就成功返回,倘若父类加载器无法完成此加载任务,子加载器才会尝试自己去加载,这就是双亲委派模式。

img

好处

双亲委派模型保证了Java程序的稳定运行,可以避免类的重复加载,当父类加载器已经加载了该类时,就没有必要子类加载器再加载一次(JVM 区分不同类的方式不仅仅根据类名,相同的类文件被不同的类加载器加载产生的是两个不同的类),也保证了 Java 的核心 API 不被篡改。如果没有使用双亲委派模型,而是每个类加载器加载自己的话就会出现一些问题,比如我们编写一个称为 java.lang.Object 类的话,那么程序运行的时候,系统就会出现多个不同的 Object

参考来源

以上是关于JVM类加载机制的主要内容,如果未能解决你的问题,请参考以下文章

JVM笔记二双亲委派机制

图解JVM类加载机制和双亲委派模型

入门篇JVM类加载机制

JVM 类加载机制与加载过程

JVM类加载机制详解JVM类加载过程

JVM类加载机制详解JVM类加载过程