类加载机制

核心概念

类加载机制是 JVM 将 Class 文件加载到内存，并对其进行校验、解析和初始化，最终形成可被 JVM 直接使用的 Java 类型的过程。

类的生命周期

加载 → 验证 → 准备 → 解析 → 初始化 → 使用 → 卸载
       ├─────────────────┤
              连接阶段

1. 加载（Loading）

• 通过类的全限定名获取二进制字节流

• 将字节流代表的静态存储结构转化为方法区的运行时数据结构

• 在堆中生成该类的 Class 对象，作为方法区数据的访问入口

字节流来源：

• 本地文件系统（.class 文件）

• JAR/WAR 包

• 网络（Applet）

• 动态代理（运行时生成）

• JSP 文件生成

2. 验证（Verification）

确保 Class 文件的字节流符合 JVM 规范，不会危害 JVM 安全。

• 文件格式验证：魔数 0xCAFEBABE、版本号、常量池

• 元数据验证：语义分析，如是否有父类、是否继承了 final 类

• 字节码验证：数据流和控制流分析，确保语义合法

• 符号引用验证：确保解析阶段能正确执行

3. 准备（Preparation）

为类的静态变量分配内存并设置零值。

public static int value = 123;
// 准备阶段：value = 0（零值）
// 初始化阶段：value = 123（赋值）

public static final int CONSTANT = 123;
// 准备阶段：CONSTANT = 123（编译期常量，直接赋值）

4. 解析（Resolution）

将常量池中的符号引用替换为直接引用。

• 符号引用：用一组符号描述引用的目标（如全限定类名）

• 直接引用：直接指向目标的指针、偏移量等

5. 初始化（Initialization）⭐

执行类构造器 <clinit>() 方法，真正执行类中定义的 Java 代码。

触发初始化的场景（有且仅有）

1. new、getstatic、putstatic、invokestatic 指令

2. 反射调用（Class.forName()）

3. 初始化子类时，父类未初始化

4. JVM 启动时的主类

5. MethodHandle 解析结果为相关方法

不会触发初始化的场景

// 1. 通过子类引用父类的静态字段 → 只初始化父类
class Parent {
    static int value = 10;
}
class Child extends Parent {}
System.out.println(Child.value); // 不会初始化 Child

// 2. 通过数组定义引用类 → 不会初始化该类
Parent[] arr = new Parent[10];

// 3. 引用常量 → 编译期已放入常量池，不会初始化定义类
System.out.println(Parent.CONSTANT);

类加载器

类加载器层次

┌─────────────────────────────────┐
│  Bootstrap ClassLoader          │ ← C++ 实现，加载 rt.jar
│  （启动类加载器）                │    JAVA_HOME/lib
├─────────────────────────────────┤
│  Extension ClassLoader          │ ← Java 实现
│  （扩展类加载器）                │    JAVA_HOME/lib/ext
│  JDK 9+: Platform ClassLoader  │
├─────────────────────────────────┤
│  Application ClassLoader        │ ← Java 实现
│  （应用程序类加载器）             │    classpath 下的类
├─────────────────────────────────┤
│  Custom ClassLoader             │ ← 用户自定义
│  （自定义类加载器）               │
└─────────────────────────────────┘

双亲委派模型（Parents Delegation Model）⭐⭐⭐⭐⭐

工作原理

                  加载请求
                     │
          ┌──────────▼──────────┐
          │ Custom ClassLoader   │─── 能加载？──▶ 加载
          └──────────┬──────────┘      ↑ NO
                     │ 委派给父加载器    │
          ┌──────────▼──────────┐      │
          │ App ClassLoader      │─── 能加载？──┘
          └──────────┬──────────┘
                     │
          ┌──────────▼──────────┐
          │ Ext ClassLoader      │─── 能加载？
          └──────────┬──────────┘      ↑ NO
                     │                 │
          ┌──────────▼──────────┐      │
          │ Bootstrap ClassLoader│─── 能加载？──┘
          └─────────────────────┘

1. 收到类加载请求时，先委派给父加载器

2. 父加载器无法加载时，子加载器才尝试加载

3. 从顶层 Bootstrap 开始往下尝试

源码实现

protected Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException {
    synchronized (getClassLoadingLock(name)) {
        // 1. 检查是否已加载
        Class<?> c = findLoadedClass(name);
        if (c == null) {
            try {
                // 2. 委派给父加载器
                if (parent != null) {
                    c = parent.loadClass(name, false);
                } else {
                    c = findBootstrapClassOrNull(name);
                }
            } catch (ClassNotFoundException e) {
                // 父加载器无法加载
            }
            if (c == null) {
                // 3. 自己加载
                c = findClass(name);
            }
        }
        return c;
    }
}

双亲委派的意义

1. 避免类的重复加载：父加载器加载过的类不会再加载

2. 保证核心类安全：即使自定义了 java.lang.String，也会被 Bootstrap 加载器优先加载，保证使用的是 JDK 的核心类

打破双亲委派

1. SPI 机制（Service Provider Interface）

Bootstrap ClassLoader 加载了 JDBC 接口（rt.jar）
但实现类（mysql-connector.jar）在 classpath 下
需要 App ClassLoader 加载

解决方案：线程上下文类加载器（Thread Context ClassLoader）

// ServiceLoader 使用线程上下文类加载器加载 SPI 实现
ServiceLoader<Driver> drivers = ServiceLoader.load(Driver.class);

2. Tomcat 类加载器

      Bootstrap
          │
      Extension
          │
      Application
          │
    ┌─────┴──────┐
  Common       Catalina
    │
 ┌──┴──┐
WebApp1 WebApp2    ← 每个 Web 应用独立的类加载器

• 每个 Web 应用使用独立的 WebAppClassLoader

• 先自己加载，再委派给父加载器（打破双亲委派）

• 实现不同 Web 应用的类隔离

3. OSGi 模块化

• 网状类加载结构

• 每个 Bundle 有自己的类加载器

• 可以精确控制类的可见性

4. 热部署

// 自定义类加载器实现热部署
public class HotSwapClassLoader extends ClassLoader {
    @Override
    public Class<?> findClass(String name) throws ClassNotFoundException {
        byte[] classData = loadClassData(name); // 重新读取 class 文件
        return defineClass(name, classData, 0, classData.length);
    }
}
// 每次热部署创建新的类加载器实例

面试要点

高频问题

1. 类加载的过程是什么？

   • 加载 → 验证 → 准备 → 解析 → 初始化

2. 什么是双亲委派模型？为什么需要？

   • 向上委派，向下加载

   • 保证类的唯一性和核心类安全

3. 如何打破双亲委派？

   • 重写 loadClass() 方法

   • 线程上下文类加载器（SPI）

   • Tomcat 的 WebAppClassLoader

4. 类的初始化时机？

   • new、getstatic、putstatic、invokestatic

   • 反射、子类初始化触发父类、主类、MethodHandle

5. 两个类相等的条件？

   • 同一个 Class 文件 + 同一个类加载器

   • 不同类加载器加载的同一个 Class 文件，产生的类不相等

常见陷阱

• Class.forName() 会触发初始化，ClassLoader.loadClass() 不会

• 准备阶段赋零值，初始化阶段才赋真正的值（static final 编译期常量除外）

• Bootstrap ClassLoader 在 Java 中返回 null，因为它由 C++ 实现

参考资料

• 《深入理解 Java 虚拟机》第 7 章 - 周志明

• JVM Specification: Loading, Linking, and Initializing