JVM 通过双亲委派模型进行类的加载，即当某个类加载器在接到加载类的请求时，首先将加载任务委托给父类加载器，依次递归，如果父类加载器可以完成类加载任务，就成功返回;只有父类加载器无法完成此加载任务时，才自己去加载。
类加载器
- 启动类加载器 (Bootstrap ClassLoader) ：负责加载 JAVA_HOME\lib 目录中的，或通过 - Xbootclasspath 参数指定路径中的，且被虚拟机认可(按文件名识别，如 rt.jar，名字不符合的类库即使放在 lib 目录也不会被加载)的类。启动类加载器无法被 Java 程序直接引用;
- 扩展类加载器 (Extension ClassLoader) ：负责加载 JAVA_HOME\jre\lib\ext 目录中的，或通过 java.ext.dirs 系统变量指定路径中的类库;
- 应用程序类加载器 (Application ClassLoader) ：负责加载用户路径(classpath)上的类库。
- 通过继承 java.lang.ClassLoader 类实现自定义类加载器(主要是重写 findClass 方法)。
小结： 类加载器和字节码是Java平台无关性的基石，对于任意一个类，都需要由它的类加载器和这个类本身一同确立其在Java虚拟机中的唯一性。
双亲委派模型的优点：
- 基础类的统一加载问题(越基础的类由越上层的加载器进行加载)。如类 java.lang.String，无论哪一个类加载器要加载这个类，最终都是委派给启动类加载器进行加载，所以在程序的各种类加载器环境中都是同一个类。
- 提高 java 代码的安全性。比如说用户自定义了一个与系统库里同名的 java.lang.String 类，那么这个类就不会被加载，因为最顶层的类加载器会首先加载系统的 java.lang.String 类，而不会加载自定义的 String 类，防止了恶意代码的注入。
- 可以避免类的重复加载，另外也避免了 Java 的核心 API 被篡改。
类加载流程
类的生命周期会经历以下 7 个阶段：
加载阶段
此阶段用于查到相应的类(通过类名进行查找)并将此类的字节流转换为方法区运行时的数据结构，然后再在内存中生成一个能代表此类的 java.lang.Class 对象，作为其他数据访问的入口。
验证阶段
此步骤主要是为了验证字节码的安全性，如果不做安全校验的话可能会载入非安全或有错误的字节码，从而导致系统崩溃，它是 JVM 自我保护的一项重要举措。
验证的主要动作大概有以下几个：
- 文件格式校验包括常量池中的常量类型、Class 文件的各个部分是否被删除或被追加了其他信息等;
- 元数据校验包括父类正确性校验(检查父类是否有被 final 修饰)、抽象类校验等;
- 字节码校验，此步骤最为关键和复杂，主要用于校验程序中的语义是否合法且符合逻辑;
- 符号引用校验，对类自身以外比如常量池中的各种符号引用的信息进行匹配性校验。
准备阶段
此阶段是用来初始化并为类中定义的静态变量分配内存的，这些静态变量会被分配到方法区上。
HotSpot 虚拟机在 JDK 1.7 之前都在方法区，而 JDK 1.8 之后此变量会随着类对象一起存放到 Java 堆中。
解析阶段
此阶段主要是用来解析类、接口、字段及方法的，解析时会把符号引用替换成直接引用。
所谓的符号引用是指以一组符号来描述所引用的目标，符号可以是任何形式的字面量，只要使用时能无歧义地定位到目标即可;而直接引用是可以直接指向目标的指针、相对偏移量或者是一个能间接定位到目标的句柄。
符号引用和直接引用有一个重要的区别：使用符号引用时被引用的目标不一定已经加载到内存中;而使用直接引用时，引用的目标必定已经存在虚拟机的内存中了。
初始化
初始化阶段 JVM 就正式开始执行类中编写的 Java 业务代码了。到这一步骤之后，类的加载过程就算正式完成了。
总结
如上图所示，浅绿的两个部分表示类的生命周期，就是从类的加载到类实例的创建与使用，再到类对象不再被使用时可以被 GC 卸载回收。
这里要注意一点，由 Java 虚拟机自带的三种类加载器加载的类在虚拟机的整个生命周期中是不会被卸载的，只有用户自定义的类加载器所加载的类才可以被卸载。
