JVM-15-类的加载过程详解

概述

在java中数据类型分为基本数据类型和引用数据类型，基本数据类型有虚拟机预先定义，引用数据类型则需要执行类的加载

从class文件到加载到内存中的类到类卸载出内存为止，整个生命周期包括如下七个阶段：

从程序中类的使用过程看：

加载-Loading

加载完成的操作

• 所谓加载 ，就是将java类的字节码文件加载到机器内存中，并在内存中构建出java类的原型–类模板对象（java类在jvm内存中的一个快照），jvm将从字节码文件中解析出的常量池、类字段、类方法等信息存储到类模板中，这样jvm在运行期边能通过类模板而获取 java类中的任何信息，能够对java类的成员变量进行遍历，也能进行java方法的调用
• 反射机制即基于这一基础，如果jvm没有将java类的声明信息存储起来，则jvm在运行期也无法反射
• 加载阶段，就是查找并加载类的二进制数据，生成class的实例
• 在加载类时，java虚拟机必须完成以下三件事情
  • 通过类的全名获取类的二进制数据流
  • 解析类的二进制数据流为方法区内的数据结构（java类模型）
  • 创建java.lang.Class类的实例，表示该类型，作为方法区这个类的各种数据的访问入口

二进制流的获取方式

对于类的二进制数据流，虚拟机可以通过多种途径产生或获得（只要所读取的字节码符合jvm规范即可）

• 虚拟机可能通过文件系统读入一份class后缀的文件（最常见）
• 读入jar、zip包，提取类文件
• 事先存放在数据库中的类的二进制数据
• 使用类似于http之类的协议通过网络进行加载
• 运行时生成一段二进制信息等

在获取到类的二进制信息后，java虚拟机就会处理这些数据，并最终转为一个java.lang.Class的实例

如果输入数据不是ClassFile的结构，则会抛出ClassFormatError

类模型和Class实例的位置

• 类模型的位置
  • 加载的类在jvm中创建相应的类结构，类结构会存储在方法区（永久代、元空间）
• Class实例的位置
  • 类将.class文件加载至元空间后，会在堆中创建一个java.lang.Class对象，用来封装类位于方法区内的数据结构，该class对象是在加载类的过程中创建的，每个类都对应有一个class类型的对象

外部可以通过访问代表order类的class对象类获取order的类数据结构

class类的构造方法是私有的，只有jvm能创建

java.lang.class实例是访问类型元数据的接口，也是实现反射的关键数据、入口、通过class类 提供的接口。可以获得 目标类所关联的class文件中具体的数据结构

数组类的加载

创建数组类的情况稍微有些特殊，因为数组类本身并不是由类的加载器负责创建，而是由jvm在运行时根据需要而直接创建的，但数组的元素类型仍然需要依靠类的加载器去创建，

创建数组类的过程：

• 如果数组的元素类型是引用类型，那么就遵循定义的加载过程递归加载和创建数组a的元素类型
• jvm使用指定的元素类型和数组维度来创建新的数组类

如果数组元素的元素类型是引用类型，数组类的可访问性就由元素类型的可访问性决定，否则数组类的可访问性将被缺省定义为 public

链接-Linking

验证-Verification

当类加载到系统后，就开始链接操作，验证是链接操作的第一步

目的 是保证加载的字节码是合法、合理并符合规范的

大体上java虚拟机需要做以下检查：

整体说明：

• 格式验证回合加载阶段一起执行，验证通过后，类加载器才会成功将类的二进制数据信息加载到方法区中
• 格式验证之外的验证操作将会 在方法区中执行

链接阶段的验证虽然拖慢了加载速度，但是它避免了再字节码 运行时还需要进行各种检查

• 格式验证：是否已魔数0xCAFFBABE开头，主版本号和副版本号是否在当前java虚拟机支持的范围内，数据中的每一项是否都有正确的格式

• java虚拟机会进行字节码的语义检查，但凡在语义上不符合规范的，虚拟机也不会给予验证通过，比如

  • 是否所有的类都有父类的存在（在java里，除了Object外，其他类都应该有父类）
  • 是否一些被定义为final的方法或者类被重写或继承了
  • 非抽象类是否实现了所有抽象方法或接口
  • 是否 存在不兼容的情况，比如除了返回名之外其他的都相同

