1、概述
虚拟机把描述类的数据从Class文件加载到内存，并对数据进行校验、 转换解析和初始化，最终形成可以被虚拟机直接使用的Java类型，这就是虚拟机的类加载机制。
2、类加载顺序
类从被加载到虚拟机内存中开始，到卸载出内存为止，它的整个生命周期包括：加载（Loading）、 验证（Verification）、 准备（Preparation）、 解析（Resolution）、 初始化
（Initialization）、 使用（Using）和卸载（Unloading）7个阶段。 其中验证、 准备、 解析3个部分统称为连接（Linking），这7个阶段的发生顺序如图7-1所示。
3、类加载时机
Java虚拟机规范只规定了“初始化”阶段的时机，其他的没有约束。
对于初始化阶段，虚拟机规范则是严格规定了有且只有5种情况必须立即对类进行“初始化” ：
1）遇到new、 getstatic、 putstatic或invokestatic这4条字节码指令时
2）使用java.lang.reflect包的方法对类进行反射调用的时候
3）当初始化一个类的时候，如果发现其父类还没有进行过初始化，则需要先触发其父类的初始化
4）当虚拟机启动时，用户需要指定一个要执行的主类（包含main（）方法的那个类），虚拟机会先初始化这个主类
5）如果一个java.lang.invoke.MethodHandle实例最后的解析结果REF_getStatic、 REF_putStatic、 REF_invokeStatic的方法句柄
这5种场景中的行为称为对一个类进行主动引用，当发生主动引用，并且类没有被初始化时，才初始化。
其他的都成为被动引用，不会进行类的初始化，比如：
1）通过其子类来引用父类中定义的静态字段，只会触发父类的初始化而不会触发子类的初始化。
2）数组初始化时，只会触发数组类的初始化，不会触发引用类型的初始化。数组类是JVM为引用类自动创建的一个类型，具体为L+引用类全路径，比如："Lcom.xxxx.xxx"
3）直接访问静态字段，在编译阶段通过常量传播优化，已经将此常量的值存储到了常量池中，不会触发类初始化
4）接口不会触发父类，只会在父类真正被使用时才会初始化。
4、类加载具体过程
4.1、加载
在加载阶段，虚拟机需要完成以下3件事情：
1）通过一个类的全限定名来获取定义此类的二进制字节流。
2）将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构。
3）在内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据的访问入口。
JVM对二进制的来源没有指定，所以，可以来源于 JAR,WAR,等等。
4.2、验证
目的是为了确保Class文件的字节流中包含的信息符合当前虚拟机的要求，并且不会危害虚拟机自身的安全。
如果验证到输入的字节流不符合Class文件格式的约束，虚拟机就应抛出一个java.lang.VerifyError异常或其子类异常 。
验证阶段大致上会完成下面4个阶段的检验动作：文件格式验证、元数据验证、 字节码验证、 符号引用验证。
1.文件格式验证： 第一阶段要验证字节流是否符合Class文件格式的规范，并且能被当前版本的虚拟机处理。
2.元数据验证： 第二阶段是对字节码描述的信息进行语义分析，以保证其描述的信息符合Java语言规范的要求。即对数据类型进行验证
3.字节码验证： 通过数据流和控制流分析，确定程序语义是合法的、 符合逻辑的。即对方法逻辑进行验证。
4.符号引用验证： 发生在“解析”阶段，验证内容包括符号名，限定符等。
4.3、准备
准备阶段是正式为类变量分配内存并设置类变量初始值的阶段，这些变量所使用的内存都将在方法区中进行分配。
注意：
1、变量指的是静态变量。
2、赋值表示的是置为JVM原始的默认值，一般是0，而不是代码指定的默认值。 比如 private static int i = 3; 这里的默认值也是0.
4.3、解析
解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程。
符号引用：就是在class文件格式里讲的引用序号。
直接引用：就是之前讲的指针引用或者句柄引用，可以直接关联到JVM内存的。
4.4、初始化
初始化阶段是执行类构造器＜clinit＞（）方法的过程。
＜clinit＞（）方法是由编译器自动收集类中的所有类变量的赋值动作和静态语句块（static{}块）中的语句合并产生的 。
编译器收集的顺序是由语句在源文件中出现的顺序所决定的 ，父类中定义的静态语句块要优先于子类的变量赋值操作 。
5、类加载器
对于任意一个类，都需要由加载它的类加载器和这个类本身一同确立其在Java虚拟机中的唯一性， 因为，每一个类加载器，都拥有一个独立的类名称空间。
所以，需要一个机制来确定用哪个类加载器来加载类。
5.1、类加载器的分类
启动类加载器（Bootstrap ClassLoader）
使用C++语言实现 ，是虚拟机自身的一部分 。
负责将存放在＜JAVA_HOME＞\lib目录中的，或者被-Xbootclasspath参数所指定的路径中的，并且是虚拟机识别的类库加载到虚拟机内存中。
启动类加载器无法被Java程序直接引用，用户在编写自定义类加载器时，如果需要把加载请求委派给引导类加载器，那直接使用null代替即可
扩展类加载器( Extension ClassLoader )
由sun.misc.Launcher$ExtClassLoader实现，它负责加载＜JAVA_HOME＞\lib\ext目录中的，或者被java.ext.dirs系统变量所指定的路径中的所有类库，开发者可以直接使用扩展类加载器。
应用程序类加载器（Application ClassLoader）
由sun.misc.Launcher $AppClassLoader实现。 由于这个类加载器是ClassLoader中的getSystemClassLoader（）方法的返回值，所以一般也称它为系统类加载器。
它负责加载用户类路径（ClassPath）上所指定的类库，开发者可以直接使用这个类加载器，如果应用程序中没有自定义过自己的类加载器，一般情况下这个就是程序中默认的类加载器。
自己定义的类加载器
5.2、类加载器的关系：双亲委派模型
图7-2中展示的类加载器之间的这种层次关系，称为类加载器的双亲委派模型（Parents Delegation Model）。
双亲委派模型要求除了顶层的启动类加载器外，其余的类加载器都应当有自己的父类加载器。
这里类加载器之间的父子关系一般不会以继承（Inheritance）的关系来实现，而是都使用组合（Composition）关系来复用父加载器的代码。
双亲委派模型的工作过程是：
如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加载这个类，而是把这个请求委派给父类加载器去完成，每一个层次的类加载器都是如此，
因此所有的加载请求最终都应该传送到顶层的启动类加载器中，只有当父加载器反馈自己无法完成这个加载请求（它的搜索范围中没有找到所需的类）时，子加载器才会尝试自己去加载。
好处：确保加载同一个类的加载器是固定的。
原因：也就是开始提到的，同一个类加载器加载的同一个类才能确定唯一的类。
疑问：为啥叫“双亲”委派模型？
答：这是翻译的锅，“双亲”只是“parents”的直译，实际上并不表示汉语中的父母双亲，而是一代一代很多parent，即parents。
5.3、双亲委派模型的例外
底层类动态获取的上层类，就需要动态设置类加载器。详略。