：全文都是自《深入理解JAVA虚拟机》一书中摘抄而来。
虚拟机把描述类的数据从Class文件加载到内存，并对数据进行校验、转换解析和初始化，最终形成可以被JVM直接使用的Java类型，这就是JVM的类加载机制。

类的生命周期：
加载Loading
验证Verification
准备preparation
解析Resolution
初始化Initialization
使用Using
卸载Unloading

连接包括：验证Verification、准备preparation、解析Resolution

顺序固定:加载Loading、验证Verification、准备preparation、初始化Initialization、卸载Unloading
解析可以再初始化阶段之后开始，这也是为了支持java语言的运行时绑定

对于初始化阶段，JVM明确规范了有且只有四种场景必须立即对类进行"初始化"（而加载、验证、准备自然要在这之前完成）。
1）遇到new、getstatic、putstatic、invokestatic这4条字节码指令时。
new:实例化对象的时候
getstatic：读取静态字段的时候（被final修饰、已在编译期把结果放入常量池的静态字段除外）
putstatic：设置静态字段的时候（被final修饰、已在编译期把结果放入常量池的静态字段除外）
invokestatic：调用静态方法的时候
2）使用java.lang.reflect包反射调用类时，如果类没有初始化，则需要触发其初始化。
3）当初始化一个类时，它有父类并且还没有进行初始化，则需要先触发其父类的初始化。
4）当JVM启动时，用户需要指定一个要执行的主类（包含main()方法的类），虚拟机会先初始化这个主类。
这四种场景中的行为称为对一个类进行主动引用。除此之外所有引用类的方式，都不会触发初始化，称为被动引用。

加载Loading：
"加载"是"类加载"过程的一个阶段，此阶段中，JVM做了三件事：
1）通过一个类的全限定名来获取定义此类的二进制字节流。
2）将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构。
3）在Java堆中生成一个代表这个类的java.lang.Class对象，作为方法区这些数据的访问入口。（类的加载的最终产品是位于堆区中的Class对象。Class对象封装了类在方法区内的数据结构，并且向Java程序员提供了访问方法区内的数据结构的接口。）

针对于"通过一个类的全限定名来获取定义此类的二进制字节流"，JVM没有限定二进制字节流必须从要Class文件获取或何处获取，事实上二进制字节流获取方式多种多样：
·zip包读取。这很常见，最终成为日后JAR、EAR、WAR格式的基础
·网络中获取。典型应用：Applet
·运行时计算生成。如动态代理技术，在java.lang.reflect.Proxy中，就是用了ProxyGenerator.generatorProxyClass来为特定接口生成*$Proxy的代理类的二进制字节流。
·由其他文件生成。典型场景：JSP引用
·从数据库中读取。不常见，有的中间件服务器（如SAP Netweaver）可以选择把程序安装到数据库中完成程序代码在集群中的分发。
......

加载阶段（准确地说是加载阶段中获取类的二进制字节流的动作），是类加载过程中，在开发期可控性最强的阶段。因为加载阶段既可以用系统提供的类加载器来完成，也可以用自定义的类加载器来完成，开发人员可以通过定义自己的类加载器去控制字节流的获取方式。
针对于"通过一个类的全限定名来获取定义此类的二进制字节流"，JVM没有限定二进制字节流必须从要Class文件获取或何处获取

加载阶段和连接阶段的部分内容（如一部分字节码文件格式验证动作）是交叉进行的，加载阶段尚未完成，连接阶段可能已经开始。
但是开始时间一定是先加载后连接的。

