概述
在Java中数据类型分为基本数据类型和引用数据类型，基本数据类型由虚拟机预先定义，引用数据类型则需要进行类的加载。
按照Java虚拟机规范，从Class文件到加载到内存中的类，到类卸载出内存为止，它的整个生命周期包括如下7个阶段：
其中，验证、准备、解析3个部分统称为链接（Linking）
相关面试题
- 描述一下JVM加载Class文件的原理机制？
- Java 类加载的过程？
- Java 类加载的时机？
- 简述 Java 类加载机制？
Loading（加载）阶段
加载的理解
所谓的加载，简而言之就是将Java类的字节码文件加载到机器内存中，并在内存中构建出Java类的原型–类模板对象。所谓类模板对象，起始就是Java类在JVM内存中的一个快照，JVM将从字节码文件中解析出常量池，类字段、类方法等信息存储到类模板中，这样JVM在运行期便能通过类模板而获得Java类中的任意信息，能够对Java类的成员变量进行遍历，也能进行Java方法的调用。
反射机制即基于这一基础。如果JVM没有将Java类的声明信息存储起来，则JVM在运行期也无法反射。
加载完成的操作
加载阶段，简而言之，查找并加载类的二进制数据，生成Class的实例。
在加载类时，Java虚拟机必须完成以下3件事情：
- 通过类的全名，获取类的二进制数据流。
- 解析类的二进制数据流为方法区内的数据结构（Java类模板）。
- 创建java.lang.Class类的实例，表示该类型。作为方法区这个类的各种数据访问的入口。
二进制流的获取方式
对于类的二进制数据流，虚拟机可以通过多种途径产生或获得。（只要所读取的字节码符合JVM规范即可）
- 虚拟机可以通过文件系统读入一共class后缀的文件（最常见）
- 读取jar、zip等归档数据包，提取类文件。
- 事先存放在数据库中的类的二进制数据
- 使用类似于HTTP之类的协议通过网络进行加载
- 在运行时生成一段Class的二进制信息等
在获取到类的二进制信息后，Java虚拟机就会处理这些数据，并最终转为一共java.lang.Class的实例。
如果输入数据不是ClassFile的结构，则会抛出ClassFormatError。
类模型与Class实例的位置
- 类模型的位置
加载的类在JVM中创建相应的类结构，类结构会存储在方法区（JDK1.8之前，是永久代；JDK1.8之后，是元空间）。 - Class实例的位置
类将.class文件加载至元空间之后，会在堆中创建一共Java.lang.Class对象，用来封装类位于方法区内的数据结构，该Class对象是在加载类的过程中创建的，每个类都对应有一个Class类型的对象。 - Class类的构造方法是私有的，只有JVM能够创建。java.lang.Class实例是访问类型元数据的接口，也是实现反射的关键数据、入口。通过Class类提供的接口，可以获得目标类所关联的.class文件中具体的数据结构：方法、字段等信息。
数组类的加载
创建数组类的情况稍微有一些特殊，因为数组本身并不是由类加载器负责创建，而是由JVM在运行时根据需要而直接创建的，但是数组的元素类型仍然需要依靠类加载器去创建。创建数组类的过程：
- 如果数组的元素类型是引用类型，那么就遵循定义的加载过程递归加载和创建数组的元素类型；
- JVM使用指定的元素类型和数组维度来创建新的数组类。
如果数组的类型是引用类型，数组类的可访问性就由元素类型的可访问性决定。否则数组类的可访问性将被缺省定义为public。
Linking（链接）阶段
验证阶段（Verification）
当类加载到系统后，就开始链接操作，验证时链接操作的第一步。它的目的是保证加载的字节码是合法、合理并符合规范的。
验证的步骤比较复杂，实际要验证的项目也很繁多，大体上Java虚拟机需要做以下检查，如图所示。
| 格式检查 | 魔数检查 |
| 长度检查 | |
| 版本检查 | |
| 语义检查 | 是否继承final |
| 是否有父类 | |
| 抽象方法是否实现 | |
| 字节码验证 | 跳转指令是否指向正确位置 |
| 操作数类型是否合适 | |
| 符合引用验证 | 符合引用的直接引用是否存在 |
验证的内容涵盖了类数据信息的格式验证、语义检查、字节码验证，以及符号引用验证等。
- 其中格式验证会和加载阶段一起执行。验证通过后，类加载器才会成功将类的二进制数据信息加载到方法区。
- 格式验证之外的验证操作将会在方法区中进行。
链接阶段的验证虽然拖慢了加载的速度，但是它避免了在字节码运行时还需要进行各种检查。
-
格式验证：是否以魔数，0xCAFEBABE开头，助版本和副版本号是否在当前Java虚拟机的支持范围内，数据中每一个项是否都拥有正确的长度等。
-
Java虚拟机会进行字节码的语义检查，但凡在语义上不符合规范的，虚拟机也不会给与验证通过。比如：
- 是否所有的累都有父类的存在（在Java里，除了Object外，其他累都应该有父类）
- 是否一些被定义为final的方法或者累被重写或继承了
- 非抽象类是否实现了所有抽象方法或者接口方法
- 是否存在不兼容的方法（比如方法的签名，除了返回值不同，其他都一样，这种方法会让虚拟机无从下手调度；abstract情况下的方法，就不能是final的）。
-
Java虚拟机还会进行字节码验证，字节码验证也是验证过程中最为复杂的一个过程。它试图通过对字节码流的分析，判断字节码是否可以被正确地执行。比如：
- 在字节码的执行过程中，是否会跳转到一条不存在的指令
- 函数的调用是否传递了正确类型的参数
- 变量的赋值是不是给了正确的数据类型等
栈映射帧（StackMapTable）就是在这个节点，用于检测在特定的字节码处，其局部变量表和操作数栈是否有着正确的数据类型。但是遗憾的是，100%准确地判断一段字节码是否可以被安全执行是无法实现的，因此，该过程只是尽可能地检查出可以预知的明细的问题。如果这个阶段无法通过检查，虚拟机也不会正确装载这个类。但是，如果通过了这个阶段的检查，也不能说明这个类是完全没问题的。
-
校验器还将进行符号引用的验证。Class文件在其常量池会通过字符串记录自己将要使用的其他类或者方法。因此，在验证阶段，虚拟机就会检查这些类或者方法确实是存在的，并且当前类有权限访问这些数据，如果一个需要使用类无法在系统中找到，则会抛出NoClasDefFoundError，如果一个方法无法被找到，则会抛出NoSuchMethodError。
准备阶段（Preparation）
准备阶段，简言之，为类的静态变量分配内存，并将其初始化为默认值。
当一个类验证通过时，虚拟机就会进入准备阶段。在这个阶段，虚拟机会为这个类分配相应的内容空间，并设置默认初始值。
Java虚拟机为各类型变量默认的初始值：
| 类型 | 默认初始值 |
|---|---|
| byte | (byte)0 |
| short | (short)0 |
| int | 0 |
| long | 0L |
| float | 0.0f |
| double | 0.0 |
| char | \u0000 |
| boolean | false |
| reference | null |
Java并不支持boolean类型，对于boolean类型，内部实现是int，由于int的默认值是0，故对应的，boolean的默认值就是false。
注意：
- 这里不包含基本数据类型的字段用static final修饰的情况，因为final在编译的时候就会分配了，准备阶段会显式赋值。
- 注意这里不会为实例变量分配初始化，类变量会分配在方法区中，而实例变量会随着对象一起分配到Java堆中。
- 在这个阶段并不会像初始化阶段中那样会有初始化或者代码被执行。
public class LinkingTest {
private static long id; // 类变量，在准备阶段分配内存，并将其初始化为默认值
private static final int num = 1; // 常量，在准备阶段进行显示赋值
public static final String constStr = "CONST"; // 常量，在准备阶段进行显示赋值(字面了量方式）
public static final String constStr1 = new String("CONST"); //通过new的方式给常量赋值（不是在准备阶段执行的）
}
解析阶段（Resolution）
在准备阶段完成之后，就进入了解析阶段。解析阶段，将类、接口、字段和方法的符号引用转化为直接引用。
-
符号引用就是一些字面量的引用，和虚拟机的内部数据结构和内存布局无关。比较容易理解的就是在Class类文件中，通过常量池进行了大量的符号引用。但是在程序实际运行时，只有符号引用是不够的，比如，比如当println()方法被调用时，系统需要明确知道该方法的位置。
以方法为例，Java虚拟机为每个类都准备了一张方法表，将其所有的方法都列在表中，当需要调用一个类的方法的时候，只要知道这个方法在方法表中的偏移量就可以直接调用该方法。通过解析操作，符号引用就可以转变为目标方法在类中方法表中的位置，从而使得方法被成功调用。
-
所谓解析就是将符号引用转为直接引用，也就是得到类、字段、方法在内存中的指针或者偏移量。因此，可以说，如果直接引用存在，那么可以肯定系统中存在该类、方法或者字段。但只存在符号引用，不能确定系统中一定存在该结构。
不过Java虚拟机规范并没有明确要求解析阶段一定要按照顺序执行。在HotSpot VM中，加载、验证、准备和初始化会按照顺序有条不紊地执行，但链接阶段中的解析操作往往会伴随着JVM在执行完初始化之后再执行。
Initialization（初始化）阶段
初始化阶段，简而言之，为类的静态变量赋予正确的初始值。
-
具体描述
类的初始化是类装载的最后一个阶段。如果前面的步骤都没有问题，那么表示类可以顺序装载到系统中，此时，类才会开始执行Java字节码。（即：到了初始化阶段，才真正开始执行类中定义的Java程序代码）
初始化阶段的重要工作是执行类的初始化方法：<clint>()方法- 该方法仅能由Java编译器生成并由JVM调用，程序开发者无法自定义一个同名的方法，更无法直接在Java程序中调用该方法，虽然该方法也是由字节码指令所组成的。
- 它是由类静态成员的赋值语句以及static语句块合并产生的。
-
说明
- 在加载一个类之前，虚拟机总是会试图加载该类的父类，因此父类的<clinit>总是在子类<clinit>之前被调用。也就是说，父类的static块优先级高于子类。
- Java编译器并不会为所有的类都产生<clinit>()初始化方法。哪些类在编译成字节码后，字节码文件中不会包含<clinit>()方法？
- 一个类中并没有声明任何的类变量，也没有静态代码块时。
- 一个类中声明类变量，但是没有明确使用类变量的初始化语句以及静态代码块来执行初始化操作时。
- 一个类中包含static final修饰的基本数据类型的字段，这些字段初始化语句采用编译时常量表达式
<clinit>() 的线程安全性
对于<clinit>方法的调用，也就是类的初始化，虚拟机会在内部确保其多线程环境中的安全性。
虚拟机会保证一个类的<clinit>()方法在多线程环境中被正确地加锁、同步，如果多个线程同时去初始化一个类，那么只会有一个线程去执行这个类的<clinit>()方法，其他线程都需要阻塞等待，直到活动线程执行<clinit>()方法完毕。
正是因为函数<clinit>()带锁线程安全，因此，如果在一个类的<clinit>()方法中有耗时很长的操作，就可能造成多个线程阻塞，引发死锁。并且这种死锁是很难发现的，因为看起来它们并没有可用的锁信息。
如果之前的线程成功加载了类，则等在队列中的线程就没有机会再执行<clinit>()方法了。那么，当需要使用这个类时，虚拟机会直接返回给它已经准备好的信息。
主动使用和被动使用
-
主动使用
Class只有再必须要首次使用的时候才会被装载，Java虚拟机不会无条件地装载Class类型。Java虚拟机规定，一个类或接口在初次使用前，必须要进行初始化。这里指的“使用”，是主动使用。主动使用只有下列几种情况：（即：如果出现如下情况，则会对类进行初始化操作。而初始化操作之前的加载、验证、准备已经完成）- 当创建一个类的实例时，比如使用new关键字，或者通过反射、克隆、反序列化。
- 当调用类的静态方法时，即当使用了字节码 invokestatic 指令。
- 当使用类、接口的静态字段时（final修饰特殊考虑），比如，使用getstatic或者putstatic指令。（对应访问变量，赋值变量操作）
- 当使用java.lang.reflect包中的方法反射类的方法时。比如：Class.forName(“com.aa.bb.Test”)
- 当初始化子类时，如果发现其父类还没有进行过初始化，则需要先触发其父类的初始化
- 如果一个接口定义了default方法，那么直接实现或者间接实现该接口的类的初始化，该接口要在其之前被初始化
- 当虚拟机启动时，用户需要指定一个要执行的主类（包含main()方法的类），虚拟机会先初始化这个主类。
- 当初次调用MethodHandle实例时，初始化该MethodHandle指向的方法所在的类。（涉及解析REF_getStatic、REF_putStatic、REF_invokeStatic方法句柄对应的类）
-
被动使用
除了以上情况属于主动使用，其他的情况均属于被动使用。被动使用不会引起类的初始化。也就是说，并不是在代码中出现的类，就一定会被加载或者初始化。如果不符合主动使用的条件，类就不会被初始化。- 当访问一个静态字段时，只有真正声明这个字段的类才会被初始化。当通过子类引用父类的静态变量，不会导致子类初始化。
- 通过数组定义类引用，不会触发此类的初始化。
- 引用常量不会触发此类或接口的初始化。因为常量在链接阶段就已经被显式赋值了。
- 调用ClassLoader类的loadClass方法加载一个类，并不是对类的主动使用，不会导致类的初始化。
Using 类的使用
任何一个类型在使用之前都必须经历过完整的加载、链接和初始化3个加载步骤。一旦一个类成功经历这3个步骤之后，就可用被使用了。
开发人员可用在程序中访问和调用它的静态类成员信息（比如：静态字段、静态方法），或者使用new关键字为其创建对象实例。
Unloading 类的卸载
类、类的加载器、类的实例之间的引用关系
在类加载器的内部实现中，用一个Java集合来存放所加载类的应用。另一方面，一个Class对象总是会引起它的类加载，调用Class对象的getClassLoader()方法，就能获得它的类加载器。由此可见，代表某个类的Class实例与其类的加载器之间为双向关联关系。
一个类的实例总是引用代表这个类的Class对象。在Object类中定义了getClass()方法，这个方法返回代表对象所属类的Class对象的引用。此外，所有的Java类都有一个静态属性class，它引用代表这个类的Class对象。
loader1变量和obj变量间接引用代表xx类的Class对象，而objClass变量则直接引用它。
如果程序运行过程中，将上图左侧的三个变量都置为null，此时Sample对象结束生命周期，类加载器对象结束生命周期，代表xx类的Class对象也结束生命周期，xx类在方法区的二进制数据被卸载。
类的卸载
- 启动类加载器加载的类型在整个运行期间是不可能被卸载的。
- 被系统类加载器和扩展类加载器加载的类型在运行期间不太可能被卸载，因为系统类加载器实例或者扩展类加载器实例基本上在整个运行期间总能直接或间接的访问到，其达到unreachable的可能性极小。
- 被开发者自定义的类加载器实例加载的类型只有在很简单的上下文环境中才能被卸载，而且一般还要借助于强制调用虚拟机的垃圾收集功能才可能做到。
扫一扫
2593
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
