JVM——如何打造一个类加载器？

引入

在Java应用程序的生命周期中，类加载器扮演着至关重要的角色。它是Java运行时环境的核心组件之一，负责在需要时动态加载类文件到JVM中。理解类加载器的工作原理以及如何自定义类加载器，不仅可以帮助我们更好地管理应用程序的类加载过程，还能提升系统的安全性和灵活性，满足特定场景下的业务需求。

类加载器家族详解

启动类加载器（Bootstrap ClassLoader）

启动类加载器是JVM自带的类加载器，由C++实现，没有对应的Java类。它的主要职责是加载Java的核心类库，如java.lang、java.util等。这些类库位于jre/lib目录下，例如rt.jar文件中就包含了Java运行时的核心类。启动类加载器是最顶层的类加载器，它为JVM的启动和基本运行提供了必要的类支持。
由于启动类加载器的特殊性，它无法直接在Java代码中被引用。它是类加载器层次结构的起始点，为整个类加载体系奠定了基础，确保了Java核心API的稳定性和可靠性。

扩展类加载器（Extension ClassLoader）

扩展类加载器负责加载位于jre/lib/ext目录下的JAR文件。这些JAR文件包含了一些扩展的Java类库，例如加密、字符集转换等工具类库。在不同的Java版本和操作系统平台上，ext目录下的内容可能会有所不同。
在Java 9及更高版本中，随着模块系统的引入，扩展类加载器逐渐被平台类加载器（Platform ClassLoader）所取代。这一变化使得Java的模块化管理更加精细和高效，但扩展类加载器在Java 8及更早版本中仍然是一个重要的类加载组件。

应用类加载器（Application ClassLoader）

应用类加载器是系统默认的类加载器，负责加载应用程序classpath路径下的类文件。它通常是从CLASSPATH环境变量或-cp命令行选项指定的路径中加载类。当我们使用IDE（如IntelliJ IDEA或Eclipse）开发Java程序时，IDE会自动配置CLASSPATH，将项目的编译输出目录（如bin或target）以及项目依赖的库文件路径包含在内。
开发者可以通过ClassLoader.getSystemClassLoader()方法获取应用类加载器的实例。应用类加载器使得Java应用程序能够灵活地加载和运行自定义类和第三方库，是日常开发中最常用的类加载器。

自定义类加载器

在一些复杂的业务场景中，预设的类加载器可能无法满足需求。这时，开发者可以创建自定义类加载器来实现特定的功能。例如，可能需要从网络远程加载类、对类文件进行加密解密处理，或者实现类的热部署等功能。
自定义类加载器通过继承ClassLoader类并重写findClass方法来实现。在实现过程中，需要遵循双亲委派模型的原则，即先将类加载请求委派给父类加载器，只有当父类加载器无法加载时，才尝试自己加载。同时，还需要妥善处理异常情况，如类文件未找到、文件读取错误等，以确保类加载过程的健壮性。

三、双亲委派模型

（一）核心流程

当一个类加载器需要加载一个类时，它会遵循以下步骤：

委派给父类加载器：类加载器首先将加载请求委派给父类加载器。例如，当应用类加载器尝试加载一个类时，它会先请求扩展类加载器进行加载；扩展类加载器又会将请求进一步委派给启动类加载器。
父类加载器处理：父类加载器会按照相同的委派机制，继续将请求向上委派，直到顶级的启动类加载器。启动类加载器会尝试加载该类，如果类的全限定名对应的是Java核心类库中的类，则加载成功并返回对应的Class对象。
加载类：如果父类加载器无法加载该类（例如，类不在核心类库或扩展目录中），则当前类加载器会尝试自己加载。它会在指定的路径下查找类文件，将其字节码加载到JVM中，并返回对应的Class实例。如果加载成功，则类可以被应用程序使用；如果加载失败，则会抛出ClassNotFoundException。
类加载隔离：不同的类加载器可以加载同一个类的不同版本，这些类在JVM中是相互隔离的。这意味着即使两个类具有相同的全限定名，如果它们是由不同的类加载器加载的，JVM会将它们视为不同的类。这种隔离机制可以避免类之间的冲突，特别是在需要使用不同版本的第三方库时非常有用。