验证Verification：
验证是连接的第一步，这一阶段的目的是为了确保Class文件的字节流包含的信息符合JVM的要求，并且不会危害JVM的安全。
如果验证的字节流不符合Class文件的存储格式，就会抛出java.lang.varifyError错误。
验证阶段大致上会完成四个阶段的检验过程：
1）文件格式验证 ： 验证字节流是否符合class文件格式的规范，并且是否能被当前版本的JVM处理。
·是否以魔数0xCAFEBABE开头
·主、次版本号是否在当前JVM可处理范围之内。
·常量池中的常量是否有不被支持的常量类型(检查常量tag标志)。
·指向常量的各种索引值中是否有指向不存在的常量或不符类型的常量。
·CONSTANT_Utf8_info型的常量中是否有不符合UTF8编码的数据。
...
2）元数据验证 ： 验证字节码描述的信息进行语义分析，确保符合java语言规范
·这个类是否有父类。(除了java.lang.Object之外，都应该有父类。)
·这个类是否继承了不能被继承的类。(如被final修饰的类。)
·如果这个类不是抽象类，是否实现了其父类或父接口中要求实现的所有方法。
·类中的字段、方法是否和父类产生了矛盾。(例如覆盖了父类的final字段，或出现了不符合规则的的方法重载，例如方法参数都一致，但是返回值类型却不同等)
...
3）字节码验证 ： (最复杂)进行数据流和控制流分析。元数据校验过后，对类的方法体进行校验分析，确保类中方法不会危害JVM。
·保证任意时刻操作数栈的数据类型与指令代码序列都能够配合工作。(防止出现此类情况：在操作数栈中放置了一个int，使用时却按long类型来加载入本地变量表。)
·保证方法体中的类型转换是有效的。例如可以向上转型，将子类对象赋值给父类。但是父类赋值给子类或赋值给不相干的类就是不合法的、危险的。

4）符号引用验证 ： 对类自身以外的信息进行匹配性的校验。发生在JVM将符号引用转化为直接引用的时候(转化动作将在连接的第三个阶段（解析阶段）中发生)。
·符号引用中通过字符串描述的全限定名是否能够找到对应的类。
·在指定类中是否存在符合方法的字段描述符及简单名称所描述的方法和字段。
·符号引用的类、字段、方法的访问性(private,default,protected,public)是否可被当前类访问。

验证阶段对于JVM的类加载机制来说，是一个非常重要的、但是不一定是必要的阶段。如果所运行的全部代码都已经被反复使用和验证过，在实施阶段就可以考虑使用-Xverify:none参数来关闭大部分的类验证措施，以缩短JVM类加载的时间。

准备Preparation：
准备阶段是正式为类变量分配内存并设置类变量初始值的阶段，这些内存都将在方法区中进行分配。
易混淆点：
1、类变量仅包含被static修饰的变量，不包含实例变量。实例变量将在对象初始化的时候随着对象一起在堆中分配。
2、通常情况下，初始值是指0、null、false等各个数据类型的默认值。

例：
public static int val = 123;
那么变量val在准备阶段过后的初始值应该是0而不是123，因为这时候尚未开始执行任何java方法，而把val赋值为123的putstatic指令是程序被编译后，存放于类构造器<clinit>()方法之中，所以把val赋值为123的动作将在初始化阶段才会被执行。

上面提到"通常情况下"，初始值是数据类型的默认值，但是也有特殊情况：如果类字段地字段属性表中存在ConstantValue属性，那么准备阶段变量value就会被初始化为ConstantValue属性所指定的值。例如上面的val加上final修饰：
public static final int val = 123;
那么变量阶段JVM会把val的值设置成123。

解析Resolution：
解析阶段是JVM将符号引用替换为直接引用的过程。
符号引用(Symbolic References)：符号引用以一组符号来描述所引用的目标，符号可以是任何形式的字面量，只要使用时能无歧义地定位到目标即可。符号引用与JVM实现的内存布局无关，引用的目标并不一定已经加载到内存中。
直接引用(Direct References):直接引用可以是直接指向目标的指针、相对偏移量或是一个能间接定位到目标的句柄。直接引用是与JVM实现的内存布局相关的，同一个符号引用在不同的JVM实例上翻译出来的直接引用一般不会相同。如果有了直接引用，那引用的目标必定已经在内存中存在。

JVM规范之中并未规定解析阶段发生的具体时间，只要求了在执行anewarry、checkcast、getfield、getstatic、invokeinterface、invokespecial、invokestatic、invokevirtual、new、putfield、putstatic这13个用于操作符号引用的字节码指令之前，先对他们所使用的符号引用进行解析。所以JVM实现会根据需要来判断，到底是类被加载器加载时就对常量池中的符号进行引用解析，还是等到一个符号引用将要被使用前才去解析它。

解析动作主要针对类或接口、字段、类方法、接口方法四类符号引用进行，分别对应常量池中的CONSTANT_Class_info、CONSTANT_Fieldref_info、CONSTANT_Methodref_info、CONSTANT_InterfaceMethodref_info四种常量类型。

