好用的类加载器-双亲委派模型

---

前言

类加载器特别重要，因为类加载器和被其所加载的类构成了一个类在虚拟机中的唯一性，每个类加载器拥有自己独立的命名空间，对比两个类是否相等（equal（）等方式）的前提就是两个类是否是由一个类加载器加载出来的。

---

1.双亲委派模型（三层类加载器）

启动类加载器

开发者不能使用，由C++写成，这个类加载器负责加载存放在 \lib目录，或者被-Xbootclasspath参数所指定的路径中存放的，而且是Java虚拟机能够 识别的（按照文件名识别，如rt.jar、tools.jar，名字不符合的类库即使放在lib目录中也不会被加载）类 库加载到虚拟机的内存中。

扩展类加载器

扩展类加载器（Extension Class Loader）：这个类加载器是在类sun.misc.Launcher$ExtClassLoader 中以Java代码的形式实现的。它负责加载\lib\ext目录中，或者被java.ext.dirs系统变量所 指定的路径中所有的类库。根据“扩展类加载器”这个名称，就可以推断出这是一种Java系统类库的扩 展机制，JDK的开发团队允许用户将具有通用性的类库放置在ext目录里以扩展Java SE的功能，在JDK 9之后，这种扩展机制被模块化带来的天然的扩展能力所取代。由于扩展类加载器是由Java代码实现 的，开发者可以直接在程序中使用扩展类加载器来加载Class文件。

应用程序类加载器

也叫系统类加载器，它负责加载用户类路径 （ClassPath）上所有的类库，开发者同样可以直接在代码中使用这个类加载器。如果应用程序中没有 自定义过自己的类加载器，一般情况下这个就是程序中默认的类加载器。

2.双亲委派模型工作原理

所有类加载器需要实现如图所示结构：看上去是继承，实际是以组合方式实现的父子关系

其原理是，每当一个类加载器收到类加载请求时，都第一时间传给自己的父加载器，所以这个请求最后一定会到达启动类即最上面的类加载器的，如果加载不了，再把这个请求逐渐往下递交。
拿到加载请求首先调用父加载器的loadClass方法，方法为空就转到启动类加载器，加载失败就调用自己的findClass方法进行加载。
这个模型的好处是：当处理某些最基本的类加载请求时，比如Object类的加载，一定会是第一个完成的，毕竟这种类都需要上交到最上面的类加载器，最上面的类加载器永远是第一个考虑是否加载类的加载器。

3.破坏双亲模型

第一次破坏

自定义类加载器出现初期，设计者面对已经出现的大量用户自定义的类加载器做出妥协，为了避免用户继承父类加载器后重写了loadClass方法导致父类的loadclass方法不能调用，设计了findClass方法并鼓励用户去重写该方法实现这个类加载器本身的加载逻辑而不会影响到父类加载器，前文已提到这两个方法。

第二次破坏

有些基础类需要去调用不基础的类，一般是调用用户写的类，这个时候父类加载器就需要委托子类加载器去加载而不是之前的子委托父的模型，设计者采用偷懒的方式通过一种加载器向子类发送请求，破坏了双亲模型

第三次破坏

因为动态这一词越来越火热，热部署等等越来越重要，即要求在程序运行时改变某个模块但不影响整个程序的运行，设计者想了一个方法，每个模块自己拥有一个类加载器，这样的话，当跨模块操作时，平级之间的请求越来越多，破坏了双亲模型。