• 字节码验证：字节码验证也是验证过程中最为复杂的一个过程，他试图通过对字节码流的分析，判断字节码是否可以被正确的执行，比如：

  • 在字节码的执行过程中，是否会跳转到一条不存在的指令
  • 函数的调用是否传递了正确类型的参数
  • 变量的赋值是不是给了 正确的数据类型等

  栈映射帧就是在这个阶段，用于检查在特定的字节码处，其局部变量表和操作数栈是否有着正确的数据类型，但遗憾的是，不能100%准确的判断字节码是否可以被安全执行，因此，该工作只是尽可能的检查出可以预知的明显的问题，如果在这个阶段也无法通过检查，虚拟机也不会正确装载这个类，但是通过了 这个检查 ，也不能说明这个类完全没有问题

在前三次检查中已经排除了文件格式错误、语义错误、以及字节码的不正确性，但是依然不能保证类是没有问题的

• 符号引用的验证：class文件在其常量池会通过字符串记录自己将要使用的其他类或方法，因此在 验证阶段，虚拟机就会检查这些类或方法是存在的，并且当前类有权限 访问这些数据，如果一个需要使用类无法在系统中找到，则会抛出NoClassDefFoundError，如果一个方法无法被找到，就会抛出NoSuchMethodErrot
  • 此阶段在解析环节才会执行

准备-Preparation

为类的静态变量分配内存，并将其初始化为默认值

当一个类通过验证时，虚拟机就会进入准备阶段，在这个阶段，虚拟机就会为这个类分配相应的内存空间，并设置默认初始值，java虚拟机为各类型变量默认的初始值如下：

java并不支持boolean类型，对于boolean类型，其内部实现是int，由于int的默认值是 0，故 boolean的默认值就是false

• 这里不包含基本数据类型的字段用static final修饰的情况，因为final在编译的时候就会分配了，准备阶段会显示赋值

• 这里不会为实例变量 分配初始化，类变量 会分配在方法区中，而实例变量是会随着对象一起分配到java堆中

• 这个阶段并不会向初始化阶段那样会有初始化或者代码被执行

解析-Resolution

将类 、接口、字段和方法的符号引用转为直接引用

• 符号引用就是一些字面量的引用，和虚拟机的内部数据结构和内存布局无关，比较容易理解的 就是在class文件中，通过常量池进行了大量的符号引用，但是在程序实际运行时，只有符号引用是不够的，比如当如下println()方法被调用时，系统需要明确知道该方法的位置
• 输出操作System.out.println()对应的字节码：invokevirtual #24 <java/io/PrintStream.println>

以方法为例，java虚拟机为每个类都准备了一张方法表，将其所有的方法都列在表中，当需要调用一个类的方法的时候，只要知道这个方法在方法表中的偏移量就可以直接调用该方法，通过解析操作，符号引用就可以转变为目标方法在类中方法表中的位置，从而使方法被成功调用

所谓解析就是将符号引用转为直接引用，也就是得到类、字段、方法在内存中的 指针或者偏移量，因此，可以说如果直接引用存在，那么可以肯定系统中存在该类、方法或字段，但只存在符号引用，不能确定系统中一定存在该结构

不过java虚拟机规范并没有明确要求解析阶段一定要按照顺序执行，在hotspot虚拟机中加载、验证、准备、初始化会按照顺序有条不紊的执行，但链接阶段中的解析操作往往会伴随着jvm在执行完初始化之后再执行

• 字符串复习
  • 当在java代码中直接使用字符串常量时，就会在类中出现CONSTANT_String，表示字符串常量，并引用一个CONSTANT_UTF8的常量项，在java虚拟机内部运行中的常量池中，会维护一张字符串拘留表（intern），会保留所有出现过的 字符串常量，并且没有重复项，只要以CONSTANT_String形式出现的字符串也都会在这张表中，使用 String.intern()方法可以得到一个字符串在拘留表中的引用，因为该表没有重复项，所以任何字面相同的字符串的String.intern()方法返回总是相等的

初始化-Initialization

为类的静态变量赋予正确的初始值

