深入理解虚拟机 —— 类的加载

• 深入理解虚拟机 —— Java内存区域
• 深入理解虚拟机 —— 垃圾收集器

类被加载到虚拟机的内存中开始，到卸载出内存为止，它的整个生命周期包括：加载、验证、准备、解析、初始化、使用和卸载。

类加载的过程

加载

在加载阶段，需要完成以下3件事情：

• 通过一个类的全限定名来获取定义此类的二进制字节流
• 将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构
• 在内存中生成一个代表这个类的 java.lang.Class 对象，作为方法区这个类的各种数据的访问入口。

加载阶段结束后，Java 虚拟机外部的二进制字节流就按照虚拟机所设定的格式存储在方法区之中，方法区中的数据存储格式完全由虚拟机实现自行定义。

验证

验证是连接阶段的第一步，这一阶段的目的是为了确保 Class 文件的字节流包含的信息符合当前虚拟机的要求，并且不会危害虚拟机自身的安全。

验证阶段大致上回完成下面4个阶段的校验：文件格式验证、元数据验证、字节码验证、符号引用验证。

准备

准备阶段是正式为类变量分配内存并设置类变量初始值的阶段，这些变量所使用的的内存都将在方法区中进行分配。在这个阶段进行分配仅包括类的变量（被static修饰的变量），而不包括实例对象，实例对象将会在对象实例化时随对象一起分配在Java堆中。

在“通常情况”下，初始值指的是数据类型的零值，比如：

public static int values = 120;

这里的 values 在准备阶段过后的初始值为0而不是120。如果类字段属性表中存在 ConstantValue 属性，那么初始值就是指定的值。

public static final int values = 120;

解析

解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程。

• 符号引用：符号引用以一组符号来描述所引用的目标，符号可以是任何形式的字面量，只要使用是无歧义地定位到目标即可。
• 直接引用：直接引用可以直接指向目标的指针、相对偏移量或是一个间接定位到目标的句柄。

初始化

类初始化时类加载过程最后一步，前面的类加载过程中，除了在加载阶段用户应用程序可以通过自定义类加载器参与外，其余动作完全由虚拟机主导和控制。这个阶段才真正执行类中定义的Java程序代码。

初始化阶段是执行类构造器<client>方法的过程。<client>方法是由编译器自动收集类中的类变量的赋值操作和静态语句块中的语句合并而成的。虚拟机会保证<client>方法执行之前，父类的<client>方法已经执行完毕。

P.S: 如果一个类中没有对静态变量赋值也没有静态语句块，那么编译器可以不为这个类生成<client>()方法。

注意以下几种情况不会执行类初始化：

• 通过子类引用父类的静态字段，只会触发父类的初始化，而不会触发子类的初始化。
• 定义对象数组，不会触发该类的初始化。
• 常量在编译期间会存入调用类的常量池中，本质上并没有直接引用定义常量的类，不会触发定义常量所在的类。
• 通过类名获取Class对象，不会触发类的初始化。
• 通过Class.forName加载指定类时，如果指定参数initialize为false时，也不会触发类初始化，其实这个参数是告诉虚拟机，是否要对类进行初始化。
• 通过ClassLoader默认的loadClass方法，也不会触发初始化动作。

类加载器

类与类加载器

类加载器只用于实现类的加载过程。对于任意一个类，都需要由加载它的类和这个了类本身一同确立其在Java虚拟机中的唯一性，每个类加载器，都拥有一个独立的类名称空间。

两个类是否“相等”的前提，只有这两个类是由同一个类加载器加载的。这里的“相等”指的是代表类的Class 对象的equals()方法、isAssignableFrom()方法、isInstance()方法的返回结果，也包括使用 instanceof 关键字做对象所属关系判定等情况。

双亲委派模型

从虚拟机的角度来说，只存在两种不同的加载器：

• 启动类加载器（Bootstrap ClassLoader），这个类加载器使用 C++ 语言实现，是虚拟机自身的一部分。
• 所有其他的类加载器，这些类加载器都由 Java 语言实现，独立于虚拟机外部，并且全都继承抽象类 java.lang.ClassLoader。

从程序员角度来说，可以更加细分：

• 启动类加载器：这个类加载器负责加载存放在 <JAVA_HOME>/lib 目录，或者被 -Xbootclasspath 参数所指定的路径中存放的，而且是 Java 虚拟机能够士必得类库加载到虚拟机的内存中。
• 扩展类加载器：这个类加载器在类 sun.misc.Launcher$ExtClassLoader 中以 Java 代码的形式实现的。它负责加载 <JAVA_HOME>/lib/ext 目录中，或者被 java.ext.dirs 系统变量所指定的路径中所有的类库。
• 应用程序类加载器：这个类是由sun.misc.Launcher$AppClassLoader 来实现的。

上图展示的类加载器之间的这种层次关系，称为类加载器的双亲委派模型。双亲委派模型要求除了顶层的启动类加载器外，别的类加载器都应有自己的父类加载器。这里类加载器之间的父子关系一般不会以继承关系来实现，而都是使用组合关系来复用父加载器的代码。

双亲委派模型的工作过程：如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加载这个类，而是把这个请求委派给父类加载器去完成，每一个层次的类加载器都是如此，因此所有的加载请求最终都应该传送给顶端的启动类加载器中，只有当父类自己无法完成这个加载请求时（它的搜索范围中没有找到所需的类），子加载器才会尝试自己去加载。

这种模型的好处就是 Java 类随着它的加载器一起具备了一种带有优先级的层次关系。比如，Java中的Object类，它存放在rt.jar之中,无论哪一个类加载器要加载这个类，最终都是委派给处于模型最顶端的启动类加载器进行加载，因此Object在各种类加载环境中都是同一个类。如果不采用双亲委派模型，那么由各个类加载器自己取加载的话，那么系统中会存在多种不同的Object类。