虚拟机把描述类的数据从 Class 文件加载到内存，并对数据进行校验、转换解析和初始化，最终形成可以被虚拟机直接使用的 Java 类型，这就是虚拟机的类加载机制。
在 Java 语言中，类型的加载、连接和初始化过程都是在程序运行期间完成的，这种策略虽然会令类加载时稍微增加一些性能开销，但是会为 Java 应用程序提供高度的灵活性，Java 里天生可以动态扩展的语言特性就是依赖运行期动态加载和连接这个特点实现的。
类加载的时机
类从被加载到虚拟机内存中开始，到卸载出内存为止，它的整个生命周期包括：加载、验证、准备、解析、初始化、使用和卸载。其中验证、准备、解析 3 个部分统称为连接，这 7 个阶段的发生顺序如图：
图片
加载、验证、准备、初始化这几个部分会按部就班的开始，解析阶段可能会出现在初始化之后。注意这里的按部就班不是顺序执行，通常会在一个阶段调用激活另一个阶段。
那什么时候开始加载呢？不知道，虚拟机没有规定，但是却规定了初始化的时机（这时，肯定已经加载了），有且只有以下 5 种情况必须对类进行初始化。
1 遇到 new, getstatic, putstatic, 或 invokestatic 这 4 条字节码指令时。对应的场景是使用 new 新建对象，读取或设置一个类的静态属性的时候，调用一个类的静态方法的时候。
2 使用 java.lang.reflect 包的方法对类进行反射调用的时候。
3 当初始化一个类的时候，首先初始化该类的父类。
4 当虚拟机启动时，虚拟机会先初始化包含 main 函数的主类。
5 当使用 JDK1.7 的动态语言支持时，如果一个 java.lang.invoke.MethodHandle 实例最后的解析结果 REF_getStatic, REF_putStatic, REF_invokeStatic 的方法句柄，并且这个方法句柄所对应的类没有进行过初始化，则需要先触发其初始化。
下面是几个感觉像是初始化，但实际没有初始化的场景。
1 通过子类引用父类的静态字段，不会导致子类初始化。
2 通过数组定义来引用类，不会触发此类的初始化。
3 常量在编译阶段会存入调用类的常量池中，本质上没有引用到定义常量的类，因此不会触发定义常量的类的初始化。
接口的初始化和类的初始化条件几乎一样，有差别的就是第 3 点，类要求父类必须先初始化，而接口并不要求其父接口全部完成了初始化，只有在真正使用到父类接口的时候才会初始化。
类加载的过程详解：加载、验证、准备、解析和初始化。
加载
在加载阶段，虚拟机需要完成 3 件事情。
1 通过一个类的全限定名来获取此类的二进制字节流。
2 将这个字节流所代表的静态存储转化为方法区的运行时数据结构。
3 在内存中生成一个代表这个类的 Class 对象。
我们通过什么样的方式获取类的二进制字节流是不受控制的，可以是 JSP，ZIP，JAR，网络，实时计算等方式。
对于非数组类的加载，我们也可以自定义类加载器来完成，即重写一个类加载器的 loadClass() 方法。
数组类本身不通过类加载器创建，它是由 Java 虚拟机直接创建的。但是数据类和类加载器仍然有密切关系，因为数组类的元素类型最终是要靠类加载器去创建。
加载之后的数据都以虚拟机定义的结构存储在方法区，Class 对象也放在方法区中，作为访问方法区的入口。
验证
验证是连接阶段的第一步，这一阶段的目的是为了确保 Class 文件的字节流中包含的信息符合当前虚拟机的要求，并且不会危害虚拟机自身的安全。
Class 文件可以由其他的语言生成，甚至可以我们自己编写，所以为了避免恶意波坏，必须要验证 Class 文件，这一阶段也是比较复杂的阶段，需要非常严谨的态度，内部太多大致可以分为 4 个部分。
1 文件格式验证
是否以魔数OXCAFEBABE 开头。主次版本号是否在当前虚拟机处理范围之内。常量池中的常量是否有不被支持的常量类型（检查常量的 tag 标志）CONSTANT_Utf8_info 型的常量中是否有不符合 UTF8 编码的数据。等等
这个阶段的校验都是对字节流层面的验证，有非常多的校验，没有写出来而已，经过文件格式验证之后，就把字节流正确解析并存储在方法区之内，后面的校验都是基于方法区的存储结构进行的。
2 元数据验证
这个类是否有父类。这个类的父类是否继承了不允许被继承的类（被 final 修饰）。如果这个类不是抽象类，是否实现了父类或接口中要求实现的方法。类中的字段，方法，是否与父类产生矛盾。
这个阶段的校验主要目的是对类的元数据信息进行语义检查，保证不存在不合符 Java 语言规范的元数据信息。
3 字节码验证
主要目的是通过数据流和控制流分析，确定程序语义是合法的，符合逻辑的。另外就是校验类中的方法体，保证方法在运行时不会做出危害虚拟机安全的事件。
4 符号引用验证
通过全限定名是否能找到对应的类。方法或是字段的名称。符合引用中的类、字段、方法（看权限控制符）是否可以被当前类访问。
如果无法通过符号引用验证，那么可能会发生如下异常， java.lang.NoSuchFileError, java.lang.NoSuchMethodError。这个校验发生在虚拟机将符号引用转化为直接引用的时候，这个转化动作将在解析阶段中发生。（开始时间顺序的，不一定要等检验全部结束才进入下一阶段）。
此外，验证阶段虽然很重要，但不是必须的，若是代码已经被反复使用和验证过，那么可以考虑使用 -Xverify:none 参数来关闭大部分的类验证措施，以缩短虚拟机类加载的时间。
准备
准备阶段是正式为类变量分配内存并设置类变量初始值的阶段，这些变量所使用的内存都将在方法区中进行分配。这个阶段中有两个容易混淆的概念需要强调一下。首先，这时候进行内存分配的只是类变量，而不包括实例变量，实例变量会在对象实例化时随着对象一起分配在 Java 堆中。
其次，这里所说的初始值通常情况下是数据的零值。假设定义 public static int value = 23，那么在准备阶段 value 的值是 0 ，而不是 23 。因为这时候还没有开始执行任何 Java 方法。把 value 赋值为 23 的 putstatic 指令是程序被编译后，存放在类构造器 () 方法之中，所以把 value 赋值为 23 的动作将在初始化阶段才会执行。
意外是这样的，如果类字段的字段属性表中存在 ConstantValue，就赋值为 ConstantValue 的值。例如：public static final int value = 23，编译时 javac 将会为 value 生成 ContantValue 属性，在准备阶段虚拟机就会根据 ConstantValue 的设置将 value 赋值为 23。
解析
解析阶段是虚拟机将常量池内的符合引用替换为直接引用的过程，符合引用在 Class 文件中有明确的定义，以 CONSTANT_Class_info、CONSTANT_Fieldref_info 等形式出现，而直接引用即是指针，可以直接定位到目标或是目标的句柄。
符合引用与虚拟机实现的内存布局无关，引用的目标也不一定已经加载到内存中。各种虚拟机实现的内存布局可能不相同，但是他们的符号引用必须是一致的，因为这是 Java 虚拟机规范中定义的 Class 文件的格式。
直接引用和虚拟机实现的内存布局相关，同一个符号引用在不同虚拟机实例上翻译出来的直接引用一般不会相同，如果有了直接引用，那引用的目标必定已经在内存中存在。
虚拟机中没有规定解析发生的具体时间，只是说明了要在 16 个指令（略）之前解析，所以虚拟机实现可以根据需要来判断到底是在类被加载器加载时就对常量池中的符号引用进行解析，还是等到一个符号引用将要被使用前才去解析它。
同一个符号引用当然可以被多次解析，若是一个符号引用第一次被解析，后面就不需要重复解析，有一个例外，当遇到的指令是 invokedynamic 时，会重新解析符号引用。
初始化
类初始化阶段是类加载过程的最后一步，前面的类加载过程中，除了在加载阶段用户可以通过自定义类加载器参与之外，其余动作完全由虚拟机主导和控制。到了初始化阶段，才真正开始执行类中定义的 Java 代码。
在准备阶段，变量已经赋值过一次系统要求的初始值，而在初始化阶段，则根据程序员自己设置的变量赋值。初始化阶段是执行类构造器() 方法的过程。
最后说说() 方法生成的细节，这部分和开发还是很贴近的。
1 () 方法是由编译器自动收集类中的所有类变量的赋值动作和静态语句块中的语句合并产生的，编译器收集的顺序是由语句在源文件中出现的前后顺序决定的，静态语句块中只能访问定义在它之前的变量，定义在它后面的变量，可以赋值，但是不能访问。
2 () 方法与类的构造函数 () 方法不同，它不需要显示地调用父类构造器，虚拟机会保证在子类() 方法执行之前，父类的() 方法已经执行完毕。因此在虚拟机中第一个被执行的() 方法肯定是 Object 的。
3 () 方法对类或接口来说不是必需的，如果一个类中没有静态语句块也没有对变量赋值的操作，那么编译器不为这个类生成() 方法。
4 接口中不能使用静态语句块，但仍然有变量初始化的操作，因此接口与类一样都会生成 () 方法。但接口与类不同的是，接口不需要首先执行父类的() 方法。只有当用到父类中的变量时，父接口才会初始化。另外，接口的实现类在初始化时也一样不会执行接口的() 方法。
5 虚拟机会保证一个类的() 方法在多线程中被正确的加锁，同步，如果多个线程同时去初始化一个类，那么只会有一个线程去执行这个类的() 方法，其它线程被阻塞。
另外就是在同一个类加载器下，() 方法只会被执行一次，也就是说一个类型只会被初始化一次。