• 类的初始化是类装载的最后一个阶段，如果前面的步骤都没有问题，那么表示可以顺利装载到系统中，此时，类才会开始执行java字节码（即到了初始化阶段，才开始真正执行类中定义的java代码）

  • 初始化阶段的重要工作时执行类的初始化方法：<clinit>()方法
  • 该方法仅能由java编译器生成并有jvm调用，程序开发者无法自定义一个同名的方法，更无法直接在java程序中调用改方法，虽然该方法也是由字节码指令所组成
  • 是由类静态成员的赋值语句以及 static语句块合并产生的

• 在加载一个类之前，虚拟机总是会试图加载该类的父类，因此父类的<clinit>()方法总是在子类的<clinit>()方法之前调用，也就是说父类的static块优先级高于子类

• java编译器并不会为所有的类都产生<clinit>()方法，以下为字节码中不包含<clinit>()方法的类：

  • 一个类中并没有声明任何的类变量，也没有静态代码块
  • 一个类中声明类变量，但是没有明确使用 类变量的初始化语句以及静态代码块来执行初始化操作时
  • 一个类中包含static final修饰的基本数据类型字段，这些类字段初始化语句采用编译时常量表达式

  

• 关于static final

  

  • 结论：
    • 在链接阶段的准备环节赋值
      • 对于基本数据类型来说，如果使用static final修饰，则显示赋值（直接赋值常量，而非调用方法）通常是在该阶段赋值
      • 对String来说，如果使用字面量 方式赋值，使用static final修饰，则显示赋值通常是在该阶段赋值
    • 在初始化环节进行赋值
      • 排除上述准备环节赋值的情况，其余情况都是
  • 就是说：如果在准备阶段能够确定下来使用static final修饰的变量的值 的都是在准备阶段赋值，不能确定的就在初始化阶段赋值，没有用final修饰只是static修饰的均在初始化阶段赋值

• <clinit>()的线程安全性问题

  • 对<clinit>()方法的调用，也就是类的初始化，虚拟机会在内部确保其多线程环境中的安全性
  • 虚拟机会保证一个类的<clinit>()方法在多线程环境中被正确的加锁、同步，如果多线程同时去 初始化一个类，那么只会有一个线程去执行这个类的<clinit>()方法，其他线程都要阻塞等待，知道活动线程的<clinit>()方法完毕
  • 正式因为函数<clinit>()带锁线程安全的，因此如果在一个类的<clinit>()方法中有耗时很长的操作，就可能造成多个线程阻塞 ，引发死锁，并且这种死锁是很难发现的，因为看起来他们并没有可用的锁信息
  • 如果之前的线程成加载了类，则等在队列中的线程就没有机会再执行<clinit>()方法了，那么当需要使用这个类是，虚拟机会直接返回给它已经准备好的信息

• 类的初始化情况：主动使用和被动使用

  • 主动使用：class只有在必须要首次使用时才会被装载，java虚拟机不会无条件的装载class类型。Java虚拟机规定，一个类或接口在初次使用前，必须要进行初始化，这里指的使用是主动使用，主动使用只有下列几种情况（即如果出现如下情况则会对类进行初始化操作，而初始化 操作之前的加载、验证、准备已经完成）

    • 当创建一个类的实例时，比如使用new关键字，或者通过反射、克隆、反序列化
    • 当调用类的静态方法时，即当使用了字节码invokestatic指令
    • 当使用类、接口的静态字段时（final修饰特殊考虑）比如使用getstatic或putstatic指令
    • 当使用java.lang.reflect包中的方法反射类的方法时，比如Class.forName(“com.ty.Test”)
    • 当初始化子类时，如果发现 父类还没有进行过初始化，则需要先触发父类的初始化

    补充说明：

    这条规则并不适用于接口

    • 在初始化一个类时，并不会先初始化它所实现的接口
    • 在初始化一个接口时，并不会先初始化它的父接口

    因此一个父接口并不会因为他的子接口或实现类的初始化而初始化，只有当程序首次使用特定接口的静态字段时，才会导致 该接口的初始化

    • 如果一个接口定义了default方法，那么直接实现或者间接实现该接口的类的初始化，该接口要在其之前被初始化
    • 当虚拟机启动时，用户需要指定一个需要执行的主类（包含main()方法的那个类），虚拟机会先初始化这个主类

    jvm启动的时候通过引导类加载器加载一个初始类，这个类在调用psvm方法之前被链接和初始化，这个方法的执行将依次导致所需的类加载、链接和初始化

    • 当初次调用MethodHandle实例时，初始化该MethodHandle指向的方法所在的类（涉及解析REF_getStatic、REF_putStatic、REF_invokeStatic方法句柄对应的类）

  • 被动使用：除了以上情况外，其余均属于被动使用，被动使用不会引起类的初始化，也就是说并不是在代码中出现的类就一定会被加载或初始化

    • 当访问一个静态字段时，只有真正声明这个字段的类才会被初始化
      • 当通过子类引用父类的静态变量，不会导致子类被初始化
    • 通过数组定义类引用，不会触发此类的初始化
    • 引用常量不会触发此类或接口的初始化，因为常量在链接阶段就已经被显示赋值了
    • 调用ClassLoder类的loadClass()方法加载一个类，并不是对类的主动使用，不会导致类的初始化

