【JVM】双亲委派模型

双亲委派模型（面试高频）

之所以这个东西面试出场概率高高，最大的原因就是它起的名字很好听

描述了查找 .class 文件的策略。

类加载器

JVM 中进行类加载的操作，是有一个专门的模块，称为“类加载器”（ClassLoader）。JVM 中的类加载器默认是由三个（也可以自定义个数）

类加载器的作用，给它一个“权限定类名”（带有包的类名（java. lang. String）），给了之后，就找到对应的 .class 文件。这里的类加载器就是从不同的目录中进行查找

1. BootstrapClassLoader
   • 负责查找标准库的目录
2. ExtensionClassLoader
   • 负责查找扩展库的目录
   • Java 语法的规范里面描述了标准库中应该有哪些功能。实现 JVM 的厂商/组织会在标准库的基础上扩充一些额外的功能（JVM 内置的，不同的厂商扩展的可能不太一样）
   • 这块内容在上古时期用处比较多，但随着时代的发展，这里的内容很少会使用了
3. ApplicationClassLoader
   • 负责查找当前项目的代码目录，以及第三方库的目录

上述的三个类加载器，存在“父子关系”

image.png|249

• 不是面向对象中的，父类子类继承关系
• 而是类似于“二叉树”。有一个指针（引用）parent，指向自己的“父”类加载器

双亲委派模型，就描述了上述类加载器之间是符合配合工作的

工作过程

双亲委派模型工作过程：

1. 从 ApplicationClassLoader 作为入口，先开始工作
2. ApplicationClassLoader 不会立即搜索自己负责的目录，会把搜索的任务交给自己的父亲
3. 代码就进入到 ExtensionClassLoader 范畴了，但它也不会立即搜索自己负责的目录，也要把搜索的任务交给自己的父亲
4. 代码就进入到 BootstrapClassLoader 范畴了，它也不想立即搜索自己负责的目录，也想把搜索的任务交给自己的父亲
5. BooststracpClassLoader 发现自己没有父亲，才会真正搜索负责的目录（标准库目录），通过全限定类名，尝试在标准库目录中找到符合要求的 .class 文件
   • 如果找到了，接下来就直接进入到打开文件/读文件等流程中
   • 如果没找到，就回到孩子这一辈的类加载器中，继续尝试加载
6. ExtensionClassLoader 收到父亲交回给他的任务之后，自己进行搜索负责目录（扩展库的目录）
   • 如果找到了，接下来就进入到后续流程
   • 如果没找到，也就再回到孩子这一辈的类加载器中继续尝试加载
7. ApplicationClassLoader 收到父亲交回给他的任务之后，自己进行搜索负责的目录（当前项目目录/第三方库目录）
   • 如果找到了，接下来就进入后续流程
   • 如果没找到，也是回到孩子这一辈的类加载器中尝试继续加载。但是由于默认情况下 ApplicationClassLoader 没有孩子了，此时说明类加载过程失败了，就会抛出 ClassNotFoundException 异常

存在意义

上述设定的最主要的目的就是为了确保这几个类加载器之间的优先级

按照上述的顺序，假定在代码中自己定义了一个 java.lang.String 这样的类。最终程序执行效果是：自定义的类不会被 JVM 加载

• 因为当我们拿着这个类给类加载器找的时候，先 BootstrapClassLoader 到标准库中找，就找到了这个类，直接就从标准库中加载了，就不会回到 ApplicationClassLoader （你自己写的代码中）这一层进行加载 设定就是为了避免你写的类的名字和标准库的重复了，导致标准库的类的功能失效