前言
上一篇文章，我们了解到类的加载流程，是由加载，验证，准备，解析，初始化这5个阶段组成的。我们也对这5个阶段进行了较为详细的解读，在这个解读的过程中，我们发现，类加载器主要是在加载阶段起到了作用。当然，我们当时没有对类加载器有进一步的了解，而今天的这篇文章，就主要集中在了类加载器身上。
在文章开始之前，我们要先明白一件事情，即便我们对类加载器有了深刻的了解，也不代表着我们对类加载的整个流程有了多大的认知，这只能说是我们在JVM这个浩瀚的海洋中，捞取了小小的一瓢水而已，微不足道，且无足挂齿。所有我们要抱着一颗谦虚的心态，去不停的学习，时时刻刻的进步。
发散的差不多了，接下来，让我们正式进入到类加载器的世界吧。
类加载器的缘来
类加载器是从jdk1.0就已经出现了，最初是为了满足 Java Applet 的需要而开发出来的。
Applet可以翻译为小应用程序，Java Applet就是用Java语言编写的这样的一些小应用程序，它们可以直接嵌入到网页中，并能够产生特殊的效果。包含Applet的网页被称为Java-powered页，可以称其为Java支持的网页。
也因此，Java Applet需要从远程网络中下载java类文件到浏览器中并执行，那么，如何保证java类文件是合法的，是符合规范的呢？于是java就创造了applet类加载器来将java文件载入，applet类加载器会保证来自文件系统的类有唯一的名称空间，来自网络资源的类有唯一的名称空间。
当浏览器通过网络载入applet的时候，applet的类被放置于和applet的源相关联的私有的名称空间中。然后，那些被类加载器载入进来的类都是通过了验证器验证的。验证器会检查类文件格式是否遵守Java语言规范，确保不会出现堆栈溢出(stackoverflow)或者下溢(underflow)，传递给字节码指令的参数是正确的。
今天用在浏览器上的Java Applet技术基本上已经被淘汰，但类加载器却在类层次划分、OSGi、程序热部署、代码加密等领域大放异彩，成为Java 技术体系中一块重要的基石。
类加载器的作用
什么是类加载器？从我个人的理解来看，类加载器用来加载java类到JVM中。
在官方的文档里面写道：类加载器就是把类文件加载到虚拟机中,也就是说通过一个类的全限定名来获取描述该类的二进制字节流。
在这里必须要说一下，什么是java类的全限定名。就拿我们最经常用的String类来说，它的全限定名是
“java.lang.String”，也就是说，java类的全限定名是：包名+类名。
与之对应的就是java的非限定类名，也叫短名，也就是我们说的类名，例如：String。
一般来说，java源程序，也就是java文件通过java编译器编译之后就会被转换成java字节码（.class文件，也就是字节代码，它的表现形式是字节数组byte[]），而我们的类加载器呢，就是负责读取java字节码代码，并且转换成java.lang.Class类的一个实例（这个过程，就是类的加载流程中一个步骤：加载），并且将这个class对象加载到虚拟机的内存中。
<table><tr><td>
什么是java.lang.Class类？
Java的基本思想之一是万事万物即对象，类也是一种对象。但是类是什么对象呢？Java中的类是java.lang.Class的实例化对象，这被成为类类型。
Java程序在运行时，Java运行时系统一直对所有的对象进行所谓的运行时类型标识。这项信息纪录了每个对象所属的类。虚拟机通常使用运行时类型信息选准正确方法去执行，用来保存这些类型信息的类是Class类。Class类封装一个对象和接口运行时的状态，当装载类时，Class类型的对象自动创建。
Class 没有公共构造方法。Class 对象是在加载类时由 Java 虚拟机以及通过调用类加载器中的 defineClass 方法自动构造的，因此不能显式地声明一个Class对象。
虚拟机为每种类型管理一个独一无二的Class对象。也就是说，每个类（型）都有一个Class对象。运行程序时，Java虚拟机(JVM)首先检查是否所要加载的类对应的Class对象是否已经加载。如果没有加载，JVM就会根据类名查找.class文件，并将其Class对象载入。
</td></tr></table>
当需要使用某个类时（因此我们要知道，在java中，类是按照需要才会加载的），类加载器将会加载它的".class"文件，并创建对应的class对象，将class文件加载到虚拟机的内存。
因此，每个这样的实例用来表示一个java类，通过此实例的newInstance()方法就可以创建出该类的一个对象。
类加载器虽然只用于实现类的加载动作，但它在Java程序中起到的作用却远超类加载阶段。对于任意一个类，都必须由加载它的类加载器和这个类本身一起共同确立其在Java虚拟机中的唯一性，每一个类加载器，都拥有一个独立的类名称空间。这句话可以表达得更通俗一些：比较两个类是否“相等”，只有在这两个类是由同一个类加载器加载的前提下才有意义，否则，即使这两个类来源于同一个Class文件，被同一个Java虚拟机加载，只要加载它们的类加载器不同，那这两个类就必定不相等。
类加载器的种类
站在Java虚拟机的角度来看，只存在两种不同的类加载器：一种是启动类加载器（Bootstrap ClassLoader），这个类加载器使用C++语言实现，是虚拟机自身的一部分；另外一种就是其他所有的类加载器，这些类加载器都由Java语言实现，独立存在于虚拟机外部，并且全都继承自抽象类 java.lang.ClassLoader。
但是，一般来说，我们会把类加载器分的更加细致一点，在我们开发人员看来，在JVM中，类加载一般分为了三种，然后除了JVM自带的三种类加载器以外，还有我们用户自己可以创建开发的类加载器，从这个角度来看，类加载器是有四种。那么，类加载器都是哪四种呢？
1. 启动类加载器（Bootstrap Class Loader）
启动类加载器属于虚拟机的一部分，它是用C++写的，看不到源码，是属于java虚拟机的一部分，而其他类加载器是用Java写的，还能看到源码的。
这个类加载器负责加载存放在 <JAVA_HOME>\lib目录，或者被-Xbootclasspath参数所指定的路径中存放的，而且是Java虚拟机能够识别的（按照文件名识别，如rt.jar、tools.jar，名字不符合的类库即使放在lib目录中也不会被加载）类库加载到虚拟机的内存中。
启动类加载器无法被Java程序直接引用，用户在编写自定义类加载器时， 如果需要把加载请求委派给启动类加载器去处理，那直接使用null代替即可。
2. 扩展类加载器（Extention Class Loader）
扩展类加载器是指JVM实现的 sun.misc.Launcher $ ExtClassLoader类，由Java语言实现的，是Launcher的静态内部类。
[图片上传失败...(image-3ef66-1612228935281)]
主要加载JAVA中的一些拓展类，java.ext.dirs目录中加载类库，或者从JDK安装目录：jre/lib/ext目录下加载类库,是启动类加载器的子类。
这是一种Java系统类库的扩展机制，JDK的开发团队允许用户将具有通用性的类库放置在ext目录里以扩展Java SE的功能，在JDK9之后，这种扩展机制被模块化带来的天然的扩展能力所取代。由于扩展类加载器是由Java代码实现的，开发者可以直接在程序中使用扩展类加载器来加载Class文件。
3. 应用程序类加载器（Application Class Loader）
Java语言编写，由sun.misc.Launcher$AppClassLoader实现。派生继承自java.lang.ClassLoader，父类加载器为启动类加载器。
它负责加载环境变量classpath或者系统属性java.class.path指定路径下的类库，它是程序中默认的类加载器，我们Java程序中的类，都是由它加载完成的。我们可以通过ClassLoader#getSystemClassLoader()获取并操作这个加载器。
由于应用程序类加载器是ClassLoader类中的getSystemClassLoader()方法的返回值，所以有些场合中也称它为“系统类加载器”。它负责加载用户类路径 （ClassPath）上所有的类库，开发者同样可以直接在代码中使用这个类加载器。如果应用程序中没有自定义过自己的类加载器，一般情况下这个就是程序中默认的类加载器。
4. 自定义类加载器（User Class Loader）
jdk9之前的java应用都是以上的三种类加载器相互配合来完成加载的，如果用户觉得有必要，还可以自己定义类加载器来进行拓展。
而一般来说，加入自己定义的类加载器的目的如下（不是全部情况，仅是举例说明）：
- 增加除了磁盘位置之外的Class文件来源。
- 通过类加载器实现类的隔离、重载等功能。
- 网络加载Java类，为了保证传输中的安全性，采用了加密操作，那么以上3种加载器就无法加载这个类，这时候就需要自定义加载器。
那么，如何自定义类加载器呢？
- 继承java.lang.ClassLoader类，重写findClass()方法
- 如果没有太复杂的需求，可以直接继承URLClassLoader类，重写loadClass方法，具体可参考AppClassLoader和ExtClassLoader（我在上面已经截图说明了，请注意，这种方案会打破双亲委派模型）。
什么时候进行类加载
- 创建类的实例，也就是new一个对象
- 访问某个类或接口的静态变量，或者对该静态变量赋值
- 调用类的静态方法
- 反射（Class.forName("com.lyj.load")）
- 初始化一个类的子类（会首先初始化子类的父类）
- JVM启动时标明的启动类，即文件名和类名相同的那个类
除此之外，下面几种情形需要特别指出：
对于一个final类型的静态变量（这种情况在上一篇文章有提及过《从头开始学习JVM（三）：类加载器（上）》），如果该变量的值在编译时就可以确定下来，那么这个变量相当于“宏变量”。Java编译器会在编译时直接把这个变量出现的地方替换成它的值，因此即使程序使用该静态变量，也不会导致该类的初始化。反之，如果final类型的静态Field的值不能在编译时确定下来，则必须等到运行时才可以确定该变量的值，如果通过该类来访问它的静态变量，则会导致该类被初始化。
双亲委派模型
双亲委派模型，其实就是设置的和加载器相关的加载器加载类的优先级顺序问题。
既然说到双亲委派模型，那么先来看一张超级经典的图。图如下：
从图中我们看到，加载器的加载必然是有一个前后顺序的，而这个顺序就是双亲委派模型。
那么，什么是双亲委派模型呢？
如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加载这个类，而是把这个请求委派给父类加载器去完成，每一个层次的类加载器都是如此，因此所有的加载请求最终都应该传送到最顶层的启动类加载器中，只有当父加载器反馈自己无法完成这个加载请求（它的搜索范围中没有找到所需的类）时，子加载器才会尝试自己去完成加载。
那么，使用双亲委派模型的好处是什么呢？
- 避免重复加载。当父亲已经加载了该类时，就没有必要子类加载器再加载一次，从而造成了资源上的浪费，也能保证java核心api加载的类的唯一性，保证了程序的基本行为和逻辑。
- 保证java核心的api不会随意的被替换，保证了一定的安全性。假如我们通过网络传递一个名为java.lang.Integer的类，通过双亲委派模型传递到启动类bootstrap加载器，然后启动类bootstrap加载器在核心java的api中发现了这个名字的类，发现这个类已经被加载了，那么就不会再加载这个类，这也就保证了java的核心api库被随意篡改。
当然，JVM并没有将双亲委派机制当作是一个具有强制性约束的规则，这只是java推荐的一个类加载实现方式，在大部分的时候，这个模型都是能满足用户的所有请求的，但是总有一些时候，我们会发现，这个模型可能不能满足我们的要求。
比如说一下几点的出现，就可能导致双亲委派模型不能满足我们的要求：
- 代码热替换。
- 模块热部署。
- 需要调用由其他厂商实现并部署在应用程序的ClassPath下的JNDI服务提供者接口（Service Provider Interface，SPI）的代码。
当然，这些功能是都需要特地去实现，也是一个仁者见仁智者见智的问题，但是JVM在jdk6的时候已经将第三点解决了，方式是JDK提供了 java.util.ServiceLoader类，以META-INF/services中的配置信息，辅以责任链模式，这才算是给这些类的加载提供了一种相对合理的解决方案。
但是如果是第一点和第二点这些涉及到了热更新热部署的情况，那么我们就不得不去学会破坏双亲委派模型了。
那么问题就来了，如何破坏双亲委派模型呢？
在这里我举两个例子说明一下：
原生的JDBC中Driver驱动本身只是一个接口，并没有具体的实现，具体的实现是由不同数据库类型去实现的。例如，MySQL的mysql-connector-.jar中的Driver类具体实现的。 原生的JDBC中的类是放在rt.jar包的，是由启动类加载器进行类加载的，在JDBC中的Driver类中需要动态去加载不同数据库类型的Driver类，而mysql-connector-.jar中的Driver类是用户自己写的代码，那启动类加载器肯定是不能进行加载的，既然是自己编写的代码，那就需要由应用程序启动类去进行类加载。于是乎，这个时候就引入线程上下文件类加载器(Thread Context ClassLoader)。有了这个东西之后，程序就可以把原本需要由启动类加载器进行加载的类，由应用程序类加载器去进行加载了。
OSGi实现模块化热部署的关键则是它自定义的类加载器机制的实现。每一个程序模块(Bundle)都有一个自己的类加载器，当需要更换一个Bundle时，就把Bundle连同类加载器一起换掉以实现代码的热替换。在OSGi幻境下，类加载器不再是双亲委派模型中的树状结构，而是进一步发展为更加复杂的网状结构，当受到类加载请求时，OSGi将按照下面的顺序进行类搜索：
1.1 将java.＊开头的类委派给父类加载器加载。
1.2 否则，将委派列表名单内的类委派给父类加载器加载。
1.3 否则，将Import列表中的类委派给Export这个类的Bundle的类加载器加载。
1.4 否则，查找当前Bundle的ClassPath，使用自己的类加载器加载。
1.5 否则，查找类是否在自己的Fragment Bundle中，如果在，则委派给Fragment Bundle的类加载器加载。
1.6 否则，查找Dynamic Import列表的Bundle，委派给对应Bundle的类加载器加载。
1.7 否则，类加载器失败。
我们在这两个例子中发现了，想打破双亲委派机制，有两个方法：
- 自定义类加载器，重写loadClass方法。
- 使用线程上下文类加载器。
<table><tr><td>
什么是线程上下文类加载器？
线程上下文类加载器（context class loader）是从 JDK 1.2 开始引入的。类 java.lang.Thread中的方法 getContextClassLoader()和 setContextClassLoader(ClassLoader cl)用来获取和设置线程的上下文类加载器。如果没有通过 setContextClassLoader(ClassLoader cl)方法进行设置的话，线程将继承其父线程的上下文类加载器。Java 应用运行的初始线程的上下文类加载器是系统类加载器。在线程中运行的代码可以通过此类加载器来加载类和资源。
</td></tr></table>
类加载器的代理模式
类加载器在尝试自己去查找某个类的字节代码并定义它时，会先代理给其父类加载器，由父类加载器先去尝试加载这个类，依次类推。
在介绍代理模式背后的动机之前，首先需要说明一下 JVM是如何判定两个 Java 类是相同的。
在上面说到双亲委派机制的时候，我们知道，JVM不仅要看类的全名是否相同，还要看加载这个类的类加载器是否一样。只有两者都相同的情况，才认为两个类是相同的。即便是同样的字节代码，被不同的类加载器加载之后所得到的类，也是不同的。
比如一个 Java 类 com.example.Sample ，编译之后生成了字节代码文件 Sample.class 。两个不同的类加载器 ClassLoaderA 和 ClassLoaderB 分别读取了这个 Sample.class 文件，并定义出两个 java.lang.Class 类的实例来表示这个类。这两个实例是不相同的。对于 Java 虚拟机来说，它们是不同的类。试图对这两个类的对象进行相互赋值，会抛出运行时异常 ClassCastException 。
了解了这一点之后，就可以理解代理模式的设计动机了。
代理模式是为了保证 Java 核心库的类型安全。所有 Java 应用都至少需要引用 java.lang.Object 类，也就是说在运行的时候， java.lang.Object 这个类需要被加载到 Java 虚拟机中。如果这个加载过程由 Java 应用自己的类加载器来完成的话，很可能就存在多个版本的 java.lang.Object 类，而且这些类之间是不兼容的。通过代理模式，对于 Java 核心库的类的加载工作由引导类加载器来统一完成，保证了 Java 应用所使用的都是同一个版本的 Java 核心库的类，是互相兼容的。
不同的类加载器为相同名称的类创建了额外的名称空间。相同名称的类可以并存在 Java 虚拟机中，只需要用不同的类加载器来加载它们即可。不同类加载器加载的类之间是不兼容的，这就相当于在 Java 虚拟机内部创建了一个个相互隔离的 Java 类空间。
总结
当我们在学习类加载器的时候，我们会发现，其实我们对java底层的代码，很明显是非常的不熟悉。我们要意识到，所谓的JVM其实只是概念上的东西，而去实现JVM的，其实就是我们底层的java代码。
比如，我们的ExtClassLoad，AppClassLoad，这两个加载器，其实都是java底层的一个类Launcher的静态内部类。
因此，如果我们仅仅只是对JVM的一些理论牢记于心的话，那就只能说我们对JVM有了一些肤浅的了解，算不上有多深入。
下一篇文章，《从头开始学习JVM（五）：类加载器（下）》，我将会尝试讲解关于类加载器的底层代码，以及自己手写属于自己的类加载器。
参考博客
https://blog.csdn.net/m0_38075425/article/details/81627349
https://blog.csdn.net/javazejian/article/details/73413292
https://developer.ibm.com/zh/articles/j-lo-classloader/
参考书籍
周志明《深入理解java虚拟机》