应用场景

安全沙箱隔离：通过自定义类加载器实现安全沙箱的机制，对不可信的类进行隔离加载和限制权限，提高系统的安全性。例如，在Java Applet（现已废弃）时代，为了防止恶意代码访问本地资源，Applet类加载器会将从网络加载的类与本地类隔离，确保其运行在沙箱环境中。

动态扩展和插件化：自定义类加载器可以实现动态加载和卸载功能，使得系统能够动态扩展和插件化。例如，一些IDE工具允许用户安装插件，这些插件的类可以通过自定义类加载器动态加载，而不会影响主程序的运行。这样可以提升程序的灵活性和可扩展性，使应用程序能够适应不断变化的需求。

多版本隔离：在同一个程序中使用不同版本的库文件时，自定义类加载器可以加载不同版本的类，从而避免版本冲突。例如，一个大型项目可能依赖多个第三方库，而这些库可能又依赖不同版本的同一个底层库。通过使用不同的类加载器加载这些不同版本的底层库，可以确保各个上层库能够正常工作，不会因为类的版本不兼容而出现错误。

限制

双亲委派模型存在一些限制：

类的静态加载状态：一旦一个类被加载到JVM中，它在整个应用程序的生命周期内都会保持加载状态，即使类的定义已经发生了变化也是如此。这是因为Java内存管理机制的设计使得ClassLoader会持有已加载类的Class对象，并且只有当ClassLoader、Class对象以及其所有实例都不可达时，垃圾回收器才会回收这个类。这限制了我们动态加载新类的能力，例如在开发过程中无法直接重新加载修改后的类，必须重新启动应用程序才能看到更改后的效果。
类加载顺序的固定性：双亲委派模型规定了类加载的严格顺序，这在某些特殊场景下可能不够灵活。例如，当需要优先加载自定义的类而不是系统提供的类时，双亲委派模型默认的加载顺序可能会导致问题。

Tomcat为什么能够突破限制？

Tomcat通过自定义类加载器的方式突破了双亲委派模型的限制。它采用了层次化的类加载器结构，包括公共类加载器（common ClassLoader）、共享类加载器（shared ClassLoader）和Web应用类加载器（Webapp ClassLoader）。这些类加载器共同协作，实现了以下功能：

隔离不同的Web模块：每个Web应用都有自己的Webapp ClassLoader，这样不同Web模块的类可以相互隔离。这避免了不同应用之间的类相互干扰，提高了系统的稳定性和安全性。
共享公共类：公共类加载器负责加载所有Web应用都可以访问的公共类库，这些类库位于Tomcat/lib目录下。这样可以减少重复加载相同的类，提高资源利用率。
灵活的类加载顺序：Tomcat的类加载器在加载类时，会先尝试加载Web应用自己的类，然后再委托给父类加载器。这种加载顺序与双亲委派模型相反，使得Web应用可以使用自己的类来覆盖父类加载器中的同名类。这为动态部署和更新Web应用提供了便利，例如在开发过程中可以更方便地更新类文件而无需重启整个Tomcat服务器。

类加载器的演进

随着JVM的不断迭代更新，类加载器也经历了一系列的演进，以适应新的需求和提高性能。

JDK 9及更高版本中的变化

引入模块系统（JPMS）：从JDK 9开始，Java引入了模块系统（Java Platform Module System，JPMS），将Java核心库分割成了一系列相互关联的模块。每个模块明确指定了其公开的包和依赖的其他模块，这样可以实现更精细的访问控制和依赖管理。模块系统使得Java的代码结构更加清晰，也为类加载器带来了新的变化。
平台类加载器和系统类加载器的引入：原本的启动类加载器被拆分成了平台类加载器和系统类加载器。平台类加载器负责加载JDK模块，而系统类加载器则用于加载应用程序模块。这种拆分使得类加载器的职责更加明确，也为模块化的类加载提供了支持。

JDK 11及更高版本中的变化

类数据共享（CDS）技术：JDK 11中引入了类数据共享技术，允许多个Java进程共享同一个JVM类元数据区域。这可以减少每个Java进程的内存占用，提高启动性能，特别是在运行多个Java应用的环境中效果显著。通过共享类元数据，不同进程可以减少重复加载相同类的开销。