使用-Using

就是平常开发时的各种使用

卸载-Unloading

• 回顾：方法区的垃圾回收

  • 方法区的垃圾收集主要是：常量池中废弃常量和不再使用的类型两部分
  • Hotspot虚拟机对常量池的回收策略是很明确的，只要常量池中的常量没有被任何地方引用，就可以被回收
  • 判定一个常量是否”废弃“还是相对简单，而要判断一个类型是否不再使用，需要同时满足以下三个条件：
    • 该类的所有实例都已经被回收，也就是java堆中不存在该类及其任何派生子类的实例
    • 加载该类的类加载器已经被回收，这个条件除非是经过精心设计的可替换类加载器的场景，如OSGI、JSP的重加载等，否则很难达成
    • 该类对应的java.lang.class对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法
  • java虚拟机被允许对满足上述三个条件的无用类进行回收，这里说的仅仅是“被允许”，而并不是和对象一样，没有引用了必然会回收

• 类、类的加载器、类的实例之间的引用关系

  • 在类加载器的内部实现中，用一个java集合来存放所加载类的引用，另一方面，一个class对象 总是会引用它的类加载器，调用class对象的getClassLoader()方法，就能获得他的类加载器，由此可见，代表某个类的class实例和其类的加载器之间是双向关联的
  • 一个类的实例总是引用代表这个类的class对象，在object类中定义了getClass()方法，这个方法返回代表对象所属类的class对象的引用，此外，所有的java类都有一个静态属性class，它引用代表这个类的class对象

• 类的生命周期

  • 当Sample类被加载链接初始化后，它的生命周期就开始了，当代表sample类的class对象不再被引用，即 不可触及时，class对象就会结束生命周期，sample类在方法区内的数据也会被卸载，从而结束sample类的生命周期
  • 一个类何时结束生命周期，取决于代表它的class对象何时结束生命周期

loader1变量和obj变量间接应用代表sample的class对象，而objclass则直接引用它

如果程序运行中，上图三个引用变量都设置为空，此时sample对象结束生命周期，myclassloader对象结束生命周期，代表sample类的class对象也结束生命周期，sample类在方法区内的二进制数据被卸载

当再次有需要时，会检查 sample类的class对象是否存在，如果存在会直接使用，不用重新加载，如果不存在sample类会被重新加载，在java虚拟机的堆区会生成一个新的代表 sample类的class实例

• 类的卸载
  • 启动类加载器加载的类型在整个运行期间是不可能被卸载的（jvm和jls规范）
  • 被系统类加载器和扩展类加载器加载的类型在运行期间不太可能被卸载，因为系统类加载器实例或者扩展类的实例基本上在整个运行期间总能直接或间接的访问的到，其达到不可触及的可能性极小
  • 被开发者自定义的类加载器实例加载的类型只有在很简单的上下文环境中才能被卸载，而且一般还要借助于强制调用虚拟机的垃圾收集功能才可以做到，稍微复杂一点的场景中（比如很多用户在 开发自定义类加载器实例的时候采用缓存的策略以提高系统性能），被加载的类型在运行期间也是几乎不太可能被卸载的（至少卸载时间是不确定的）
  • 综上三点，一个已经加载的类型被卸载的几率很小至少被卸载的时间是不确定的，同时开发者在开发代码的时候，不应该对虚拟机的类型卸载做任何假设的前提下，来实现系统中的特点功能