虚拟机把描述类的数据从Class文件加载到内存，并对数据进行校验、转换解析和初始化，最终形成可以被虚拟机直接使用的Java类型，这就是虚拟机的类加载机制。
一、类加载的时机
类从被加载到虚拟机内存中开始，到卸载出内存为止，它的整个生命周期包括：加载（Loading）、验证（Verification）、准备（Preparation）、解析（Resolution）、初始化（Initialization）、使用（Using）和卸载（Unloading）7个阶段。其中验证、准备、解析3个部分统称为连接（Linking）。
只有5种情况必须立即对类进行初始化（而加载、验证、准备自然需要在此之前开始）：
1.遇到new、getstatic、putstatic或invokestatic这4条字节码指令时，如果类没有进行过初始化，则需要先触发其初始化。生成这4条指令的最常见的Java代码场景是：使用new关键字实例化对象的时候、读取或设置一个类的静态字段（被final修饰、已在编译期把结果放入常量池的静态字段除外）的时候，以及调用一个类的静态方法的时候。
2.使用java.lang.reflect包的方法对类进行反射调用的时候，如果类没有进行过初始化，则需要先触发其初始化。
3.当初始化一个类的时候，如果发现其父类还没有进行过初始化，则需要先触发其父类的初始化。
4.当虚拟机启动时，用户需要指定一个要执行的主类（包含main（）方法的那个类），虚拟机会先初始化这个主类。
5.当使用JDK 1.7的动态语言支持时，如果一个java.lang.invoke.MethodHandle实例最后的解析结果REF_getStatic、REF_putStatic、REF_invokeStatic的方法句柄，并且这个方法句柄所对应的类没有进行过初始化，则需要先触发其初始化。对于这5种会触发类进行初始化的场景，虚拟机规范中使用了一个很强烈的限定语：“有且只有”，这5种场景中的行为称为对一个类进行主动引用，除此之外，所有引用类的方式都不会触发初始化，称为被动引用。
1.实例验证第3、第4条
父类
public class Parent {
static {
System.out.println("parent 初始化了...");
}
}
子类
public class Child extends Parent {
static {
System.out.println("child 初始化...");
}
public static void main(String[] args) {
}
}
输出：
解析：执行的类中包含了main()会初始化这个类（第4条），在初始化子类时，发现父类没有被初始化，则先初始化父类（第3条。）
2.不会触发初始化的案例
a. 案例：通过子类引用父类的静态字段，子类不会被初始化
父类
public class Parent {
static {
System.out.println("parent 初始化了...");
}
public static int num = 10;
}
子类
public class Child extends Parent {
static {
System.out.println("child 初始化...");
}
}
执行类
public class Main {
public static void main(String[] args) {
System.out.println(Child.num);
}
}
初始化了父类，但是子类没有初始化。
b. 案例：通过数组定义来引用类
将上面执行类的代码做一下修改，子类和父类不改动。
执行类
public class Main {
public static void main(String[] args) {
Child[] children = new Child[10];
}
}
没有初始化子类和父类。
c. 案例：调用类的常量。
将子类和执行类进行修改，父类不改动。
子类
public class Child extends Parent {
public static final int a = 20;
static {
System.out.println("child 初始化...");
}
}
执行类
public class Main {
public static void main(String[] args) {
System.out.println(Child.a);
}
}
二、类加载的过程
1.类加载的过程---加载
“加载”是“类加载”（Class Loading）过程的一个阶段，在加载阶段，虚拟机需要完成以下3件事情：
1.通过一个类的全限定名来获取定义此类的二进制字节流。
2.将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构。
3.在内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据的访问入口。虚拟机规范的这3点要求并不具体。所以虚拟机实现与具体应用的灵活度都是相当大的。
比如第一条：没有指明二进制字节流要从一个Class文件中获取，准确来说是根本没有指明从哪里获取，怎么获取。例如：
1.从ZIP包中读取（典型场景：JAR、EAR、WAR）。
2.从网络中获取（典型场景：Applet）。
3.运行时计算生成（典型场景：动态代理技术，*$Proxy）。
4.由其它文件生成（典型场景：JSP应用）。
5.从数据库读取（典型场景：中间服务器）。数组类的特殊性：数组本身不通过类加载器创建，它是由Java虚拟机直接创建的，但数组类与类加载器仍然有很密切的关系，因为数组类的元素类型最终是要靠类加载器去创建，数组创建过程如下：
1.如果数组的组件类型是引用类型，那就递归采用类加载来加载。
2.如果数组的组件类型不是引用类型，Java虚拟机会把数组标记为引导类加载器关联。
3.数组类的可见性与它的组件类型的可见性一致，如果组件类型不是引用类型，那数组类的可见性将默认为public。类加载无须等到“首次使用”该类时才加载该类，Java虚拟机规范允许系统预先加载某些类。
加载阶段完成后，虚拟机外部的二进制字节流就按照虚拟机所需的格式存储在方法区之中，方法区中的数据存储格式由虚拟机实现自行定义，虚拟机规范未规定次区域的具体数据结构。
然后在内存中实例化一个java.lang.Class类的对象存放在方法区里面，作为程序访问方法区中的这些类型数据的外部接口。
加载阶段与连接阶段的部分内容（如一部分字节码文件格式验证动作）是交叉进行的，加载阶段尚未完成，连接阶段可能已经开始，但这些夹在阶段之中进行的动作，仍然处于连接阶段的内容，这两个阶段的开始时间仍然保持着固定的先后顺序。
2.类加载的过程---验证
验证是连接阶段的第一步，这一阶段的目的是为了确保Class文件的字节流中包含的信息符合当前虚拟机的要求，并且不会危害虚拟机自身的安全。
i. 文件格式验证
第一阶段要验证字节流是否符合Class文件格式的规范，并且能被当前版本的虚拟机处理（基于二进制字节流）。这一阶段可能包括下面这些验证点：
1.是否以魔数0xCAFEBABE开头。
2.主、次版本号是否在当前虚拟机处理范围之内。
3.常量池的常量中是否有不被支持的常量类型（检查常量tag标志）。
4.指向常量的各种索引值中是否有指向不存在的常量或不符合类型的常量。
5.CONSTANT_Utf8_info型的常量中是否有不符合UTF8编码的数据。
6.Class文件中各个部分及文件本身是否有被删除的或附加的其他信息。
……这一阶段的验证主要目的是保证输入的字节流能正确地解析并存储方法区之内，格式上符合描述一个Java类型信息的要求。
ii. 元数据验证
第二阶段是对字节码描述的信息进行语义分析，以保证其描述的信息符合Java语言规范的要求（基于方法区的存储结构）。这个阶段可能包括的验证点如下：
1.这个类是否有父类（除了java.lang.Object之外，所有的类都应当有父类）。
2.这个类的父类是否继承了不允许被继承的类（被final修饰的类）。
3.如果这个类不是抽象类，是否实现了其父类或接口之中要求实现的所有方法。
4.类中的字段、方法是否与父类产生矛盾（例如覆盖了父类的final字段，或者出现不符合 规则的方法重载，例5.如方法参数都一致，但返回值类型却不同等）。
……第二阶段的验证主要目的是对类的元数据信息进行语义校验，保证不存在不符合Java语言规范的元数据信息。
iii. 字节码验证
在第二阶段对元数据信息中的数据类型做完校验后，这个阶段将对类的方法体进行校验分析，保证被校验类的方法在运行时不会做出危害虚拟机安全的事件（基于方法区的存储结构），例如：
1.保证任意时刻操作数栈的数据类型与指令代码序列都能配合工作，例如不会出现类似这样的情况：在操作栈放置了一个int类型的数据，使用时却按long类型来加载入本地变量表中。
2.保证跳转指令不会跳转到方法体以外的字节码指令上。
3.保证方法体中的类型转换是有效的，例如可以把一个子类对象赋值给父类数据类型，这是安全的，但是把父类对象赋值给子类数据类型，甚至把对象赋值给与它毫无继承关系、完全不相干的一个数据类型，则是危险和不合法的。
……第三阶段是整个验证过程中最复杂的一个阶段，主要目的是通过数据流和控制流分析，确定程序语义是合法的、符合逻辑的。
iv. 符号引用验证
符号引用验证可以看做是对类自身以外（常量池中的各种符号引用）的信息进行匹配性校验，通常需要校验下列内容：
1.符号引用中通过字符串描述的全限定名是否能找到对应的类。
2.在指定类中是否存在符合方法的字段描述符以及简单名称所描述的方法和字段。
3.符号引用中的类、字段、方法的访问性（private、protected、public、default）是否可被当前类访问。
……最后一个阶段的校验发生在虚拟机将符号引用转化为直接引用的时候，这个转化动作将 在连接的第三阶段——解析阶段中发生。
符号引用验证的目的是确保解析动作能正常执行，如果无法通过符号引用验证，那么将 会抛出一个java.lang.IncompatibleClassChangeError异常的子类，如 java.lang.IllegalAccessError、java.lang.NoSuchFieldError、java.lang.NoSuchMethodError等。
3.类加载的过程---准备
准备阶段是正式为类变量分配内存并设置类变量初始值的阶段，这些变量所需要的内存都将在方法区中进行分配。
public static int value = 1024;那变量value在准备阶段过后的初始值为0而不是1024，因为这时候尚未开始做执行任何Java方法，而把value赋值为1024的putstatic指令是程序被编译后，存放于类构造器<clinit>()方法之中，所以把value赋值为1024的动作将在初始化阶段才会执行。
所有基本数据类型的零值
特殊情况：如果类字段的字段属性表中存在ConstantValue属性，那在准备阶段变量value就会被初始化为ConstantValue属性所指定的值。
public static final int value = 1024;编译时Javac会为value生产ConstantValue属性，在准备阶段虚拟机就会根据ConstantValue的设置将value赋值为1024。
4.类加载的过程---解析
解析阶段是虚拟机将常量池内的符号引用替换成直接引用的过程。
符号引用：
符号引用以一组符号来描述所引用的目标，符号可以是任何形式的字面量，只要使用时能无歧义地定位到目标即可，符号引用和虚拟机实现的布局无关，引用的目标并不一定已经加载到内存中。
直接引用：
直接引用可以是直接指向目标的指针，相对偏移量或是一个能间接定义到目标的句柄，直接引用是和虚拟机内存布局相关，引用的布标必定在内存中存在。
解析动作主要针对类或接口、字段、类方法、接口方法、方法类型、方法句柄和调用点限定符。
分别对应于常量池的
CONSTANT_Class_info、
CONSTANT_Fieldref_info、
CONSTANT_Methodref_info、
CONSTANT_InterfaceMethodref_info、
CONSTANT_MethodType_info、
CONSTANT_MethodHandle_info、
CONSTANT_InvokeDynamic_info 7种常量类型
5.类加载的过程---初始化
类初始化阶段是类加载过程的最后一步，前面的类加载过程中，除了在加载阶段可以自定义类加载器参与之外，其余都是由虚拟机主导与控制，到了初始化阶段，才真正开始执行类中定义的Java程序代码（字节码）。
从另一个角度来表达：初始化阶段是执行类构造器<clinit>()方法的过程。
如果执行<clinit>()方法那条线程退出后，其它线程唤醒之后也不会再次进行<clinit>()方法。同一个类加载器下，一个类型只会初始化一次。
三、类加载器
类加载器：通过一个类的全限定名来获取描述此类的二进制字节流。
1.类与类加载器
类加载器虽然只用于实现类的加载动作，但它在Java程序中起到的作用却远远不限于类加载阶段。
比较两个类是否相等，需要这两个类是由同一个类加载器加载的前提之下才有意义。否则哪怕是同一个Class文件，这两个类一定不相等。
相等指的是包括Class对象的equals()方法，isAsssignableFrom()方法，isInstance()方法的返回结果，也包括使用instanceof关键字做对象所属关系判定等情况。-
i. 自定义类加载器
- 定义一个类，继承ClassLoader
- 重写loadClass方法
- 实例化Class对象
-
ii. 自定义类加载器的优势
- 类加载器是Java语言的一项创新，也是Java语言流行的重要原因之一，最初的设计是为了满足Java Applet的需求而开发出来的。
- 高度的灵活性
- 通过自定义类加载器可以实现热部署
- 代码加密
-
iii. 自定义类加载器案例
package com.kevin.jvm.classloader;
import java.io.IOException;
import java.io.InputStream;
/**
* @author caonanqing
* @version 1.0
* @description 测试自定义类加载器
* 1.定义一个类，继承ClassLoader
* 2.重写loadClass方法
* 3.实例化Class对象
* @createDate 2019/8/2
*/
public class ClassLoaderDemo {
public static void main(String[] args) throws Exception {
// 自定义类加载器
ClassLoader mycl = new ClassLoader() {
/**
* 加载当前包下的所有类，其他的类委派父类加载器
* @param name 类的全限定名
* @return
* @throws ClassNotFoundException 找不到类的时候会抛出这个异常
*/
@Override
public Class<?> loadClass(String name) throws ClassNotFoundException {
// com.kevin.jvm.classloader.ClassLoaderDemo
String filename = name.substring(name.lastIndexOf(".") + 1) + ".class";
InputStream ins = getClass().getResourceAsStream(filename); // 加载
if(ins == null) { // 没有找到，让父类加载器来加载
return super.loadClass(name);
}
try {
byte[] buff = new byte[ins.available()];
ins.read(buff);
return defineClass(name,buff,0,buff.length);
} catch (IOException e) {
throw new ClassNotFoundException();
}
}
};
// 有main方法的类，被会应用程序加载器加载一次，加上我们自定义的加载器，所以会被加载两次
Object c = mycl.loadClass("com.kevin.jvm.classloader.ClassLoaderDemo").newInstance();
System.out.println(c.getClass());
// 其实c是被应用程序加载类所加载的，所以他们并不是被同一个类加载器加载的、
System.out.println(c instanceof ClassLoaderDemo);
}
}
2.双亲委派模型
从Java虚拟机的角度来讲，只存在两种不同的类加载器：
1.一种是启动类加载器（Bootstrap ClassLoader），这个类加载器使用C++语言实现，是虚拟机自身的一部分。
2.另一种就是所有其他的类加载器，这些类加载器都由Java语言实现，独立于虚拟机外部，并且全都继承自抽象类java.lang.ClassLoader。从Java开发人员的角度来看，大部分Java程序会使用到以下3中系统提供的类加载器：
1.启动类加载器（Bootstrap ClassLoader）：加载lib下或被-Xbootclasspath路径下的类。
2.扩展类加载器（Extension ClassLoader）：加载lib/ext或java.ext.dirs系统变量所指定的路径中的所有类库。
3.应用程序类加载器（Application ClassLoader）：ClassLoader负责，加载用户路径（ClassPath）上所指定的类库，一般也成为系统类加载器，默认使用这个。一般我们的应用程序都是这3种类加载器互相配合进行加载的，如果有必要还可以加入我们自定义的类加载器。这些类加载器之间的关系，称为类加载的双亲委派模型。
如图所示：
双亲委派模型要求除了顶层的启动类加载器外，其余的类加载器都应当有自己的父类加载器。
这里类加载器之间的父子关系一般不会以继承的关系来实现，而是都使用组合关系来复用类加载器的代码。
工作流程：如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加载这个类，而是将这个请求委派给父类加载器。只有父类加载器无法完成时子类加载器才会尝试加载。
a.案例
package java.lang;
/**
* @author caonanqing
* @version 1.0
* @description 测试双亲类加载器
* @createDate 2019/8/2
*/
public class Object {
public static void main(String[] args) {
Object obj = new Object();
System.out.println("Hello World");
}
}
这个类其实并没有被加载。
b.双亲类加载器的案例
protected Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException {
synchronized (getClassLoadingLock(name)) {
//检查该类是否已经加载过
Class c = findLoadedClass(name);
if (c == null) {
//如果该类没有加载，则进入该分支
long t0 = System.nanoTime();
try {
if (parent != null) {
//当父类的加载器不为空，则通过父类的loadClass来加载该类
c = parent.loadClass(name, false);
} else {
//当父类的加载器为空，则调用启动类加载器来加载该类
c = findBootstrapClassOrNull(name);
}
} catch (ClassNotFoundException e) {
//非空父类的类加载器无法找到相应的类，则抛出异常
}
if (c == null) {
//当父类加载器无法加载时，则调用findClass方法来加载该类
long t1 = System.nanoTime();
c = findClass(name); //用户可通过覆写该方法，来自定义类加载器
//用于统计类加载器相关的信息
sun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);
sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);
sun.misc.PerfCounter.getFindClasses().increment();
}
}
if (resolve) {
//对类进行link操作
resolveClass(c);
}
return c;
}
}
3.破坏双亲委派模型
双亲委派模型并不是强制性的约束模型，而是Java设计者推荐给开发者的类加载器实现方式。
线程上下文类加载器（Thread Context ClassLoader），这个类加载器可以通过java.lang.Thread类的setContextClassLoaser()方法进行设置，如果创建线程时还没设置，它将会从父线程中继承一个，如果在应用程序的全局范围内都没有设置过的话，那这个类加载器默认就是应用程序类加载器。
在OSGi环境下，类加载器不再是双亲委派模型中的树状结构，而是进一步发展为更加复杂的网状结构，当收到类加载请求时，OSGi将按照下面的顺序进行类搜索：
1.将以java.*开头的类委派给父类加载器加载。
2.否则，将委派列表名单内的类委派给父类加载器加载。
3.否则，将Import列表中的类委派给Export这个类的Bundle的类加载器加载。
4.否则，查找当前Bundle的ClassPath，使用自己的类加载器加载。
5.否则，查找类是否在自己的Fragment Bundle中，如果在，则委派给Fragment Bundle的 类加载器加载。
6.否则，查找Dynamic Import列表的Bundle，委派给对应Bundle的类加载器加载。
7.否则，类查找失败。 上面的查找顺序中只有开头两点仍然符合双亲委派规则，其余的类查找都是在平级的类 加载器中进行的。