共计 2732 个字符，预计需要花费 7 分钟才能阅读完成。
1. 类加载机制概述
2. 类加载的过程
3. 类加载器
4. 双亲委派模型
1. 类加载机制概述
上一篇文章：深刻了解 JVM（一）——JVM 简介和运行时数据区构造
次要解说了 JVM 的组成部分以及运行时数据区的组成部分，这节咱们来讲一下类加载子系统。
所谓的类加载机制：
就是虚拟机把形容类的数据从 class 加载到内存，并对数据进行校验，解析和初始化，最终造成能够被虚拟机间接应用的 JAVA 类型，这就是虚拟机的加载机制。
2. 类加载的过程
类从硬盘加载到内存，到卸载出内存，整个生命周期包含：加载，验证，筹备，解析，初始化，应用，卸载。（加验准解初使卸）
验证，筹备，解析 3 个局部统称为链接。
接下来咱们将对以上步骤挨个进行剖析：
2.1 加载
加载，是类加载的第一个阶段，心愿读者不会混同这两个很类似的词语。在加载阶段，虚拟机要实现以下三个事件：
1）通过一个全限定名（包名 + 类名）来获取定义此类的二进制字节流。
2）将这个字节流的字段信息转化为办法区的运行时数据结构。
3）在内存中是生成一个此类的对象，作为办法区这个类的各种数据的拜访入口。
简略地来说，就是通过包名 + 类名把类加载到内存中，而后在办法区中生成该类的模板，供类在新建对象的时候应用。
2.2 验证
验证是连贯的第一步，这一阶段的目标是为了确保 Class 文件字节流的内容合乎虚拟机标准，并且不会危害虚拟机本身平安。
JAVA 自身是一门绝对平安的语言，无奈做到拜访数据边界之外的数据，跳转到不存在的代码之类的事件，然而上述 JAVA 代码无奈做到的事件，字节码层面却都是能够做到的，所以虚拟机如果不查看输出的字节流，很可能因为载入了无害的字节流导致系统的解体。所以验证是非常重要的，这个阶段是否谨严，间接决定了 JAVA 虚拟机是否能接受歹意的代码的攻打。
从整体上看，验证阶段大抵会实现上面 4 个阶段的查看动作：文件格式验证，元数据验证，字节码验证，符号援用验证。
1）文件格式验证
第一阶段要验证字节流是否合乎 class 标准，举例如下：
是否以魔数 0xCAFEBABE 结尾
主次版本号是否在以后虚拟机解决范畴之内
常量池中的常量是否有不被反对的常量类型
等等
该阶段次要目标确保输出的字节流能正确地解析并存储于办法区之内，只有通过了这个阶段的验证后，字节流才会进入内存你的办法区中进行存储，所以前面的 3 个验证阶段全部都是基于办法区的存储构造进行的，不会操作字节流。
2）元数据验证
对字节码形容的信息进行语义剖析，以保障其形容的信息合乎 java 语言标准的要求：
这个类是否有父类
这个类的父类是否继承了不容许被继承的类
如果这个类不是抽象类，是否实现了其父类或接口之中要求实现的所有办法
类中的字段，办法是否与父类产生矛盾
次要对类的元数据信息进行语义校验，保障不存在不合乎 java 语言标准的元数据信息。
3）字节码验证
最简单的一个阶段，次要目标通过数据流和控制流剖析，确定程序语义是非法的，合乎逻辑的。
保障任意时刻操作数栈的数据类型与指令代码序列都能配合呈现工作，不会呈现相似：在操作栈避免了一个 int 类型的数据，应用时却按 long 类型来加载入本地变量表中
保障跳转指令不会跳转到办法体以外的字节码指令上
4）符号援用验证
最初一个阶段的校验产生在虚拟机将符号援用转化为间接援用的时候，这个转化动作将在链接的第三个阶段 - 解析阶段产生。能够看做是对类本身以外（常量池中的各种符号援用）的信息进行匹配性校验，通常须要校验以下内容：
符号援用通过字符串形容的全限定名是否能找到对应的类
在指定类中是否存在合乎办法的字段描述符以及简略名称所形容的办法和字段
符号援用中的类，字段，办法的拜访性是否能够被以后类拜访
2.3 筹备
筹备阶段是正式为变量分配内存并设置变量初始值的阶段，这些变量所应用的的内存都将在办法区内进行调配。
这个时候进行内存调配的仅仅蕴含类变量（被 static 润饰的变量），而不包含实例变量。
2.4 解析
解析阶段是虚拟机将常量池内的符号援用替换为间接援用的过程
解释一下这两种援用的概念。
符号援用：符号援用以一组符号来形容援用的指标，符号能够是任何模式的字面量，只有应用时能无歧义地定位到指标即可。例如 org.simple.People 类援用了 org.simple.Language 类，在编译时 People 类并不知道 Language 类的理论内存地址，因而只能应用符号 org.simple.Language 来代替。
间接援用：间接援用就是能够间接指向指标的指针。就是该对象曾经被调配了内存地址，并且曾经指向该内存地址。
2.5 初始化
类的初始化是类加载过程中的最初一步，后面的过程中，除了加载阶段用户应用程序能够通过自定义类加载器参加之外，其余动作齐全由虚拟机主导和管制。到了初始化阶段，才真正开始执行类中定义的 java 程序代码。
对于初始化，咱们都看过一张图，我置信大家对于这张图曾经很理解了。
3. 类加载器
接下来咱们介绍类加载器，在之前“加载”这个阶段的时候咱们说过，虚拟机通过全限定名来获取二进制字节流，实现这个动作的就是类加载器。
类加载器个别有四种
启动类加载器，扩大类加载器，应用程序类加载器，自定义类加载器。
4. 双亲委派模型
在理解每一个类加载器之前，咱们先理解一下双亲委派模型：
双亲委派模型：
双亲委派模型的工作过程是：如果一个类加载器收到了类加载的申请，它首先不会本人去尝试加载这个类，而是把这个申请委派给父类加载器去实现，每一个档次的类加载器都是如此，因为所有的类加载器申请最终都应该传送到顶层的启动类加载器中，只有当父类加载器反馈本人无奈实现这个加载申请时，子类加载器才会尝试本人加载。
疏导类加载器，次要加载 rt.jar 外面的类文件
咱们相熟的 String，Object 等，等各种 jdk 自带的类型，都存在于 rt.jar 中，这些类都通过疏导类加载器加载。
扩大类加载器，次要加载 ext 包下的类，比方通过 maven，引入的包外面的类，都是通过扩大类加载器加载的。
应用程序类加载器，次要加载本人写的类。
应用双亲委派模型有一个不言而喻的益处就是 java 的类随着它的类加载器一起具备了一种带有优先级的档次关系，例如 Object，它位于 rt.jar 中，无论哪一个类加载器要加载这个类，最终都是委派给处于模型最顶端的启动类加载器进行加载，因而 Object 类在程序中的各种类加载器环境中都是同一个类，相同，如果没有应用双亲委派模型，因为各个类加载器自行加载的话，如果用户本人编写了一个 Object 类，那么就会呈现多个 Object，程序也会一片凌乱。
总结：
明天咱们介绍了类加载的加载过程，分为加载，验证，筹备，解析，初始化，应用，卸载，并且大抵介绍了每一个步骤外面的过程，还介绍了双亲委派模型，以及双亲委派模型的工作过程。
