跳至主要內容

JVM类加载机制

清峰大约 6 分钟

JVM类加载机制

核心理论

1.1 类加载的生命周期

类从被加载到虚拟机内存中开始，到卸载出内存为止，其生命周期包括：加载（Loading）、验证（Verification）、准备（Preparation）、解析（Resolution）、初始化（Initialization）、使用（Using）和卸载（Unloading）七个阶段。其中验证、准备、解析三个阶段统称为连接（Linking）。

1.2 类加载的双亲委派模型

双亲委派模型是Java类加载器的核心机制，其工作过程是：当一个类加载器收到类加载请求时，首先将请求委派给父类加载器完成，只有当父类加载器无法加载该类时，子类加载器才会尝试自己加载。这种模型避免了类的重复加载，保证了Java核心库的安全性。

类加载器的层次结构：

  • 启动类加载器（Bootstrap ClassLoader）：加载JRE核心类库（如rt.jar），由C++实现
  • 扩展类加载器（Extension ClassLoader）：加载JRE扩展目录（ext目录）中的类
  • 应用程序类加载器（Application ClassLoader）：加载应用程序classpath下的类
  • 自定义类加载器（Custom ClassLoader）：用户自定义的类加载器

1.3 类初始化时机

JVM规定，只有在以下五种主动使用情况下才会触发类的初始化：

  1. 创建类的实例（new关键字、反射、克隆、反序列化）
  2. 调用类的静态方法
  3. 访问类的静态字段（被final修饰的常量除外）
  4. 初始化子类时，父类未初始化则先初始化父类
  5. 虚拟机启动时，指定的主类（包含main()方法的类）

代码实践

2.1 双亲委派模型演示

public class ClassLoaderDemo {
    public static void main(String[] args) {
        // 获取系统类加载器
        ClassLoader appClassLoader = ClassLoader.getSystemClassLoader();
        System.out.println("应用程序类加载器: " + appClassLoader);

        // 获取扩展类加载器
        ClassLoader extClassLoader = appClassLoader.getParent();
        System.out.println("扩展类加载器: " + extClassLoader);

        // 获取启动类加载器（null表示由C++实现，无法直接获取）
        ClassLoader bootstrapClassLoader = extClassLoader.getParent();
        System.out.println("启动类加载器: " + bootstrapClassLoader);

        // 查看当前类的类加载器
        ClassLoader currentClassLoader = ClassLoaderDemo.class.getClassLoader();
        System.out.println("当前类的类加载器: " + currentClassLoader);

        // 查看Java核心类的类加载器
        ClassLoader stringClassLoader = String.class.getClassLoader();
        System.out.println("String类的类加载器: " + stringClassLoader); // null，表示由启动类加载器加载
    }
}

2.2 自定义类加载器实现

public class CustomClassLoader extends ClassLoader {
    private String classPath;

    public CustomClassLoader(String classPath) {
        this.classPath = classPath;
    }

    // 重写findClass方法
    @Override
    protected Class<?> findClass(String name) throws ClassNotFoundException {
        try {
            byte[] classData = loadClassData(name);
            if (classData == null) {
                throw new ClassNotFoundException();
            }
            // 调用defineClass方法将字节数组转换为Class对象
            return defineClass(name, classData, 0, classData.length);
        } catch (IOException e) {
            throw new ClassNotFoundException(e.getMessage());
        }
    }

    private byte[] loadClassData(String className) throws IOException {
        // 将类名转换为文件路径
        String path = classPath + File.separatorChar +
                className.replace('.', File.separatorChar) + ".class";
        try (InputStream is = new FileInputStream(path);
             ByteArrayOutputStream baos = new ByteArrayOutputStream()) {
            byte[] buffer = new byte[1024];
            int bytesRead;
            while ((bytesRead = is.read(buffer)) != -1) {
                baos.write(buffer, 0, bytesRead);
            }
            return baos.toByteArray();
        }
    }

    public static void main(String[] args) throws Exception {
        // 创建自定义类加载器
        CustomClassLoader customClassLoader = new CustomClassLoader("/path/to/classes");
        // 加载自定义类
        Class<?> clazz = customClassLoader.loadClass("com.example.TestClass");
        // 反射调用方法
        Object obj = clazz.newInstance();
        Method method = clazz.getMethod("test");
        method.invoke(obj);
    }
}

