JVM:虚拟机类加载机制
什么是JVM的类加载
众所周知，Java是面向对象编程的一门语言，每一个对象都是一个类的实例。所谓类加载，就是JVM虚拟机把描述类的数据从class文件加载到内存，并对数据进行校验，转换解析和初始化，最终形成可以被虚拟机直接使用的Java类型。 动态的类型加载也是Java语言的一个重要特性之一，比如Android中的Retrofit库的动态代理在一定程度上也依赖于动态的类型加载。
类加载的生命周期
关于类加载的生命周期实际上在之前的一篇文章中已经粗略地提到过了：
这里我们以《深入理解JVM虚拟机》为准，完整地描述出其七个生命周期：
类的加载过程
Java虚拟机中类加载的全过程包括：加载，验证，准备，解析和初始化这五个过程，接下来我们分别来看这五个步骤：
1.加载
在加载阶段，JVM主要需要完成以下三件事情：
- 通过一个类的
全限定名来获取定义此类的二进制字节码 - 将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构
- 在内存中 生成代表该类的
java.lang.Class文件，作为方法区这个类的各种数据的访问入口
其中，获取定义此类的二进制字节码 这个行为默认情况下就是从.class的字节码文件中读取，不过我们也可以通过自定义的类加载器从诸如 网络，数据库等中读取字节码流，从而达到动态加载的目的。
而对于数组来说则是由JVM直接在内存中动态构造出来的，不过数组的元素类型最终还是要依靠类加载器来完成加载。
加载阶段结束后，JVM的方法区之中就存在对应类的相关数据了，当这些数据都被安放完成之后，会在Java堆内存中 实例化一个java.lang.Class类的对象，该对象就是程序访问方法区中数据的外部接口。
2.验证
所谓验证阶段，就是JVM确保Class文件的字节流中包含的信息符合《Java虚拟机规范》的全部约束，确保这些信息被当做代码运行后不会危害JVM自身的安全。
从整体上来看，验证阶段大致可以分为四个阶段的校验动作：文件格式验证，元数据验证，字节码验证，符号引用验证。
文件格式验证
验证过程的第一个阶段就是验证文件的格式是否合法，并且能否被当前版本的JVM所处理。这一阶段的验证点主要有：
- 是否以魔数0xCAFEBABE开头
- 主，次版本号是否在当前JVM所接受范围之内
- ...
总之，该阶段的主要目的是保证输入的字节流能被正确地解析并存储进方法区之中，并且格式上符合一个Java类型信息的要求。只有通过了该阶段的验证之后，字节流才能被存储进方法区之中，所以后面三个阶段都是基于方法区的存储结构上进行的，不会再直接操作字节流了。
元数据验证
第二阶段主要是对字节码描述的信息做语义上的分析，以确保其符合《Java语言规范》的要求。拿什么是语义上的分析呢？验证点就包括有：
- 这个类是否有父类（除了Object之外，其余所有类都应当有父类）
- 这个类的父类是否继承了不允许被继承的类（即被final修饰）
- 如果这个类不是抽象类，是否实现了其父类或接口中要求实现的所有方法
- ...
可以看到，该阶段的验证条件实际上就是我们在学习Java语法中的一些规定；总之第二阶段的主要目的是对类的元数据信息进行语义校验，保证不存在与《Java语言规范》定义相悖的元数据信息。
字节码验证
第三个阶段是整个验证阶段最复杂的过程，主要目的是通过数据流分析和控制流分析，确定程序语义是合法且符合逻辑的，保证被校验类的方法在运行时不会做出危害虚拟机的行为。
符号引用验证
最后一个阶段发生在虚拟机将符号引用转化为直接引用的时候，而这个动作是在解析阶段中发生的。符号引用验证可以看做是对类自身以外（常量池中的各种符号引用）的各类信息进行匹配性校验，通俗来讲就是该类是否缺少或者被禁止访问它依赖的某些外部类，方法，字段等资源。
3.准备
准备阶段是正式为类中定义的变量（即静态变量）分配内存并设置初值的过程，在JDK7之前类变量将被存储在方法区之中，而在JDK7后类变量则会随着Class对象一起存放在Java堆中。这里的初始化指的又是数据类型的置零，比如说:
java
public static int value = 123;那变量在准备阶段过后是0而不是123，因为此时尚未执行任何Java方法，而赋值语句是存放在类构造器<clinit>之中的，这个赋值动作要到类的初始化阶段才会执行。
不过这个置零也有例外情况，如果该字段是常量的话，也就是：
java
public static final int value = 123;这种情况下value的值就将直接被赋值为123。
4.解析
解析阶段是JVM将常量池内的符号引用替换为直接引用的过程，这个过程的逻辑比较复杂，简单来说就是将符号替换成直接指向对应变量的地址，此处我们就不展开了。
5.初始化
初始化阶段是类加载过程的最后一个步骤，之前的准备阶段中我们已经将变量赋值成零值了（除了常量），而在初始化阶段则会根据我们编写的程序进行相应变量的初始化。具体来说，初始化阶段就是执行类构造器<clinit>()方法的过程，至于这个<clinit>()方法并不是程序员直接编写的，该方法是由编译器自动收集所有类变量的赋值动作和静态语句块中的语句合并而成的。
类加载器
之前在类的加载过程中我们提到了一个类并不仅仅可以通过class文件读取，它还可以通过其他各种手段来将类加载进方法区中，其中类加载器就是用来进行类加载的工具。
类与类加载器
顾名思义，每一个类都是由类加载器加载进入JVM之中的，虽然类加载器只用来实现类的加载动作，但是其作用远超其加载阶段。
对于任意一个类，都必须由加载它的类加载器和这个类本身一起共同确立其在JVM中的唯一性。 也就是说，只有当字节码相同且由同一个类加载器加载时才能认为这两个类是相同的，每一个类加载器都有其自己的类名称空间。
双亲委派模型
所谓双亲委派是Java默认情况下的类加载机制遵守的原则。站在JVM的视角上只有启动类加载器和其他类加载器这两种类加载器。启动类加载器属于JVM的一部分，它是由C++语言实现的；而其他的类加载器则是由Java语言实现的，不属于JVM的一部分且全部继承于抽象类java.lang.ClassLoader。
而双亲委派则是涉及到三层类加载器：
- 启动类加载器：这个加载器是负责加载存放在
<JAVA_HOME>\lib目录并且可以被JVM识别的类库； - 拓展类加载器：它是负责加载
<JAVA_HOME>\lib\ext目录下的类库 - 应用程序类加载器：这个类是用来加载用户类路径上的所有类库，我们同样可以直接使用这个加载器，一般情况下这就是程序中默认的类加载器
这三层类加载器在双亲委派模型下的关系如下所示：
除了启动类加载器之外，其他所有的类加载器都应该有自己的父加载器，不过他们之间并不是通过继承来实现的，非要说的话可能更接近于责任链模式
双亲委派模式的具体原则是： 如果一个类加载器受到了类加载的请求，它首先不会自己尝试加载，而是把这个请求委派给父加载器去实现，每一个层次的类加载器的行为都是如此，所以说所有的类加载请求首先都会被发送到启动类加载器去进行加载。只有当父加载器无法实现类的加载时子加载器才会尝试进行类的加载。
使用双亲委派模型的好处也是显而易见的：
首先它保证了JVM中的一些系统类不会被轻易地被替换，因为大部分的系统类，比如说Object类都是在系统类启动器管理的目录下的；其次，这种层次关系保证了同一个类(class)文件加载后的类都是相同的（由同一个类加载器加载的）