本篇文章主要介绍一下虚拟机是如何进行类加载的以及进行类加载的加载器的工作原理。
一、类加载过程
Java的类加载过程分为三个主要步骤：加载、链接、初始化。
1.加载
将class二进制文件加载到内存中，通过一个类的全限定名来获取定义此类的二进制字节流。在加载过程中虚拟机将字节流所代表的静态存储结构转化为方法区的运行时数据结构。在java堆中生成一个代表这个类的java.lang.Class对象，做为方法区这些数据的访问入口。加载阶段完成之后二进制字节流就按照虚拟机所需的格式存储在方法区中。
在这个加载过程中虚拟机不能独立完成，需要借助加载器完成的，本篇后面会对加载器的加载原理进行介绍。
2.验证
这是虚拟机安全的重要保障，JVM需要核验字节信息是符合Java虚拟机规范的，否则就被认为是VerifyError，这样就防止了恶意信息或者不合规的信息危害JVM的运行，验证阶段有可能触发更多class的加载。验证阶段主要进行了如下内容的验证：
（1）文件格式验证：验证字节流是否符合Class文件格式的规范，并且能被当前版本的虚拟机处理。
（2）元数据验证：对字节码描述的信息进行语义分析，以确保其描述的信息符合java语言规范的要求。
（3）字节码验证：这个阶段的主要工作是进行数据流和控制流的分析。任务是确保被验证类的方法在运行时不会做出危害虚拟机安全的行为。
（4）符号引用验证：这一阶段发生在虚拟机将符号引用转换为直接引用的时候（解析阶段），主要是对类自身以外的信息进行匹配性的校验。目的是确保解析动作能够正常执行。
3.准备
对静态变量赋默认值，而不是初始值（目标值），准备阶段是正式为静态变量分配内存并设置初始值，这些内存都将在方法区中进行分配，这里的变量仅包括类变量（静态变量）不包括实例（成员）变量。不同的数据类型及其初始值如下图所示。
public class LinkedPrepare {
private static int a = 10; //①
private final static int b = 10; //②
}
其中static int a=10在准备阶段不是10，而是初始值0，当然final static int b则还会是10，为什么呢？因为final修饰的静态变量（可直接计算得出结果）不会导致类的初始化，是一种被动引用，因此就不存在连接阶段了。当然了更加严谨的解释是final static int b=10在类的编译阶段javac会将其value生成一个ConstantValue属性，直接赋予10。
4.解析
解析是虚拟机将常量池的符号引用替换为直接引用的过程。
5.初始化
类的初始化阶段是整个类加载过程中的最后一个阶段，在初始化阶段做的最主要的一件事情就是执行＜clinit＞()方法的过程（clinit是class initialize前面几个字母的简写）在＜clinit＞()方法中所有的类变量都会被赋予正确的值，也就是在程序编写的时候指定的值。＜clinit＞()方法是在编译阶段生成的，也就是说它已经包含在了class文件中了，＜clinit＞()中包含了所有类变量的赋值动作和静态语句块的执行代码，编译器收集的顺序是由执行语句在源文件中的出现顺序所决定的。另外需要注意的一点是，静态语句块只能对后面的静态变量进行赋值，但是不能对其进行访问。
另外＜clinit＞()方法与类的构造函数有所不同，它不需要显示的调用父类的构造器，虚拟机会保证父类的＜clinit＞（）方法最先执行，因此父类的静态变量总是能够得到优先赋值。
虽然说Java编译器会帮助class生成＜clinit＞()方法，但是该方法并不意味着总是会生成，比如某个类中既没有静态代码块，也没有静态变量，那么它就没有生成＜clinit＞()方法的必要了，接口中同样也是如此，由于接口天生不能定义静态代码块，因此只有当接口中有变量的初始化操作时才会生成＜clinit＞()方法。
二、双亲委派模式
在类加载过程中，是需要加载器将class二进制文件加载到内存中，JVM预定义的三种类型类加载器：
（1）启动类加载器（Bootstrap Class-Loader）：是用本地代码实现的类装入器，它负责将 <Java_Runtime_Home>/lib下面的类库加载到内存中（比如rt.jar）。由于引导类加载器涉及到虚拟机本地实现细节，开发者无法直接获取到启动类加载器的引用，所以不允许直接通过引用进行操作。
（2）扩展类加载器（Extension Class-Loader）：是由 Sun 的 ExtClassLoader（sun.misc.Launcher$ExtClassLoader）实现的。它负责将<Java_Runtime_Home>/lib/ext或者由系统变量 java.ext.dir指定位置中的类库加载到内存中。开发者可以直接使用标准扩展类加载器。
（3）应用程序（App）类加载器：是由 Sun 的 AppClassLoader（sun.misc.Launcher$AppClassLoader）实现的。它负责将系统类路径（CLASSPATH）中指定的类库加载到内存中。开发者可以直接使用应用程序类加载器。由于这个类加载器是ClassLoader中的getSystemClassLoader()方法的返回值，因此一般称为系统（System）加载器。
双亲委托模型的主要工作过程：
如果一个类加载器收到了类加载请求，它首先不会自己去尝试加载这个类，而是把请求委派给父类加载器去完成，每一个层次的类加载器都是如此，因此所有的加载请求最终都应该传送到顶层的启动类加载器中，只有当父类加载器反馈自己无法完成这个加载请求时（它的搜索范围中没有找到所需的类）时，子加载器才会尝试自己去加载。
使用双亲委派模型来组织类加载器之间的关系，使得Java类随着它的类加载器一起具备了一种带有优先级的层次关系。例如类java.lang.String，它存放在rt.jar之中，无论哪一个类加载器要加载这个类，最终都要委托给处于模型最顶端的启动类加载器进行加载，因此String类在程序的各种类加载器环境中都是同一个类。相反如果没有使用双亲委派模型，由各个类加载器自行去加载的话，如果用户自己编写了一个称为java.lang.String的类，并放在程序的ClassPath中，那系统中将会出现多个不同的Object类，Java类型体系中最基础的行为也就无法保证，应用程序也将会一片混乱。
JVM在搜索类的时候，是如何判定两个class是相同的？
JVM在判定两个class是否相同时，不仅要判断两个全限定类名是否相同，而且要判断是否由同一个类加载器实例加载的。只有两者同时满足的情况下，JVM才认为这两个class是相同的。就算两个class是同一份class字节码，如果被两个不同的ClassLoader实例所加载，JVM也会认为它们是两个不同class。
最后：打一个小广告，后续的文章会在微信公众号“程序员之家QAQ”推送，欢迎大家搜索关注~~
