前言
在上一篇文章中，荔枝梳理了有关Java中JVM体系架构的相关知识，其中涉及到的有关Java类加载机制的相关知识并没有过多描述。那么在这篇文章中，荔枝会详细梳理一下有关JVM的类加载机制和双亲委派模型的知识，希望能够帮助到有需要的小伙伴~~~
文章目录
一、JVM中类加载过程
在前面JVM体系结构一文中我们知道运行Java程序的过程首先编译器会将.Java文件编译成字节码文件并由JVM中的类加载机制进行加载和并发送指令给执行引擎执行。而对于类来说，它的生命周期主要经历7个阶段：加载、验证、准备、解析、初始化、使用、卸载，其中前五个阶段就是类加载的过程。需要注意的是，类加载过程并不是严格意义上的按顺序经历上面的五个阶段，这些阶段可能会互相混合、交叉运行。接下来看看五个阶段的类加载的内容：
加载
加载阶段是将类的字节码文件加载到JVM中的内存中，并在内存中生成对应的Class对象。类加载器根据类的全限定名（类的包名+类名）来查找字节码文件，找到后读取字节码数据，转化成方法区的运行时数据结构并在Java堆中生成对应的Java.lang.Class对象，作为对方法区中这些数据的访问入口。
类加载器可以是Java虚拟机自带的类加载器，也可以是自定义的类加载器。
连接
我们一般把验证、准备和解析这三个状态归到一块作为连接的阶段， 连接阶段将类的字节码文件中的符号引用转换为直接引用，生成可执行的代码。
验证
验证阶段的目的是保证字节码文件中的字节流内容符合Java虚拟机的规范。一般来说验证阶段会进行文件格式验证、元数据验证、字节码验证和符号引用验证。
- 文件格式验证：验证字节流是否符合Class文件格式的规范。例如：是否以0xCAFEBABE开头、主次版本号是否在当前虚拟机的处理范围之内、常量池中的常量是否有不被支持的类型；
- 元数据验证：对字节码描述的元数据信息进行语义分析，要符合Java语言规范。例如：是否继承了不允许被继承的类（例如final修饰过的）、类中的字段、方法是否和父类产生矛盾等；
- 字节码验证：对类的方法体进行校验分析，确保这些方法在运行时是合法的、符合逻辑的。
- 符号引用验证 ：发生在解析阶段，符号引用转为直接引用的时候，例如：确保符号引用的全限定名能找到对应的类、符号引用中的类、字段、方法允许被当前类所访问等等
准备
在准备阶段类的静态字段信息会得到内存分配，并设置为初始值，其中静态字段信息指的是被static关键字修饰的变量。
解析
这个阶段，虚拟机会把这个Class文件中，常量池内的符号引用转换为直接引用。主要解析的是类或接口、字段、类方法、接口方法、方法类型、方法句柄等符号引用。
初始化
初始化阶段是类加载的最后一个阶段，也是真正执行类的初始化代码块和静态变量初始化的阶段。在这个阶段，JVM会按照程序员指定的顺序执行类的静态初始化代码块和静态变量的初始化，这些初始化代码会在类第一次使用时被调用。初始化是类加载过程中的最后一个步骤，直到此阶段完成，类才算完全加载并可以使用。
需要注意的是：在整个类加载过程中，类加载器负责加载和连接阶段，而初始化阶段由JVM负责。
二、类加载器
类加载器，其实就是一个可以将Java编译后的字节码文件加载为可以被java.lang.class实例化的工具，负责将字节码文件转化成为JVM内部的Class对象。
类加载器的分类
**启动类加载器（Bootstrap ClassLoader）：**负责加载%JAVA_HOME%/lib 目录，或者被 -Xbootclasspath 参数制定的路径，例如 jre/lib/rt.jar 里所有的class文件。由C++实现，不是ClassLoader子类。
**拓展类加载器（Extension ClassLoader）：**负责加载Java平台中扩展功能的一些jar包，包括<JAVA_HOME>\lib\ext 目录中 或 java.ext.dirs 指定目录下的jar包。由Java代码实现。
**应用程序类加载器（Application ClassLoader）：**我们自己开发的应用程序，就是由它进行加载的，负责加载ClassPath路径下所有jar包。
**自定义类加载器（User ClassLoader）：**通过继承java.lang.ClassLoader实现自定义的类加载
类加载器的特点
- 按需加载：无需在程序一开始运行的时候加载所有的字节码文件，而是在程序运行的过程中，动态按需加载，字节码的来源也很多，压缩包jar、war中，网络中，本地文件等。类加载器按需加载的特点为热部署，热加载做了有力支持。
- **全盘负责：**当一个类加载器加载一个类时，这个类所依赖的、引用的其他所有类都由这个类加载器加载，除非在程序中显式地指定另外一个类加载器加载。所以破坏双亲委派不能破坏扩展类加载器以上的顺序。
- 双亲委派：类加载器遵循双亲委派模型，即加载类时，首先委派给父类加载器处理。只有父类加载器无法加载时，才由子类加载器尝试加载。双亲委派模型保证了类的加载在整个类加载器层次中的一致性，避免类的重复加载和冲突。
- 自定义扩展：开发者可以继承java.lang.ClassLoader类，实现自定义的类加载器。通过自定义类加载器，可以实现特定的类加载行为，打破双亲委派模型，加载特定位置的类文件，满足特定需求。
三、双亲委派机制
JVM 并不是在启动时就把所有的Class文件都加载一遍，而是程序在运行过程中用到了这个类才去加载，而通常这个类加载过程就会基于双亲委派机制来实现。双亲委派是JVM中对类加载的一种模式机制，即任意一个类在接到一个类的加载请求时，都会先加载其父类，若父类无法加载(或无父类)的情况下，再尝试自己加载或者给子类加载，总的来说就是向上委派、向下加载的过程。
双亲委派机制流程
用直白的语言来描述一下双亲委派的流程：
- 在当前的类加载器收到类加载请求时，会首先检查是否之前加载过该类，如果加载过就将该类所对应的Class对象返回出去并完成类加载请求响应。
- 如果该类没有被加载过，当前的类加载器则会将该加载请求委派给父类加载器处理。父类加载器按照同样的递归方式向上委派该类加载请求，即首先检查该类是否已经被加载过，如果已经被加载过，则返回对应的Class对象。如果父类加载器也没有加载过这个类，则将加载请求再委派给父类的父类的加载器，直到达到顶层的启动类加载器。
- 如果顶层的启动类加载器也没有加载过这个类，则当前类加载器尝试自己加载这个类。如果启动类加载器加载该类失败（加载路径下找不到该class文件），就会将加载向下委派给其子类的类加载器直至自定义类加载器；
- 如果自定义类加载器也无法加载该类，就会排除ClassNotFound异常。
双亲委派机制的优点
前面我们已经知晓双亲委派机制是向上委派、向下加载的。这种执行方式就能够有效保证了类都是在同一个类加载器中加载并构造对象的。同时由于类总是从父类中开始加载的，也保证了官方JDK代码包的安全性，具体的优点如下：
-
避免类的重复加载：通过双亲委派机制，当一个类加载器加载一个类时，它会首先委派给父类加载器处理。如果父类加载器已经加载了这个类，就不需要再次加载，直接返回已加载的Class对象。这样可以避免同一个类被不同的类加载器加载，保证类的唯一性，避免类的重复加载，节省了内存空间。
-
保证代码安全性：通过双亲委派机制，JVM的核心类库（如java.lang、java.util等）由启动类加载器加载，这些类库被放置在JVM的核心路径下，由Java官方提供，保证了这些类的安全性和稳定性。用户自定义的类则由应用类加载器加载，用户可以控制这些类的访问权限，从而提高了应用程序的安全性。
-
确保类的一致性：通过双亲委派机制，JVM保证了类加载的一致性。无论是系统核心类库还是用户自定义的类，它们都是由类加载器层次结构中的某个类加载器加载的，这样可以保证类在整个JVM中的唯一性和一致性，避免类的冲突和不一致性。
-
代码隔离：双亲委派机制将类的加载委派给父类加载器处理，子类加载器无法直接访问父类加载器加载的类，这样实现了类加载器之间的代码隔离。不同的类加载器可以加载相同名称的类，但它们加载的类是不同的，从而实现了类的隔离，不同的类加载器可以加载自己的版本，相互之间不会相互干扰。
如何打破双亲委派机制
在某些特定的场景下，我们需要打破JVM类加载中的双亲委派机制，比如我们想要加载一些于JVM核心类库同名的类并且希望这些类由用户自定义的类加载器加载，而不是受到父类加载器的影响。打破双亲委派机制的两种方式：
- 自定义类加载器并继承ClassLoader类，重写该类的方法如findClass和loadClass；
- 通过线程上下文类加载器的传递性并让父类加载器调用子类加载器的加载动作。
总结
以上就是JVM中有关类加载机制的相关知识点了，其中最重要的就是双亲委派机制的理解和两种打破方式的了解，这里其实荔枝写的不是特别详细，可能需要在阅读完源码之后才能输出更有质量的自我理解吧。大致了解了JVM的类加载机制，接下来的文章中荔枝可能会输出有关JVM另一个核心知识点：GC垃圾回收机制的相关知识的梳理，希望能够帮助到大家哈哈哈~~~
今朝已然成为过去，明日依然向往未来！我是小荔枝，在技术成长的路上与你相伴，码文不易，麻烦举起小爪爪点个赞吧哈哈哈~~~ 比心心♥~~~