虚拟机把描述类的数据从 Class 文件加载到内存，并对数据进行校验、转换解析和初始化，最终形成可以被虚拟机直接使用的 Java 类型，这就是虚拟机的类加载机制。相较于在编译时需要进行连接工作的语言，Java 语言类型的加载、连接和初始化过程都是在程序运行期间完成的，这种策略虽然会令类加载时稍微增加一些性能开销，但是会为 Java 应用程序提供高度的灵活性，Java 里天生可以动态扩展的语言特性就是依赖运行期动态加载和动态连接这个特点实现的。
下面示例体现了 Java 语言的运行期类加载（动态扩展）的特性
- 编写一个面向接口的应用程序，可以等到运行时再指定其实际的实现类。
- 通过 Java 预定义的和自定义类加载器，让一个本地的应用程序可以在运行时从网络或其他地方加载一个二进制流作为程序代码的一部分，这种组装应用程序的方式目前已广泛应用于 Java 程序之中。
- 从最基础的 Applet、JSP 到相对复杂的 OSGi 技术都使用了这种特性。
类加载的时机
类从被加载到虚拟机内存中开始，到卸载出内存为止，它的整个生命周期包括：加载（Loading）、验证（Verification）、准备（Preparation）、解析（Resolution）、初始化（Initialization）、使用（Using）和卸载（Unloading）7 个阶段。其中验证、准备、解析 3 个部分统称为连接（Linking）。
加载阶段：主要负责查找并且加载类的二进制数据文件，其实就是 class 文件。
连接阶段：连接阶段所做的工作比较多，细分的话还可以分为如下三个阶段。
- 验证：主要是确保类文件的正确性，比如 class 的版本。
- 准备：为类的静态变量分配内存，并且为其初始化默认值。
- 解析：把类中的符号引用转换为直接引用。
初始化阶段：为类的静态变量赋予正确的初始值（代码编写阶段给定的值)。
对类的主动引用
JVM 虚拟机规范规定了，每个类或者接口被 Java 程序首次主动使用时才会对其进行初始化，当然随着 JIT 技术越来越成熟，JVM 运行期间的编译也越来越智能，不排除 JVM 在运行期间提前预判并且初始化某个类。
对于初始化阶段，虚拟机规范严格规定了有且只有 5 种情况必须立即对类进行“初始化”（而加载、验证、准备自然需要在此之前开始）：
- 遇到 new、getstatic、putstatic 或 invokestatic 这4条字节码指令时，如果类没有进行过初始化，则需要先触发其初始化。
- 使用
java.lang.reflect包的方法对类进行反射调用的时候，如果类没有进行过初始化，则需要先触发其初始化。 - 当初始化一个类的时候，如果发现其父类还没有进行过初始化，则需要先触发其父类的初始化。
- 当虚拟机启动时，用户需要指定一个要执行的主类（包含
main()方法的类），虚拟机会先初始化这个主类。 - 当使用 JDK1.7 的动态语言支持时，如果一个
java.lang.invoke.MethodHandle实例最后的解析结果 ReF_getStatic、 REF_putStatic、 REF_invokeStatic的方法句柄，并且这个方法句柄所对应的类没有进行过初始化，则需要先触发其初始化。
这五种场景中的行为称为对一个类进行主动引用，其他则为被动引用。
对类的被动引用
类的被动引用：示例一
public class Test {
public static void main(String[] args) {
/*
对于静态字段来说，只有直接定义了该字段的类才会被初始化.
Console:
Parent Init
Hello Parent
并不初始化Child类，只初始化含有调用静态字段的Parent类。
*/
// System.out.println(Child.str1);
/*
如果初始化了子类，那么父类也会初始化。
Console:
Parent Init
Child Init
Hello Child
*/
// System.out.println(Child.str2);
/*
final 本身是一个常量，不能被改变
编译时，常量被存入调用这个常量的方法所在的类的常量池当中
本质上，调用类并没有直接引用到定义常量的类，因此并不会触发定义常量的类的初始化
相当于将Child类中的常量存放到了Test类的常量池中，之后Test的Main程序直接调用Test类的常量池中内容即可，与Child类之后就并无关系了
Console:
Hello Constant
*/
// System.out.println(Child.str3);
}
}
class Parent{
public static String str1 = "Hello Parent";
static {
System.out.println("Parent Init");
}
}
class Child extends Parent{
public static String str2 = "Hello Child";
public static final String str3 = "Hello Constant";
static {
System.out.println("Child Init");
}
}对于静态字段，只有直接定义这个字段的类才会被初始化，因此通过其子类来引用父类中定义的静态字段，只会触发父类的初始化而不会触发子类的初始化。至于是否要触发子类的加载和验证，在虚拟机规范中并未明确规定，这点取决于虚拟机的具体实现。对于 Sun HotSpot 虚拟机来说，可通过-XX:+TraceClassLoading参数观察到此操作会导致子类的加载。
类的被动引用：示例二
public class Test {
public static void main(String[] args) {
/*
引用数组类型
- 一维数组 class [L XXXX
- 二维数组 class [[L XXXX
原始数组类型
- 一维数组 class [I (int) [C (char) [Z (boolean) [S (short) [B (byte)
数组声明不初始化类,对于数组声明来说其类型由JVM在运行期间动态生成的，其动态生成的类型父类型为Object
*/
Parent[] parents1 = new Parent[1];
System.out.printf("parents[] %s %s \n", parents1.getClass(), parents1.getClass().getSuperclass());
Parent[][] parents2 = new Parent[1][1];
System.out.printf("parents[][] %s %s \n", parents2.getClass(), parents2.getClass().getSuperclass());
int[] ints = new int[1];
System.out.printf("int[] %s %s \n", ints.getClass(), ints.getClass().getSuperclass());
}
}
class Parent{
static {
System.out.println("Parent Init");
}
}运行之后发现没有输出”Parent Init”，说明并没有触发类 Parent 的初始化阶段。但是这段代码里面触发了另外一个名为Lorg.tarot.classloading.Parent”的类的初始化阶段，对于用户代码来说，这并不是一个合法的类名称，它是一个由虚拟机自动生成的、直接继承于java.lang.Object的子类，创建动作由字节码指令 newarray 触发。
这个类代表了一个元素类型为org.tarot.classloading.Parent的一维数组，数组中应有的属性和方法（用户可直接使用的只有被修饰为 public 的 length 属性和 clone 方法）都实现在这个类里。Java 语言中对数组的访问比 C/C++ 相对安全是因为这个类封装了数组元素的访问方法，而 C/C++ 直接翻译为对数组指针的移动。在 Java 语言中，当检查到发生数组越界时会抛出java.lang.ArraylndexOutOfBoundsException异常。
类的被动引用：示例三
public class Test {
public static void main(String[] args) {
/*
如上述所讲，常量不初始化包含类
Console:
Hello World
*/
// System.out.println(Parent.str1);
/*
对于UUID.randomUUID().toString()来说，由于编译期无法确定该常量的值，那么值就无法放入调用类的常量池中，
在程序运行时，会导致主动使用这个常量所在的类，显然会导致这个类被初始化
Console:
Parent2 Static Block
25372e9d-8347-4b87-add8-2940d1f38b30
*/
// System.out.println(Parent2.str2);
}
}
class Parent{
public static final String str1 = "Hello World";
static {
System.out.println("Parent Static Block");
}
}
class Parent2{
public static final String str2 = UUID.randomUUID().toString();
static {
System.out.println("Parent2 Static Block");
}
}虽然在 Java 源码中引用了常量，但其实在编译阶段通过常量传播优化，已经将此常量的值存储到了引用该常量的类的常量池中，以后对常量的引用都被转化为类对自身常量池的引用了。
接口的被动引用：示例四
public class Test {
public static void main(String[] args) {
/*
对一个接口的成员变量来说，默认public static final
当一个接口在初始化时，并不要求其父接口完成初始化。
但如常量在编译期无法确定，则理由同上一例子
如果真正使用到父接口时（如引用接口中所定义的常量时），才会初始化（如本例调用b就一定要初始化Child，依赖Parent）
*/
System.out.println(Child.thread);
}
}
interface Parent{
int a = 3;
public static Thread thread = new Thread(){
{
System.out.println("Parent");
}
};
}
interface Child extends Parent{
public static Thread thread = new Thread(){
{
System.out.println("Child");
}
};
}接口的被动引用：示例五
public class Test {
public static void main(String[] args) {
/*
初始化类不需要先初始化类实现的接口
Console:
1
*/
System.out.println(Child.b);
}
}
interface Parent{
public static Thread thread = new Thread(){
{
System.out.println("Parent");
}
};
}
class Child implements Parent{
public static int b = 1;
}类加载的过程
主要分为五个阶段：加载、验证、准备、解析、初始化，并且都是在程序运行期间完成的。
加载
类加载的最终产物就是堆内存中的 class 对象，对同一个 ClassLoader 来讲，不管某个类被加载了多少次，对应到堆内存中的 class 对象始终是同一个。
非数组类的加载过程
- 通过一个类的全限定名来获取此类的二进制字节流
- 将这个字节流所代表的静态存储结构转化为运行时数据区的方法区内的数据结构
- 在内存中生成一个代表这个类的
java.lang.Class对象（规范并未说明 Class 对象位于哪里，HotSpot 虚拟机将其放在方法区内 MetaSpace），用来封装类在方法区内的数据结构，并作为方法区这个类的各种数据的访问入口
由于 JVM 规范并未指明具体从哪里获取二进制字节流，因此产生了许多新花样：
- 从 ZIP 包中读取，这很常见，最终成为日后 JAR、EAR、WAR 格式的基础
- 从网络中获取，这种场景最典型的应用就是 Applet
- 运行时计算生成，这种场景使用得最多的就是动态代理技术，在
java.lang.reflect.Proxy中，就是用了 ProxyGenerator.generateClass 为特定接口生成形式为*$Proxy的代理类的二进制字节流 - 由其他文件生成，典型场景是 JSP 应用，即由 JSP 文件生成对应的 Class 类
- 从数据库中读取，这种场景相对少见些，例如有些中间作服务器（如 SAP Netweaver）可以选择把程序安装到数据库中来完成程序代码在集群间的分发
- …..
相对于类加载过程的其他阶段，一个非数组类的加载阶段（准确地说，是加载阶段中获取类的二进制字节流的动作）是开发人员可控性最强的，因为加载阶段既可以使用系统提供的引导类加载器来完成，也可以由用户自定义的类加载器去完成，开发人员可以通过定义自己的类加载器去控制字节流的获取方式（即重写一个类加载器的loadClass()方法）。
数组类的加载过程
对于数组类而言，情况就有所不同，数组类本身不通过类加载器创建，它是由 Java 虚拟机直接创建的。但数组类与类加载器仍然有很密切的关系，因为数组类的元素类型（Element Type，指的是数组去掉所有维度的类型）最终是要靠类加载器去创建，一个数组类（下面简称为 C）创建过程就遵循以下规则：
- 如果数组的组件类型（Component Type，指的是数组去掉一个维度的类型）是引用类型，那就递归采用本节中定义的加载过程去加载这个组件类型，数组 C 将在加载该组件类型的类加载器的类名称空间上被标识（一个类必须与类加载器一起确定唯一性）
- 如果数组的组件类型不是引用类型（例如 int 数组），Java 虚拟机将会把数组 C 标记为与引导类加载器关联。
- 数组类的可见性与它的组件类型的可见性一致，如果组件类型不是引用类型，类的可见性将默认为 public。
加载阶段完成后，虚拟机外部的二进制字节流就按照虚拟机所需的格式存储在方法区之中，方法区中的数据存储格式由虚拟机实现自行定义，虚拟机规范未规定此区域的具体数据结构。然后在内存中实例化一个java.lang.Class类的对象（并没有明确规定是在 Java 堆中，对于 HotSpot 虚拟机而言，Class 对象比较特殊，它虽然是对象，但是存放在方法区里面），这个对象将作为程序访问方法区中的这些类型数据的外部接口。
加载阶段与连接阶段的部分内容（如一部分字节码文件格式验证动作）是交叉进行的，加载阶段尚未完成，连接阶段可能已经开始，但这些夹在加载阶段之中进行的动作，仍然属于连接阶段的内容，这两个阶段的开始时间仍然保持着固定的先后顺序。
连接
验证
类被加载后，就进入连接阶段。连接就是将已经读入到内存的类的二进制数据合并到虚拟机的运行时环境中去。验证是连接阶段的第一步，这一阶段的目的是为了确保 Class 文件的字节流中包含的信息符合当前虚拟机的要求，并且不会危害虚拟杌自身的安全。
Java 语言本身是相对安全的语言（依然是相对于 C/C++ 来说），使用纯粹的 Java 代码无法做到诸如访问数组边界以外的数据、将一个对象转型为它并未实现的类型、跳转到不存在的代码行之类的事情，如果这样做了，编译器将拒绝编译。但前面已经说过，Class 文件并不一定要求用 Java 源码编译而来，可以使用任何途径产生，甚至包括用十六进制编辑器直接编写来产生 Class 文件。在字节码语言层面上，上述 Java 代码无法做到的事情都是可以实现的，至少语义上是以表达出来的。虚拟机如果不检查输入的字节流，对其完全信任的话，很可能会因为载入了有害的字节流而导致系统崩溃，所以验证是虚拟机对自身保护的一项重要工作。
但从整体上看，验证阶段大致上会完成下面 4 个阶段的检验动作：文件格式验证、元数据验证、字节码验证、符号引用验证。
文件格式验证：验证字节流是否符合 Class 文件格式的规范，并能被当前版本虚拟机处理。
元数据验证（类元数据信息）：对字节码描述的信息进行语义分析，以保证其描述的信息符合 Java 语言规范的要求。
字节码验证（类方法体）：通过数据流和控制流分析，确定程序语义是合法的、符合逻辑的。
由于数据流验证的高复杂性，虚拟机设计团队为了避免过多的时间消耗在字节码验证阶段，在JDK 1.6 之后的 Javac 编译器和 Java 虚拟机中进行了一项优化，给方法体的 Code 属性的属性表中增加了一项名为“Stack Table”的属性，这项属性描述了方法体中所有的基本块（Basic Block，按照控制流拆分的代码块）开始时本地变量表和操作栈应有的状态，在字节码验证期间，就不需要根据程序推导这些状态的合法性，只需要检查 StackMapTable 属性中的记录是否合法即可。这样将字节码验证的类型推导转变为类型检查从而节省一些时间。
理论上 StackMapTable 属性也存在错误或被篡改的可能，所以是否有可能在恶意篡改了 Code 属性的同时，也生成相应的 StackMapTable 属性来骗过虚拟机的类型校验则是虚拟机设计者值得思考的问题。
符号引用验证：发生在虚拟机将符号引用转化为直接引用的时候，符号引用验证可以看做是对类自身以外（常量池中的各种符号引用）的信息进行匹配性校验。
对于虚拟机的类加载机制来说，验证阶段是一个非常重要的、但不是一定必要（因为对程序运行期没有影响）的阶段。如果所运行的全部代码（包括自己编写的及第三方包中的代码）都已经被反复使用和验证过，那么在实施阶段就可以考虑使用
-Verify:none参数来关闭大部分的类验证措施，以缩短虚拟机类加载的时间。
准备
准备阶段是正式为类变量分配内存并设置类变量初始值的阶段，这些变量所使用的内存都将在方法区中进行分配。
需要注意的是：
进行内存分配的仅包括类变量（被 static 修饰的变量），而不包括实例变量。实例变量将会在对象实例化时随着对象一起分配在 Java 堆中。
准备阶段设置的初始值如下表
| 数据类型 | 初始值 |
| ————- | ————- |
| int | 0 |
| long | 0L |
| short | (short) 0 |
| char | ‘\u0000’ |
| byte | (byte) 0 |
| boolean | false |
| float | 0.0f |
| double | 0.0d |
| reference | null |
正常的类成员初始化流程是：在准备阶段分配内存并设置类变量初始值，在初始化阶段通过类构造器<clinit>中的putstatic进行赋值。
但设置初始值零值有个例外，如果类字段的字段属性表中存在 ConstantValue 属性（也就是被 static final 修饰的常量属性），在准备阶段虚拟机就会根据 ConstantValue 进行赋值。
解析
解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程。
- 符号引用（Symbolic References）：符号引用以一组符号来描述所引用的目标，符号可以是任何形式的字面量，只要使用时能无歧义地定位到目标即可。符号引用与虚拟机实现的内存布局无关，引用的目标并不一定已经加载到内存中。各种虚拟机实现的内存布局可以各不相同，但是它们能接受的符号引用必须都是一致的，因为符号引用的字面量形式明确定义在 Java 虚拟机规范的 Class 文件格式中。
- 直接引用（Direct References）：直接引用可以是直接指向目标的指针、相对偏移量或是一个能间接定位到目标的句柄。直接引用是和虚拟机实现的内存布局相关的，同一个符号引用在不同虚拟机实例上翻译出来的直接引用一般不会相同。如果有了直接引用，那引用的目标必定已经在内存中存在。
虚拟机规范之中并未规定解析阶段发生的具体时间，只要求了在执行 anewarray、checkcast、getfield、getstatic、instanceof、invokedynamic、invokeinterface、invokespecial、invokestatic、invokevirtual、ldc、ldc_w、multianewarray、new、putfield 和 putstatic 这 16 个用于操作符号引用的字节码指令之前，先对它们所使用的符号引用进行解析。所以虚拟机实现可以根据需要来判断到底是在类被加载器加载时就对常量池中的符号引用进行解析，还是等到一个符号引用将要被使用前才去解析它。
对同一个符号引用进行多次解析请求是很常见的事情，除 invokedynamic 指令以外，虚拟机实现可以对第一次解析的结果进行缓存（在运行时常量池中记录直接引用，并把常量标识为已解析状态）从而避免解析动作重复进行。无论是否真正执行了多次解析动作，虚拟机需要保证的是在同一个实体中，如果一个符号引用之前已经被成功解析过，那么后续的引用解析请求就应当一直成功；同样的，如果第一次解析失败了，那么其他指令对这个符号的解析请求也应该收到相同的异常。
对于 invokedynamic 指令，上面规则则不成立。当碰到某个前面已经由 invokedynamic 指令触发过解析的符号引用时，并不意味着这个解析结果对于其他 invokedynamic 指令也同样生效。因为 invokedynamic 指令的目的本来就是用于动态语言支持（目前仅使用 Java 语言不会生成这条字节码指令），它所对应的引用称为“动态调用点限定符（Dynamic Call Site Specifier），这里“动态”的含义就是必须等到程序实际运行到这条指令的时候，解析动作才能进行。相对的，其余可触发解析的指令都是“静态”的，可以在刚刚完成加载阶段，还没有开始执行代码时就进行解析。
解析动作主要针对类或接口、字段、类方法、接口方法、方法类型、方法句柄和调用点限定符 7 类符号引用进行，分别对应于常量池的CONSTANT_Class_info、CONSTANT_Fieldref_info、CONSTANT_Methodref_info、CONSTANT_Interface_info、CONSTANT_MethodType_info、CONSTANT_MethodHandle_info、CONSTANT_InvokeDynamic_info 7 种常量类型°。
类或接口的解析
假设当前代码所处的类为 D，如果要把一个从未解析过的符号引用 N 解析为一个类或接口 C 的直接引用，那虚拟机完成整个解析的过程需要以下 3 个步骤：
- 如果 C 不是一个数组类型，那虚拟机将会把代表 N 的全限定名传递给 D 的类加载器去加载这个类 C。在加载过程中，由于元数据验证字节码验证的需要，又可能触发其他相关类的加载动作，例如加载这个类的父类或实现的接口。一旦这个加载过程出现了任何异常，解析过程就宣告失败。
- 如果 C 是一个数组类型，并且数组的元素类型为对象，也就是 N 的描述符会是类似
Ljava/lang/Integer的形式，那将会按照第 1 点的规则加载数组元素类型。如果 N 的描述符如前面所假设的形式，需要加载的元素类型就是java.lang.Integer，接着由虚拟机生成个代表此数组维度和元素的数组对象 - 如果上面的步骤没有出现任何异常，那么 C 在虚拟机中实际上已经成为一个有效的类或接口了，但在解析完成之前还要进行符号引用验证，确认 D 是否具备对 C 的访问权限。如果发现不具备访问权限，将抛出
java.lang.IllegalAccessError异常
字段解析
要解析一个未被解析过的字段符号引用，首先将会对字段表内 class_index 项中索引的 CONSTANT_Class_info 符号引用进行解析，也就是字段所属的类或接目的符号引用。如果在解析这个类或接口符号引用的过程中出现了任何异常，都会导致字段符号引用解析的失败如果解析成功完成，那将这个字段所属的类或接口用 C 表示，虚拟机规范要求按照如下步骤对 C 进行后续字段的搜索。
- 如果 C 本身就包含了简单名称和字段描述符都与目标相匹配的字段，则返回这个字段的直接引用，查找结束。
- 否则，如果在 C 中实现子接口，将会按照继承关系从下往上递归搜索各个接口和它的父接口，如果接口中包含了简单名称和字段描述符都与目标相匹配的字段，则返回这个字段的直接引用，查找结束
- 否则，如果 C 不是
java.lang.Object的话，将会按照继承关系从下往上递归搜索其父类，如果在父类中包含了简单名称和字段描述符都与目标相匹配的字段，则返回这个字段的直接引用，查找结束 - 否则，查找失败，抛出
java.lang.NoSuchFieldError异常
如果查找过程成功返回了引用，将会对这个字段进行权限验证，如果发现不具备对字段的访问权限，将抛出java.lang.IllegalAccessError异常。
在实际应用中，虚拟机的编译器实现可能会比上述规范要求得更加严格一些，如果有个同名字段同时出现在 C 的接口和父类中，或者同时在自己或父类的多个接口中出现，那编译器将可能拒绝编译。下述代码中，如果注释了 Sub 类中的public static int A = 4;，接口与父类同时存在字段 A，那编译器将提示“The field Sub.A is ambiguous”，并且拒绝编译这段代码。
public class Solution {
interface Interface0 {
int A = 0;
}
interface Interface1 extends Interface0 {
int A = 1;
}
interface Interface2 {
int A = 2;
}
static class Parent implements Interface1 {
public static int A = 3;
}
static class Sub extends Parent implements Interface2 {
// public static int A = 4;
}
public static void main(String[] args) {
System.out.println(Sub.A);
}
}类方法解析
类方法解析的第一个步骤与字段解析一样，也需要先解析出类方法表的 class_index 项中索引的方法所属的类或接口的符号引用，如果解析成功，我们依然用 C 表示这个类，接下来虚拟机将会按照如下步骤进行后续的类方法搜索。
- 类方法和接口方法符号引用的常量类型定义是分开的，如果在类方法表中发现 class_index 中索引的 C 是个接口，那就直接抛出
java.lang.IncompatibleClassChangeError异常。 - 如果通过了第 1 步，在类 C 中查找是否有简单名称和描述符都与目标相匹配的方法，如果有则返回这个方法的直接引用，查找结束。
- 否则，在类 C 的父类中递归查找是否有简单名称和描述符都与目标相匹配的方法，如果有则返回这个方法的直接引用，查找结束。
- 否则，在类 C 实现的接口列表及它们的父接口之中递归查找是否有简单名称和描述符都与目标相匹配的方法，如果存在匹配的方法，说明类 C 是一个抽象类，这时查找结束，抛出
java.lang.AbstractMethodError异常。 - 否则，宣告方法查找失败，抛出
java.lang.NoSuchMethodError - 最后，如果查找过程成功返回了直接引用，将会对这个方法进行权限验证，如果发现不具备对此方法的访问权限，将抛出
java.lang.IllegalAccessError异常。
接口方法解析
接口方法也需要先解析出接口方法表的 class_index 项中索引的方法所属的类或接口的符号引用，如果解析成功，依然用 C 表示这个接口，接下来虚拟机将会按照如下步骤进行后续的接口方法搜索。
- 与类方法解析不同，如果在接口方法表中发现 class_index 中的索引 C 是个类而不是接口，那就直接抛出
java.lang.IncompatibleClassChangeError异常。 - 否则，在接口 C 中查找是否有简单名称和描述符都与目标相匹配的方法，如果有则返回这个方法的直接引用，查找结束。
- 否则，在接口 C 的父接口中递归查找，直到
java.lang.Object类（查找范围会包括 object 类）为止，看是否有简单名称和描述符都与目标相匹配的方法，如果有则返回这个方法的直接引用，查找结束。 - 否则，宣告方法查找失败，抛出
java.lang.NoSuchMethodError异常由于接口中的所有方法默认都是 public 的，所以不存在访问权限的问题，因此接口方法的符号解析应当不会抛出java.lang.lllegalAccessError异常。
初始化
类初始化阶段是类加载过程的最后一步，前面的类加载过程中，除了在加载阶段用户应用程序可以通过自定义类加载器参与之外，其余动作完全由虚拟机主导和控制。到了初始化阶段，才真正开始执行类中定义的 Java 程序代码（或者说是字节码）。
在准备阶段，变量已经赋过一次系统要求的初始值，而在初始化阶段，则根据程序员通过程序制定的主观计划去初始化类变量和其他资源，或者可以从另外一个角度来表达：初始化阶段是执行类构造器<clinit>()方法的过程。
<clinit>()方法执行过程中一些可能会影响程序运行行为的特点和细节。
<clinit>()方法是由编译器自动收集类中的所有类变量的赋值动作和静态语句块（static 代码块）中的语句合并产生的，编译器收集的顺序是由语句在源文件中出现的顺序所决定的，静态语句块中只能访问到定义在静态语句块之前的变量，定义在它之后的变量，在前面的静态语句块可以赋值，但是不能访问，如下面代码所示。public class Solution { static { i = 1; System.out.println(i); } static int i = 0; }<clinit>()方法与类的构造函数（或者说实例构造器<init>()方法）不同，它不需要显式地调用父类构造器，虚拟机会保证在子类的<clinit>()方法执行之前，父类的<clinit>()方法已经执行完毕。因此在虚拟机中第一个被执行的<clinit>()方法的类肯定是java.lang.Object。由于父类的
<clinit>()方法先执行，也就意味着父类中定义的静态语句块要优先于子类的变量赋值操作，字段 B 的值将会是 2 而不是 1。public class Solution { static class Parent{ public static int A = 1; static { A = 2; } Parent(){ A = 3; } } static class Sub extends Parent{ public static int B = A; } public static void main(String[] args) { System.out.println(Sub.B); } }<clinit>()方法对于类或接口来说并不是必需的，如果一个类中没有静态语句块，也没有对变量的赋值操作，那么编译器可以不为这个类生成<clinit>()方法接口中不能使用静态语句块，但仍然有变量初始化的赋值操作，因此接口与类一样都会生成<clinit>()方法。但接口与类不同的是，执行接口的<clinit>()方法不需要先执行父接口的<clinit>()方法。只有当父接口中定义的变量使用时，父接口才会初始化。另外，接口的实现类在初始化时也一样不会执行接口的<clinit>()方法。- JVM 会保证一个类的
<clinit>()方法在多线程环境中被正确地加锁、同步，如果多个线程同时去初始化一个类，那么只会有一个线程去执行这个类的<clinit>()方法，其他线程都需要阻塞等待，直到活动线程执行<clinit>()方法完毕。如果在一个类的<clinit>()方法中有耗时很长的操作，就可能造成多个进程阻塞，在实际应用中这种阻塞往往是很隐蔽的。
需要注意的是，其他线程虽然会被阻塞，但如果执行
<clinit>()方法的那条线程退出<clinit>()方法后，其他线程唤醒之后不会再次进入<clinit>()方法。同一个类加载器下，一个类型只会初始化一次。
类卸载的过程
在 JVM 的启动过程中，JVM 会加载很多的类，在运行期间同样也会加载很多的类，比如用自定义的类加载器进行类的加载，或者像 Apache Drools 框架一样会在每一个 DSL 文件解析成功之后生成相应的类文件。关于 JVM 在运行期间到底加载了多少 class，可以在启动 JVM 时指定 -verbose:class 参数观察得到，我们知道某个对象在堆内存中如果没有其他地方引用则会在垃圾回收器线程进行 GC 的时候被回收掉，那么该对象在堆内存中的 Class 对象以及 Class 在方法区中的数据结构何时被回收呢？
JVM 规定了一个 Class 只有在满足下面三个条件的时候才会被 GC 回收，也就是类被卸载。
- 该类所有的实例都已经被 GC，比如 Simple.class 的所有 Simple 实例都被回收掉。
- 加载该类的 ClassLoader 实例被回收。
- 该类的 class 实例没有在其他地方被引用。
类加载器
虚拟机设计团队把类加载阶段中的“通过一个类的全限定名来获取描述此类的二进制字节流”这个动作放到 JVM 外部去实现，以便让应用程序自己决定如何去获取所需要的类。实现这个动作的代码模块称为“类加载器”。
类加载器可以说是 Java 语言的一项创新，也是 Java 语言流行的重要原因之一，它最初是为了满足 Java applet 的需求而开发出来的。虽然目前 Java Applet 技术基本上已经“死掉”，但类加载器却在类层次划分、OSGi、热部署、代码加密等领域大放异彩，成为了 Java 技术体系中一块重要的基石。
类与类加载器
类加载器命名空间
对于任意一个类，都需要由加载它的类加载器和这个类本身一同确立其在 JVM 中的唯一性，每一个类加载器，都拥有一个独立的类名称空间。这句话可以表达得更通俗一些：比较两个类是否“相等”，只有在这两个类是由同一个类加载器加载的前提下才有意义，否则，即使这两个类来源于同一个 Class 文件，被同一个虚拟机加载，只要加载它们的类加载器不同，那这两个类就必定不相等。
以下是同一个类加载器加载 A Class：
以下是不同类加载器加载 A Class：
这里所指的“相等”，包括代表类的 Class 对象的equals()方法、isAssignableFrom()方法、isInstance()方法的返回结果，也包括使用 instanceof 关键字做对象所属关系判定等情况。如果没有注意到类加载器的影响，在某些情况下可能会产生具有迷惑性的结果，下面代码中演示了不同的类加载器对 instanceof 关键字运算的结果的影响。
public class Solution {
public static void main(String[] args) throws ClassNotFoundException, IllegalAccessException, InstantiationException {
ClassLoader loader = new ClassLoader() {
@Override
public Class<?> loadClass(String name) throws ClassNotFoundException {
try {
String filename = name.substring(name.lastIndexOf(".") + 1) + ".class";
InputStream is = getClass().getResourceAsStream(filename);
if (is == null) {
return super.loadClass(name);
}
byte[] b = new byte[is.available()];
is.read(b);
return defineClass(name, b, 0, b.length);
} catch (IOException e) {
throw new ClassNotFoundException();
}
}
};
Object obj = loader.loadClass("com.example.demo.Solution").newInstance();
System.out.println(obj.getClass());
System.out.println(obj instanceof com.example.demo.Solution);
}
}
//Console false类加载器的分类
从Java虚拟机的角度来讲，只存在两种不同的类加载器：一种是启动类加载器（Bootstrap Classloader），这个类加载器使用 C++ 语言实现，是虚拟机自身的一部分；另种就是所有其他的类加载器，这些类加载器都由 Java 语言实现，独立于虚拟机外部，并且全都继承自抽象类java.lang.ClassLoader。
这里只是说 HotSpot 是使用 C++ 实现 Bootstrap Classloader，其他虚拟机也有通过 Java 实现的。
从开发人员的角度分析，类加载器还可以划分得更细致一些，绝大部分 Java 程序都会使用到以下 3 种系统提供的类加载器。
启动类加载器（Bootstrap ClassLoader）
这个类加载器负责将存放在
<JAVA_HOME>\lib目录中的，或者被-Xbootclasspath参数所指定的路径中的，并且是虚拟机识别的（仅按照文件名识别，如rt.jar，名字不符合的类库即使放在 lib 目录中也不会被加载）类库加载到虚拟机内存中。Bootstrap ClassLoader 无法被 Java 程序直接引用，用户在编写自定义类加载器时，如果需要把加载请求委派给 Bootstrap ClassLoader，那直接使用 null 代替即可。扩展类加载器（Extension）
扩展类加载器由
sun.misc.Launcher$ExtClassLoader实现，它负责加载<JAVA_HOME>\lib\ext目录中的，或者被java.ext.dirs系统变量所指定的路径中的所有类库，开发者可以直接使用扩展类加载器。应用程序类加载器（Application ClassLoader）
这个类加载器由
sun.misc.Launcher$AppClassLoader实现。由于这个类加载器是 ClassLoader 中的getSystemClassLoader()方法的返回值，所以般也称它为系统类加载器。它负责加载用户类路径（ Class Path）上所指定的类库，开发者可以直接使用这个类加载器，如果应用程序中没有自定义过自已的类加载器一般情况下这个就是程序中默认的类加载器。用户自定义的类加载器
- java.lang.ClassLoader 的子类
- 用户可以定制类的加载方式
双亲委派模型
类加载器的双亲委派模型在 JDK1.2 期间被引入并被广泛应用于之后几乎所有的 Java 程序中，但它并不是个强制性的约束模型，而是 Java 设计者推荐给开发者的一种类加载器实现方式。
双亲委派模型的工作过程是：如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加载这个类，而是把这个请求委派给父类加载器去完成，每一个层次的类加载器都是如此，因此所有的加载请求最终都应该传送到顶层的启动类加载器中，只有当父加载器反馈自己无法完成这个加载请求（它的搜索范围中没有找到所需的类）时，子加载器才会尝试自己去加载。
下面是双亲委派的实现代码
protected Class<?> loadClass(String name, boolean resolve)
throws ClassNotFoundException
{
synchronized (getClassLoadingLock(name)) {
// First, check if the class has already been loaded
Class<?> c = findLoadedClass(name);
if (c == null) {
long t0 = System.nanoTime();
try {
if (parent != null) {
c = parent.loadClass(name, false);
} else {
c = findBootstrapClassOrNull(name);
}
} catch (ClassNotFoundException e) {
// ClassNotFoundException thrown if class not found
// from the non-null parent class loader
}
if (c == null) {
// If still not found, then invoke findClass in order
// to find the class.
long t1 = System.nanoTime();
c = findClass(name);
// this is the defining class loader; record the stats
sun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);
sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);
sun.misc.PerfCounter.getFindClasses().increment();
}
}
//由于loadClass指定了resolve为false，所以不会继续执行连接阶段
//这也就解释了为什么通过类加载器加载类并不会导致类的初始化。
if (resolve) {
resolveClass(c);
}
return c;
}
}类加载器命名空间、运行时包
破坏双亲委派模型
破坏双亲委派模型（自身缺陷）
双亲委派很好地解决了各个类加载器的基础类的统一问题（越基础的类由越上层的加载器进行加载），基础类之所以称为“基础”，是因为它们总是作为被用户代码调用的 API，但世事往往没有绝对的完美，如果基础类又要调用回用户的代码，那该怎么办？
这并非是不可能的事情，一个典型的例子便是 JNDI 服务，JNDI 现在已经是 Java 的标准服务，它的代码由启动类加载器去加载（在 JDK 1.3 时放进去的 rt.jar），但 JNDI 的目的就是对资源进行集中管理和查找，它需要调用由独立厂商实现并部署在应用程序的 Class Path 下的 JNDI 接口提供者（SPI, Service Provider Interface）的代码，但启动类加载器不可能“认识”这些代码啊！那该怎么办？
为了解决这个问题，Java 设计团队只好引入了一个不太优雅的设计：线程上下文类加载器（Thread Context Classloader）。这个类加载器可以通过java.lang.Thread类的setContextClassLoader()方法进行设置，如果创建线程时还未设置，它将会从父线程中继承一个，如果在应用程序的全局范围内都没有设置过的话，那这个类加载器默认就是应用程序类加载器。
有了线程上下文类加载器，就可以做一些“舞弊”的事情了，JNDI 服务使用这个线程上下文类加载器去加载所需要的 SPI 代码，也就是父类加载器请求子类加载器去完成类加载的动作，这种行为实际上就是打通了双亲委派模型的层次结构来逆向使用类加载器，实际上已经违背了双亲委派模型的一般性原则，但这也是无可奈何的事情。Java 中所有涉及 SPl 的加载动作基本上都采用这种方式，例如 JNDI、JDBC、JCE、JAXB 和 JBI 等。
破坏双亲委派模型（用户对程序动态性的追求）
这里所说的“动态性”指的是当前一些非常“热门”的名词：代码热替换（Hotswap）、模块热部署（Hot Deployment）等。对于一些生产系统来说，关机重启一次可能就要被列为生产事故，这种情况下热部署就对软件开发者，尤其是企业级软件开发者具有很大的吸引力。
Sun 公司所提出的 JSR-294、JSR-277 规范在与 JCP 组织的模块化规范之争中落败给 JSR-291（即 OSGi R4.2），虽然 Sun 不甘失去 Java 模块化的主导权，独立在发展 Jigsaw 项目，但目前 OSGi 已经成为了业界“事实上”的 Java 模块化标准，而 OSGi 实现模块化热部署的关键则是它自定义的类加载器机制的实现。每一个程序模块（OSGi 中称为 Bundle）都有一个自己的类加载器，当需要更换一个 Bundle 时，就把 Bundle 连同类加载器一起换掉以实现代码的热替换。
在 OSGi 环境下，类加载器不再是双亲委派模型中的树状结构，而是进一步发展为更加复杂的网状结构，当收到类加载请求时，OSGi 将按照下面的顺序进行类搜索
- 将以
java.*开头的类委派给父类加载器加载。 - 否则，将委派列表名单内的类委派给父类加载器加载。
- 否则，将 Import 列表中的类委派给 Export 这个类的 Bundle 的类加载器加载。
- 否则，查找当前 Bundle 的 Class Path，使用自己的类加载器加载。
- 否则，查找类是否在自己的 Fragment Bundle 中，如果在，则委派给 Fragment Bundle 的类加载器加载
- 否则，查找 Dynamic Import 列表的 Bundle，委派给对应 Bundle 的类加载器加载。
- 否则，类查找失败。
上面的查找顺序中只有开头两点仍然符合双亲委派规则，其余的类查找都是在平级的类加载器中进行的。