2.3 打破双亲委派模型

public class BreakParentDelegateClassLoader extends ClassLoader {
    private String classPath;

    public BreakParentDelegateClassLoader(String classPath) {
        super(null); // 将父类加载器设置为null，打破双亲委派
        this.classPath = classPath;
    }

    @Override
    protected Class<?> findClass(String name) throws ClassNotFoundException {
        // 实现与自定义类加载器相同的加载逻辑
        try {
            byte[] classData = loadClassData(name);
            return defineClass(name, classData, 0, classData.length);
        } catch (IOException e) {
            throw new ClassNotFoundException(e.getMessage());
        }
    }

    private byte[] loadClassData(String className) throws IOException {
        // 实现与自定义类加载器相同的路径转换逻辑
        String path = classPath + File.separatorChar +
                className.replace('.', File.separatorChar) + ".class";
        try (InputStream is = new FileInputStream(path);
             ByteArrayOutputStream baos = new ByteArrayOutputStream()) {
            byte[] buffer = new byte[1024];
            int bytesRead;
            while ((bytesRead = is.read(buffer)) != -1) {
                baos.write(buffer, 0, bytesRead);
            }
            return baos.toByteArray();
        }
    }
}

设计思想

3.1 双亲委派模型的安全设计

双亲委派模型通过优先由父类加载器加载类，确保了Java核心类库的安全性。例如，用户无法自定义一个名为java.lang.String的类来替代核心类库中的String类，因为启动类加载器会优先加载核心类库中的String类。

3.2 类加载器的隔离性设计

不同的类加载器可以加载相同名称的类，但这些类在JVM中被视为不同的类。这种隔离性使得不同的应用模块可以使用不同版本的类，实现了模块间的隔离。例如，Tomcat通过自定义类加载器实现了Web应用之间的类隔离。

3.3 延迟加载与按需加载

类加载机制采用延迟加载策略，只有当类被主动使用时才会触发加载。这种按需加载的方式减少了内存占用，提高了JVM的启动速度。

避坑指南

4.1 类加载器泄漏

  • 原因：自定义类加载器未被正确回收，导致其加载的类也无法卸载
  • 常见场景：线程上下文类加载器、ThreadLocal中持有类加载器引用
  • 解决：使用完类加载器后及时清除引用，避免长期持有

4.2 双亲委派模型的局限性

  • 问题：父类加载器无法访问子类加载器加载的类
  • 解决：使用线程上下文类加载器（Thread Context ClassLoader），如JDBC加载驱动时打破双亲委派

4.3 类版本冲突

  • 原因：不同模块依赖同一类的不同版本
  • 解决：使用OSGi等模块化框架，或通过自定义类加载器实现类隔离

深度思考题

  1. 什么是线程上下文类加载器？它是如何打破双亲委派模型的？
  2. 类加载过程中，准备阶段和初始化阶段有什么区别？
  3. 如何实现一个热部署类加载器？

思考题回答：

  1. 线程上下文类加载器是Thread类中的一个ClassLoader类型的属性，通过setContextClassLoader()设置。它允许父类加载器请求子类加载器加载类，从而打破了双亲委派模型的单向委派关系。例如，JDBC驱动加载时，核心类库中的DriverManager（由启动类加载器加载）需要加载应用程序提供的驱动类（由应用程序类加载器加载），此时通过线程上下文类加载器实现。

  2. 准备阶段是为类的静态变量分配内存并设置初始值（通常是零值），而初始化阶段是根据程序中的赋值语句为静态变量赋值。例如，对于static int a = 1;，准备阶段a的值为0，初始化阶段a的值才被设置为1。

  3. 热部署类加载器的实现原理：1）自定义类加载器加载目标类；2）当需要更新类时，创建新的类加载器实例加载新版本的类；3）使用新的类实例替换旧的实例。关键是确保旧的类加载器和类实例可以被GC回收，避免内存泄漏。

默认页脚
Copyright © 2025 清峰