注：对同一个符号引用进行多次解析是很正常的事情，JVM实现可能会对第一次解析的结果进行缓存(在运行时常量池中记录直接引用，并把常量标识为'已解析'状态)从而避免重复解析。无论是否会多次解析，JVM必须保证的是在同一个实体中，第一次成功则后续次次成功，第一次失败，则后续一定失败。
以下的解析均针对未被解析过的类、接口、字段、方法。以下的解析均针对未被解析过的类、接口、字段、方法。
1、类或接口的解析
假设当前代码所处的类是D，要把符号引用N解析成一个类或接口C的直接引用，三个步骤：
1）如果C不是一个数组，那JVM会把代表N的全限定名传递给D的类加载器去加载这个类C。在加载过程中，由于无数据验证、字节码验证的需要，又将可能触发其他相关类的加载动作，例如加载这个类的父类或实现的接口。一旦加载过程出现了异常，解析过程宣告失败。
2）如果C是一个数组如Person[]，并且数组元素是对象类型的，那JVM会按照1)中的规则去加载数组元素类型Person，接着由JVM生成一个代表此数组维度和元素的数组对象。
3）如果上面的步骤没有出现异常，那么C在JVM中实际上已经成为一个有效的类或接口了，但在解析完成之前还要进行符号引用验证，确认C是否具备对D的访问权限。如果没有权限，将抛出java.lang.IllegalAccessError异常。
2、字段解析
JVM对字段解析之前，会先对字段表内的class_index项中索引的CONSTANT_Class_info符号引用进行解析。也就是说，会先对类或接口C的符号引用N解析成直接引用。后续继续进行字段的解析：
1）如果C本身就包含了简单名称和字段描述符都与目标相匹配的字段，则返回这个字段的直接引用，查找结束。
2）否则，如果在C中实现了接口，将会按照继承关系从上往下递归搜索各个接口和他们的父接口，如果接口中包含了简单名称和字段描述符都与目标相匹配的字段，则返回这个字段的直接引用，查找结束。
3）否则，如果C不是java.lang.Object的话，将会按照继承关系从上往下递归搜索其父类，如果父类中包含了简单名称和字段描述符都与目标相匹配的字段，则返回这个字段的直接引用，查找结束。
4）否则，查找失败，抛出java.lang.NoSuchFieldError异常。
如果查找过程中成功返回了引用，将会对这个字段进行权限验证，如果发现没权限，将抛出java.lang.IllegalAccessError异常。
3、类方法解析
JVM在对方法解析之前，也是会先对方法所属类或接口C的符号引用进行解析。如果解析成功，JVM将会按照如下步骤对方法进行解析：
1）类方法和接口方法符号引用的常量类型定义是分开的，如果在类方法表中发现class_index中索引的C是个接口，那就直接抛出java.lang.IncompatibleClassChangeError。异常。
2）如果通过了1，在类C中查找是否有简单名称和描述符都与目标相匹配的方法，如果有则返回这个方法的直接引用，查找结束。
3）否则，在类C的父类中递归查找是否有简单名称和描述符都与目标相匹配的方法，如果有则返回这个方法的直接引用，查找结束。
4）否则，在类C实现的接口列表及他们的父接口之中递归查找是否存在简单名称和描述符都与目标相匹配的方法，如果存在，则说明C是一个抽象类，查找结束，抛出java.lang.NoSuchMethodError。
如果查找过程中成功返回了引用，将会对这个方法进行权限验证，如果发现没权限，将抛出java.lang.IllegalAccessError异常。
4、接口方法解析
JVM首先解析接口方法表的class_info项中索引的方法所属的类或者接口C的符号引用。后续：
1）与类方法解析相反，如果在接口方法表中发现class_index的索引C是个类，而不是接口，那就直接抛出java.lang.IncompatibleClassChangeError。异常。
2）如果通过了1，在接口C中查找是否有简单名称和描述符都与目标相匹配的方法，如果有则返回这个方法的直接引用，查找结束。
3）否则，在接口C的父接口中递归查找（直到并包含Object类）是否有简单名称和描述符都与目标相匹配的方法，如果有则返回这个方法的直接引用，查找结束。
4）否则，宣告方法查找失败，抛出java.lang.NoSuchMethodError。

