目录

1.类加载过程

1.1.加载（去车站）

1.2.验证（过安检）

1.3.准备（候车）

1.4.解析（检票）

1.5.初始化（上车）

2.双亲委派模型

2.1.什么是双亲委派模型？

2.2.双亲委派模型的优点

3.破坏双亲委派模型

---

1.类加载过程

在整个 JVM 执行的流程中，和程序员关系最密切的就是类加载的过程了。

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

其中前 5 步是固定的顺序并且也是类加载的过程，其中中间的 3 步都属于连接，所以对于类加载来说总共分为以下几个步骤：

• 加载
• 连接

1. 验证
2. 准备
3. 解析

• 初始化

1.1.加载（去车站）

“加载”（Loading）阶段是整个“类加载”（Class Loading）过程中的一个阶段，它和类加载 Class Loading 是不同的，一个是加载 Loading，另一个是类加载 Class Loading，所以不要把二者搞混了。

在加载 Loading 阶段，Java虚拟机需要完成以下三件事情：

1. 通过一个类的全限定名（完整的包名+类名）来获取定义此类的二进制字节流。
2. 将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构。
3. 在内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据的访问入口。

1.2.验证（过安检）

验证是连接阶段的第一步，这一阶段的目的是确保Class文件的字节流中包含的信息符合《Java虚拟机规范》的全部约束要求，保证这些信息被当作代码运行后不会危害虚拟机自身的安全。

验证选项：

• 文件格式验证
• 字节码验证
• 符号引用（相当于指针：内存地址）验证
• ...

1.3.准备（候车）

准备阶段是正式为类中定义的变量（即静态变量，被static修饰的变量）分配内存并设置类变量初始值的阶段。

比如此时有这样一行代码：

public static int value = 123;

它是初始化 value 的 int 值为 0，而非 123。

1.4.解析（检票）

解析阶段是 Java 虚拟机将常量池内的符号引用（相当于一个符号，这个符号还没有在内存中生效）替换为直接引用（内存中的对象）的过程，也就是初始化常量的过程。

1.5.初始化（上车）

初始化阶段，Java 虚拟机真正开始执行类中编写的 Java 程序代码，将主导权移交给应用程序。初始化阶段就是执行类构造器方法的过程。

2.双亲委派模型

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

站在 Java 虚拟机的角度来看，只存在两种不同的类加载器：

• 一种是启动类加载器（Bootstrap ClassLoader），这个类加载器使用 C++ 语言实现，是虚拟机自身的一部分；
• 另外一种就是其他所有的类加载器，这些类加载器都由Java语言实现，独立存在于虚拟机外部，并且全都继承自抽象类 java.lang.ClassLoader。

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

2.1.什么是双亲委派模型？

如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加载这个类，而是把这个请求委派给父类加载器去完成，每一个层次的类加载器都是如此，因此所有的加载请求最终都应该传送到最顶层的启动类加载器中，只有当父加载器反馈自己无法完成这个加载请求（它的搜索范围中没有找到所需的类）时，子加载器才会尝试自己去完成加载。

所有的API都是来自rt.jar包，

• 启动类加载器：加载 JDK 中 lib 目录中 Java 的核心类库，即 $JAVA_HOME/lib 目录。所有的 API 都是来自 rt.jar 包。
• 扩展类加载器：加载 lib/ext 目录下的类，都是扩展 jar 包。
• 应用程序类加载器：加载我们写的应用程序。
• 自定义类加载器：根据自己的需求定制类加载器。 

2.2.双亲委派模型的优点

1. 避免重复加载类：比如 A 类和 B 类都有一个父类 C 类，那么当 A 启动时就会将 C 类加载起来，那么在 B 类进行加载时就不需要再重复加载 C 类了。
2. 安全性：使用双亲委派模型也可以保证了 Java 的核心 API 不被篡改，如果没有使用双亲委派模型，而是每个类加载器加载自己的话就会出现一些问题，比如我们编写一个称为 java.lang.Object 类的话，那么程序运行的时候，系统就会出现多个不同的 Object 类，而有些 Object 类又是用户自己提供的，因此安全性就不能得到保证了。

3.破坏双亲委派模型

双亲委派模型虽然有其优点，但在某些情况下也存在一定的问题/缺点：比如①Java 中 SPI（Service Provider Interface，服务提供接口）机制中的 JDBC 实现；②Tomcat 容器加载。

小知识：SPI 全称 Service Provider Interface，是 Java 提供的一套用来被第三方实现或者扩展的接口，它可以用来启用框架扩展和替换组件。 SPI 的作用就是为这些被扩展的 API 寻找服务实现。

JDBC 的 Driver 接口定义在 JDK 中，其实现由各个数据库的服务商来提供，比如 MySQL 驱动包。先来看下 JDBC 的核心使用代码：

public class JdbcTest {public static void main(String[] args) {Connection connection = null;try {connection = DriverManager.getConnection("jdbc:mysql://127.0.0.1:3306/test", "root", "awakeyo");} catch (SQLException e) {e.printStackTrace();}System.out.println(connection.getClass().getClassLoader());System.out.println(Thread.currentThread().getContextClassLoader());System.out.println(Connection.class.getClassLoader());}
}

然后进入 DriverManager 的源码类就会发现它是存在系统的 rt.jar 中的：

由双亲委派模型的加载流程可知 rt.jar 是由顶级父类 Bootstrap ClassLoader 加载的：

而当进入它的 getConnection 源码是却发现，它在调用具体的类实现时，使用的是子类加载器（线程上下文加载器 Thread.currentThread().getContextClassLoader ）来加载具体的数据库数据库包 （如 mysql 的 jar 包），源码如下：

@CallerSensitive
public static Connection getConnection(String url, java.util.Properties info) throws SQLException {return (getConnection(url, info, Reflection.getCallerClass()));
}private static Connection getConnection (String url, java.util.Properties info, Class<?> caller) throws SQLException {ClassLoader callerCL = caller != null ? caller.getClassLoader() : null;synchronized(DriverManager.class) {// synchronize loading of the correct classloader.if (callerCL == null) {//获取线程上下为类加载器callerCL = Thread.currentThread().getContextClassLoader();}}if(url == null) {throw new SQLException("The url cannot be null", "08001");}println("DriverManager.getConnection(\"" + url + "\")");SQLException reason = null;for(DriverInfo aDriver : registeredDrivers) {// isDriverAllowed 对于 mysql 连接 jar 进行加载if(isDriverAllowed(aDriver.driver, callerCL)) {try {println("trying" + aDriver.driver.getClass().getName());Connection con = aDriver.driver.connect(url, info);if (con != null) {// Success!println("getConnection returning " + aDriver.driver.getClass().getName());return (con);}} catch (SQLException ex) {if (reason == null) {reason = ex;}}} else {println("   skipping: " + aDriver.getClass().getName());}}if (reason != null)   {println("getConnection failed: " + reason);throw reason;}println("getConnection: no suitable driver found for "+ url);throw new SQLException("No suitable driver found for "+ url, "08001");
}

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

它的交互流程图如下所示：