JDK 17及更高版本中的变化

移除系统类加载器：在JDK 17中，系统类加载器被移除，所有的类加载操作由应用类加载器接管。这一改动简化了JVM的架构，减少了潜在的安全风险。例如，避免了系统类加载器在加载模块时可能出现的映射关系混乱问题，同时也提高了模块化系统的安全性和运行时性能。

打造自定义类加载器的实践案例

下面是一个自定义类加载器的完整实例，展示了如何通过继承ClassLoader类并重写findClass方法来实现自定义的类加载逻辑：

import java.io.*;
import java.util.HashMap;

// 自定义ClassLoader类，继承自ClassLoader
public class CustomClassLoader extends ClassLoader {
    // 定义了类文件的根路径
    private String rootDir;
    // 缓存已经加载的类
    private HashMap<String, Class<?>> loadedClasses;

    /**
     * Constructor
     *
     * @param rootDir 类文件的根目录路径
     */
    public CustomClassLoader(String rootDir) {
        this.rootDir = rootDir;
        // 初始化缓存Hashmap
        loadedClasses = new HashMap<>();
    }

    /**
     * 加载类文件并返回Class实例
     *
     * @param className 类的全限定名
     * @return 加载的类的Class实例
     * @throws ClassNotFoundException 如果类未被找到或加载
     */
    @Override
    protected Class<?> findClass(String className) throws ClassNotFoundException {
        // 从已加载的类缓存中查找类
        Class<?> loadedClass = loadedClasses.get(className);
        // 如果类已经被加载，从缓存中返回
        if (loadedClass != null) {
            return loadedClass;
        }
        // 否则读取类文件的字节码
        byte[] classBytes = getClassBytes(className);
        if (classBytes == null) {
            throw new ClassNotFoundException();
        }
        // 在锁定的环境中，定义类并将类放入已加载的类缓存中
        synchronized (loadedClasses) {
            loadedClass = defineClass(className, classBytes, 0, classBytes.length);
            loadedClasses.put(className, loadedClass);
        }
        return loadedClass;
    }

    /**
     * 根据类名读取类文件的字节码
     *
     * @param className 类的全名（包括包名）
     * @return 类文件的字节码
     */
    private byte[] getClassBytes(String className) {
        // 将全名转换为文件名
        String classPath = rootDir + '/' + className.replace('.', '/') + ".class";
        FileInputStream fis = null;
        ByteArrayOutputStream baos = null;
        try {
            fis = new FileInputStream(classPath);
            baos = new ByteArrayOutputStream();
            byte[] buffer = new byte[1024];
            int bytesRead;
            // 循环读取文件直到文件结束
            while ((bytesRead = fis.read(buffer)) != -1) {
                baos.write(buffer, 0, bytesRead);
            }
            // 返回字节流的字节数组
            return baos.toByteArray();
        } catch (IOException e) {
            e.printStackTrace();
        } finally {
            // 关闭资源
            try {
                if (fis != null) {
                    fis.close();
                }
                if (b aos != null) {
                    baos.close();
                }
            } catch (IOException e2) {
                e2.printStackTrace();
            }
        }
        return null;
    }

    public static void main(String[] args) {
        // 创建新的CustomClassLoader实例
        CustomClassLoader customClassLoader = new CustomClassLoader("/path/to/classes");
        try {
            // 通过自定义的类加载器加载一个类，输出其类名
            Class<?> sampleClass = customClassLoader.loadClass("com.example.SampleClass");
            System.out.println("Class loaded successfully: " + sampleClass.getName());
        } catch (ClassNotFoundException e) {
            e.printStackTrace();
        }
    }
}

总结

通过深入理解类加载器家族的成员及其职责、双亲委派模型的原理和应用场景，以及类加载器在不同JDK版本中的演进，我们可以更加灵活地管理和优化Java应用程序的类加载过程。自定义类加载器为我们提供了强大的工具，以应对复杂的业务需求和特定的技术挑战。在实际开发中，合理利用类加载器的特性，可以帮助我们构建更加安全、高效和可扩展的Java应用。