初始化Initialization：
类的初始化是类加载的最后一步，前面的类加载过程中，除了在加载阶段用户应用程序可以通过自定义类加载器参与之外，其余动作完全由JVM主导和控制。到了初始化阶段，才开始执行类中定义的Java程序代码（或者说是字节码）。
在准备阶段，变量已经赋值过一次系统要求的初始值。而在初始化阶段，则是根据程序员通过程序制定的主观计划去初始化类变量和其他资源。或者可以从另外一个角度去表达：初始化阶段是执行类构造器<clinit>()方法的过程。
下面是<clinit>()方法执行过程中可能会影响程序运行行为的一些特点和细节：
1、<clinit>()方法是由编译器自动收集类中的所有类变量的赋值动作和静态语句块（static{}块）中的语句合并生成的，编译器收集的顺序是语句在源文件中出现的顺序所决定的，静态语句块中只能访问到定义在静态语句块之前的变量，定义在他之后的变量，在前面的静态语句块中可以赋值，但不可以访问。
2、<clinit>()方法与类的构造函数（或者说实例构造器<init>()方法）不同，它不需要显式地调用父类构造器，JVM会保证在子类的<clinit>()方法执行之前，父类的<clinit>()方法已经执行完毕。因此在JVM中第一个被执行的<clinit>()方法的类是肯定是Object。
3、由于父类的<clinit>()方法先执行，也就意味着父类中定义的静态语句块要优先于子类的变量赋值操作。
4、<clinit>()方法对于类或接口来说，不是必须的，如果一个类中没有静态语句块，也没有对变量的赋值操作，那么编译器可以不为这个类生成<clinit>()方法。
5、接口中不能使用静态语句块，但仍然有变量初始化的赋值操作，因此接口与类一样都会生成<clinit>()方法。但接口与类不同的是，执行接口的<clinit>()方法不需要执行父接口的<clinit>()方法。只有当父接口中定义的变量被使用时，父接口才会初始化。另外，接口的实现在初始化时也一样不会执行接口的<clinit>()方法。
6、JVM会保证一个类的<clinit>()方法在多线程环境中被正确地加锁和同步，如果多个线程同时去初始化一个类，那么只会有一个线程去执行这个类的<clinit>()方法，其他线程都需要阻塞等待，知道活动线程执行<clinit>()方法完毕。如果在一个类的<clinit>()方法中有耗时很长的操作，那就可能造成多个进程阻塞，在实际应用中这种阻塞往往是很隐蔽的。

类加载器：

JVM把类加载阶段的“通过一个类的全限定名来获取描述此类的二进制字节流”这个动作放到java虚拟机外部去实现，以便让应用程序自己去决定如何去获取所需要的类。实现这个动作的代码模块被称为“类加载器”。

（一）类与类加载器
类加载器虽然只用于实现类的加载动作，但它在java中起到的作用远远不仅于类加载阶段。对于任何一个类来说，都需要类本身和加载这个类的类加载器一同确立其在java JVM中的唯一性。通俗来讲：比较两个类是否相等，只有两个类是由同一个类加载器加载的前提下才有意义。否则，即使两个类来自同一个class文件，但是由于加载他们的类加载器不同，那这两个类就必不相等。
这里的“相等”，包括代表类的Class对象的equals()方法，isAssignableForm()方法和，isInstance()方法的返回结果。也包括instanceOf关键字对象所属关系判定等情况。如果没有注意到类加载器的影响，在某些情况下会产生迷惑人的结果。
如例：

