目录

四、类加载过程

1.类加载过程

2.双亲委派模型（经典面试题）

什么是双亲委派模型

双亲委派模型的优点

 破坏双亲委派模型

---

四、类加载过程

1.类加载过程

咱们写的java代码，是.java文件（硬盘），一个java进程要跑起来，就需要把.java先变成.class文件（硬盘），加载到内存中，得到“类对象”，其中就执行了指令，要执行的CPU指令，都是通过字节码（进入内存中）让JVM翻译出来的

从上⾯的图⽚我们可以看出整个JVM执⾏的流程中，和程序员关系最密切的就是类加载的过程了，所以接下来我们来看下类加载的执⾏流程。

对于⼀个类来说，它的⽣命周期是这样的：

类加载的几个环节（八股）

1.加载：在硬盘上，找到对应的.class文件，读取文件内容

2.验证：检查.class里的内容，是否符合要求

3.准备：给类对象，分配内存空间（元数据区）（类加载最终要得到的就是类对象），会把这个空间里的数据先全都填充为0（此时，如果这个类有静态成员，值就是0）

4.解析：针对字符串常量来初始化，把刚才.class文件中的常量的内容取出来，放到“元数据区”

5.初始化：针对类对象进行初始化（不是针对对象初始化，和构造方法无关），给静态成员进行初始化，执行静态代码块

此时类对象就搞定了

后续代码就可以使用这个类对象，创建实例，或者使用里面的静态成员了

---

2.双亲委派模型（经典面试题）

提到类加载机制，不得不提的⼀个概念就是“双亲委派模型”

站在Java虚拟机的⻆度来看，只存在两种不同的类加载器：⼀种是启动类加载器（Bootstrap  ClassLoader），这个类加载器使⽤C++语⾔实现，是虚拟机⾃⾝的⼀部分；另外⼀种就是其他所有的类加载器，这些类加载器都由Java语⾔实现，独⽴存在于虚拟机外部，并且全都继承⾃抽象类java.lang.ClassLoader。

站在Java开发⼈员的⻆度来看，类加载器就应当划分得更细致⼀些。⾃JDK 1.2以来，Java⼀直保持着三层类加载器、双亲委派的类加载架构器

---

什么是双亲委派模型

它出现在“加载”环节（第一步），根据代码中的写的“全限定类名”（包名+类名）找到对应的.class文件

这个模型描述了JVM加载.class文件过程中，找文件的过程

“类加载模型”在JVM中包含的一个特定的模块/类，这个类负责完成后续的类加载工作

JVM中内置了三个类加载器，负责加载不同的类

1）BootstrapClaaLoader （相当于爷爷）

负责加载标准库的类

2）ExtentionClassLoader（相当于父亲）

负责加载JVM扩展库的类

3）ApplicationClassLoader（相当于儿子）

负责加载第三方库的类 和 自己写的代码的类

 此处的“父子关系”不是通过类的继承表示的（不是父类子类），而是通过类加载器中存在一个“parent”这样的字段，指向自己的父亲，类似于二叉树中的“三叉实现形式”）

“双亲委派模型”本身翻译是不准确的，更准确的翻译：“父亲委派模型”，“单亲委派模型”

工作过程举例：

给定一个类的全限定类名：java111.Test

此时加载过程如下：

（1）工作从ApplicationClassLoader开始进行

ApplicationClassLoader并不会立即搜索第三方库的相关目录，而是把任务交给自己的父亲来进行处理

（2）工作就到ExtentionClassLoader

ExtentionClassLoader也不会立即搜索负责的扩展库的目录，也是把任务交给自己的父亲来处理

（3）工作就来到BootstrapClaaLoader

BootstrapClaaLoader也像交给自己的父亲来处理，但是它的parent指向null，只能自己处理，BootstrapClaaLoader尝试在标准库的路径中搜索上述的类

（4）工作回到了ExtentionClassLoader

此时就要搜索扩展库对应的目录了

如果找到了，就由当前的类加载器负责打开文件，读取文件等后续操作...

如果找不到，任务就还是要继续还给儿子来处理

（5）工作回到了ApplicationClassLoader

此时要搜索第三方库/用户项目代码的目录了

如果找到了，也就是由当前的类加载器负责处理

如果没有找到，任务还是要继续还给儿子来处理

but，此时没有儿子了，还没找到，最早就会抛出一个ClassNotFoundException

本质就是：拿到任务，先交给父亲处理，父亲处理不了，在自己处理

---

双亲委派模型的优点

1. 避免重复加载类：⽐如A类和B类都有⼀个⽗类C类，那么当A启动时就会将C类加载起来，那么在B类进⾏加载时就不需要在重复加载C类了。

2. 安全性：使⽤双亲委派模型也可以保证了Java的核⼼API不被篡改，如果没有使⽤双亲委派模型，⽽是每个类加载器加载⾃⼰的话就会出现⼀些问题，⽐如我们编写⼀个称为java.lang.Object类的话，那么程序运⾏的时候，系统就会出现多个不同的Object类，⽽有些Object类⼜是⽤⼾⾃⼰提供的因此安全性就不能得到保证了（JVM会确保加载的类是标准库的类）

---

 破坏双亲委派模型

but 双亲委派模型虽然有其优点，但在某些情况下也存在⼀定的问题，⽐如Java中SPI（Service Provider Interface，服务提供接⼝）机制中的JDBC实现：

因为DriverManager位于rt.jar包，由BootStrap类加载器加载，⽽其Driver接⼝的实现类是位于服务商提供的Jar包中，是由⼦类加载器（线程上下⽂加载器 Thread.currentThread().getContextClassLoader）来加载的，这样就破坏了双亲委派模型了（双亲委派模型讲的是所有类都应该交给⽗类来加载，但JDBC显然并不能这样实现）