// 用自定义类加载器加载类ClassLoaderTest，与系统默认加载器加载的类进行isInstance比较，结果为flase。
// 这是因为JVM中存在了两个ClassLoaderTest类，一个是由系统默认类加载器加载的，一个是由自定义类加载器myloader加载的。
// 虽然都来自同一个class文件，但依然是两个独立的类。
// 说明判定类相同的条件：1、类加载器相同。 2、class文件相同
public class ClassLoaderTest {
public static void main(String[] args) throws ClassNotFoundException, IllegalAccessException, InstantiationException {
ClassLoader myLoader = new ClassLoader() {
@Override
public Class<?> loadClass(String name) throws ClassNotFoundException {
String fileName = name.substring(name.lastIndexOf(".") + 1) + ".class";
InputStream is = getClass().getResourceAsStream(fileName);
if (is == null) {
return super.loadClass(name);
}
try {
byte[] bytes = new byte[is.available()];
is.read(bytes);
return defineClass(name, bytes, 0, bytes.length);
} catch (IOException e) {
e.printStackTrace();
}
return null;
}
};
/**
* loader 'ClassLoaderTest' by myLoader-
*/
Class<?> aClass = myLoader.loadClass("jvm.classloaderabout.classloaderandclass.ClassLoaderTest");
Object obj = aClass.newInstance();
System.out.println(obj.getClass());
System.out.println(obj instanceof ClassLoaderTest);
}
}

（二）双亲委派模型
从JVM的角度来说，只存在两种不同的类加载器：一种是启动类加载器（Bootstrap ClassLoader）,这个类由C++实现，是JVM自身的一部分。另外一种就是其他所有的类加载器，这些类加载器由java实现。独立于JVM外部，并且全部都继承自抽象类java.lang.ClassLoader。
从java开发者角度来说，常用的系统提供的类加载器可以细化有三种：
1、启动类加载器（Bootstrap ClassLoader）：
这个类加载器负责将存放在<JAVA_HOME>\lib目录中的，或者被-Xbootclasspath参数所指定的路径中的，并且是JVM识别的（仅按照文件名识别，如rt.jar，名字不符合的类库即使放在lib目录中也不会被加载）类库加载到JVM内存中。启动类加载器无法被java程序直接引用。

2、扩展类加载器（Extension ClassLoader）：
这个类加载器由sun.misc.Launcher$ExtClassLoader实现，它负责加载<JAVA_HOME>\LIB\ext目录中的，或者被java.ext.dirs系统变量所指定的所有类库，开发者可以直接使用扩展类加载器。

3、应用程序类加载器（Application ClassLoader）：
这个类加载器由sun.misc.Launcher$AppClassLoader实现。由于这个类加载器是ClassLoader中的getSystemClassLoader()方法的返回值，所以一般也称之为系统类加载器。它负责加载用户类路径（ClassPath）上所指定的类库，开发者可以直接用这个类加载器，如果应用程序中没有自定义过自己的类加载器，一般情况下这个就是程序中的默认加载器。
我们的应用程序都是由这三个类加载器相互配合进行加载的，如果有必要，还可以加入自己定义的类加载器。加载器之间的关系一般如下：
启动类加载器（Bootstrap ClassLoader）<- 扩展类加载器（Extension ClassLoader） <- 应用程序类加载器（Application ClassLoader） <- 一个或多个自定义类加载器。

4、双亲委派模型
双亲委派模型要求：除了顶层的启动类加载器外，其余的类加载器都应当有自己的父类加载器。这里的类加载器之间的父子关系一般不会以继承的关系去实现，而是都使用组合关系来复用父加载器的代码。
类加载器的双亲委派模型在JDK1.2被引入并广泛应用于之后几乎所有的java程序中。是java设计者们推荐使用的类加载实现方式，但是非强制性的约束模型。

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

使用双亲委派模型来组织类加载器之间的关系
好处：java类随着它的类加载器一起具备了一种带有优先级的层次关系。例如Object类，它存放在rt.jar中，无论哪个类加载器要加载这个类，最终都是委派给启动类加载器进行加载，因此Object类在程序的各种类加载环境中都是同一个类。相反，如果没有使用双亲委派模型，由各个类加载器去加载的话，如果用户自己写了一个Object类，并放在程序的ClassPath中，那系统中将会出现多个不同的Object类，Java类型体系中最基础的行为也就无从保证，应用程序也会变得一片混乱。

双亲委派模型对于保证java程序的稳定运作很重要，但是它的实现非常简单。实现双亲委派的代码都在java.lang.ClassLoader的loadClass()方法之中。
逻辑清晰易懂：先检查是否已经被加载过，若没有加载则调用父加载器的loadClass()方法，若父类加载器为空，则默认使用启动类加载器作为父加载器。如果父类加载失败。则抛出ClassNotFoundException异常后，再调用自己的findClass()方法进行加载。

JVM命令合集：
https://blog.csdn.net/qq_27785239/article/details/98657351