JVM系列(三) -类加载器及双亲委派模型介绍

在之前的文章中，介绍了类的加载过程中，我们有提到在加载阶段，通过一个类的全限定名来获取此类的二进制字节流操作，其实类加载器就是用来实现这个操作的。

在虚拟机中，任何一个类，都需要由加载它的类加载器和这个类本身一同确立其唯一性，每一个类加载器，都拥有一个独立的类名称空间，对于类也同样如此。

简单的说，在虚拟机中看两个类是否相同，只有在这两个类是由同一个类加载器加载的前提下才有意义，否则即使这两个类来源于同一个.class文件，被同一个虚拟机加载，但是它们的类加载器不同，这两个类必定不相等。

当年为了满足浏览器上 Java Applet 的需求，Java 的开发团队设计了类加载器，它独立于 Java 虚拟机外部，同时也允许用户按自身需要自行实现类加载器。通过类加载器，可以让同一个类可以实现访问隔离、OSGi、程序热部署等等场景。发展至今，类加载器已经是 Java 技术体系的一块重要基石。

一、类加载器介绍

如果要查找类加载器，通过Thread.currentThread().getContextClassLoader()方法可以获取。

简单示例如下：

public class ClassLoaderTest {

    public static void main(String[] args) {
        ClassLoader loader = Thread.currentThread().getContextClassLoader();
        System.out.println("current loader：" +  loader);
        System.out.println("parent loader：" +  loader.getParent());
        System.out.println("parent parent loader：" +  loader.getParent().getParent());
    }
}

输出结果如下：

current loader：sun.misc.Launcher$AppClassLoader@18b4aac2
parent loader：sun.misc.Launcher$ExtClassLoader@511d50c0
parent parent loader：null

从运行结果可以看到，当前的类加载器是AppClassLoader，它的上一级是ExtClassLoader，再上一级是null。

其实ExtClassLoader的上一级是有类加载器的，它叫Bootstrap ClassLoader，是一个启动类加载器，由 C++ 实现，不是 ClassLoader 子类，因此以 null 作为结果返回。

这几种类加载器的层次关系，可以用如下图来描述。

它们之间的启动流程，可以通过以下内容来简单描述：

• 1.在虚拟机启动后，会优先初始化Bootstrap Classloader
• 2.接着Bootstrap Classloader负责加载ExtClassLoader，并且将 ExtClassLoader的父加载器设置为Bootstrap Classloader
• 3Bootstrap Classloader加载完ExtClassLoader后，就会加载AppClassLoader，并且将AppClassLoader的父加载器指定为 ExtClassLoader

因此，在加载 Java 应用程序中的class文件时，这里的父类加载器并不是通过继承关系来实现的，而是互相配合进行加载。

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

• 启动类加载器：它由 C++ 实现（这里仅限于 Hotspot，不同的虚拟机可能实现不太一样），是虚拟机自身的一部分
• 其它类加载器：这些类加载器都由 Java 实现，独立于虚拟机之外，并且全部继承自抽象类java.lang.ClassLoader，比如ExtClassLoader、AppClassLoader等，这些类加载器需要由启动类加载器加载到内存中之后才能去加载其他的类

站在开发者的角度，类加载器大致可以划分为三类：

• 启动类加载器：比如Bootstrap ClassLoader，负责加载<JAVA_HOME>\lib目录，或者被-Xbootclasspath参数制定的路径，例如jre/lib/rt.jar里所有的class文件。同时，启动类加载器是无法被 Java 程序直接引用的
• 拓展类加载器：比如Extension ClassLoader，负责加载 Java 平台中扩展功能的一些 jar 包，包括<JAVA_HOME>\lib\ext目录中或java.ext.dirs指定目录下的 jar 包。同时，开发者可以直接使用扩展类加载器
• 应用程序类加载器：比如Application ClassLoader，负责加载ClassPath路径下所有 jar 包，如果应用程序中没有自定义过自己的类加载器，一般情况下它就是程序中默认的类加载器

当然，如果有必要，也可以自定义类加载器，因为 JVM 自带的 ClassLoader 只懂得从本地文件系统中加载标准的class文件，如果要从特定的场所取得class文件，例如数据库中和网络中，此时可以自己编写对应的 ClassLoader 类加载器。

二、双亲委派模型

在上文中我们提到，在虚拟机中，任何一个类由加载它的类加载器和这个类一同来确立其唯一性。

也就是说，JVM 对类的唯一标识，可以简单的理解为由ClassLoader id + PackageName + ClassName组成，因此在一个运行程序中有可能存在两个包名和类名完全一致的类，但是如果这两个类不是由一个 ClassLoader 加载，会被视为两个不同的类，此时就无法将一个类的实例强转为另外一个类，这就是类加载器的隔离性。

为了解决类加载器的隔离问题，JVM 引入了双亲委派模型。

双亲委派模式，可以用一句话来说表达：任何一个类加载器在接到一个类的加载请求时，都会先让其父类进行加载，只有父类无法加载（或者没有父类）的情况下，才尝试自己加载。

大致流程图如下：

使用双亲委派模式，可以保证，每一个类只会有一个类加载器。例如 Java 最基础的 Object 类，它存放在 rt.jar 之中，这是 Bootstrap 的职责范围，当向上委派到 Bootstrap 时就会被加载。

但如果没有使用双亲委派模式，可以任由自定义加载器进行加载的话，Java 这些核心类的 API 就会被随意篡改，无法做到一致性加载效果。

JDK 中ClassLoader.loadClass()类加载器中的加载类的方法，部分核心源码如下：

public Class<?> loadClass(String name) throws ClassNotFoundException {
    return loadClass(name, false);
}

protected Class<?> loadClass(String name, boolean resolve)
        throws ClassNotFoundException
{
    // 1.首先要保证线程安全
    synchronized (getClassLoadingLock(name)) {
        // 2.先判断这个类是否被加载过，如果加载过，直接跳过
        Class<?> c = findLoadedClass(name);
        if (c == null) {
            long t0 = System.nanoTime();
            try {
                // 3.有父类，优先交给父类尝试加载；如果为空，使用BootstrapClassLoader类加载器
                if (parent != null) {
                    c = parent.loadClass(name, false);
                } else {
                    c = findBootstrapClassOrNull(name);
                }
            } catch (ClassNotFoundException e) {
                // 父类加载失败，这里捕获异常，但不需要做任何处理
            }

            // 4.没有父类，或者父类无法加载，尝试自己加载
            if (c == null) {
                long t1 = System.nanoTime();
                c = findClass(name);

                // this is the defining class loader; record the stats
                sun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);
                sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);
                sun.misc.PerfCounter.getFindClasses().increment();
            }
        }
        if (resolve) {
            resolveClass(c);
        }
        return c;
    }
}

三、自定义类加载器

在上文中我们提及过，针对某些特定场景，比如通过网络来传输 Java 类的字节码文件，为保证安全性，这些字节码经过了加密处理，这时系统提供的类加载器就无法对其进行加载，此时我们可以自定义一个类加载器来完成文件的加载。

自定义类加载器也需要继承ClassLoader类，简单示例如下：

public class CustomClassLoader extends ClassLoader {

    private String classPath;

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

    @Override
    protected Class<?> findClass(String name) throws ClassNotFoundException {
        Class<?> c = findLoadedClass(name);
        if (c == null) {
            byte[] data = loadClassData(name);
            if (data == null) {
                throw new ClassNotFoundException();
            }
            return defineClass(name, data, 0, data.length);
        }
        return null;
    }

    protected byte[] loadClassData(String name) {
        try {
            // package -> file folder
            name = name.replace(".", "//");
            FileInputStream fis = new FileInputStream(new File(classPath + "//" + name + ".class"));
            ByteArrayOutputStream baos = new ByteArrayOutputStream();
            int len = -1;
            byte[] b = new byte[2048];
            while ((len = fis.read(b)) != -1) {
                baos.write(b, 0, len);
            }
            fis.close();
            return baos.toByteArray();
        } catch (IOException e) {
            e.printStackTrace();
        }
        return null;
    }
}

相关的测试类如下：

package com.example;

public class ClassLoaderTest {

    public static void main(String[] args) {
        ClassLoader loader = Thread.currentThread().getContextClassLoader();
        System.out.println("current loader：" +  loader);
    }
}

将ClassLoaderTest.java源文件放在指定目录下，并通过javac命令编译成ClassLoaderTest.class，最后进行测试。

public class CustomClassLoaderTest {

    public static void main(String[] args) throws Exception {
        String classPath = "/Downloads";
        CustomClassLoader customClassLoader = new CustomClassLoader(classPath);
        Class<?> testClass = customClassLoader.loadClass("com.example.ClassLoaderTest");
        Object obj = testClass.newInstance();
        System.out.println(obj.getClass().getClassLoader());
    }
}

输出结果：

com.example.CustomClassLoader@60e53b93

在实际使用过程中，最好不要重写loadClass方法，避免破坏双亲委派模型。

四、加载类的几种方式

在类加载器中，有三种方式可以实现类的加载。

• 1.通过命令行启动应用时由 JVM 初始化加载，在上文已提及过
• 2.通过Class.forName()方法动态加载
• 3.通过ClassLoader.loadClass()方法动态加载

其中Class.forName()和ClassLoader.loadClass()加载方法，稍有区别：

• Class.forName()：表示将类的.class文件加载到 JVM 中之后，还会对类进行解释，执行类中的static方法块；
• Class.forName(name, initialize, loader)：支持通过参数来控制是否执行类中的static方法块；
• ClassLoader.loadClass()：它只将类的.class文件加载到 JVM，但是不执行类中的static方法块，只有在newInstance()才会去执行static方法块；

我们可以看一个简单的例子！

public class ClassTest {

    static {
        System.out.println("初始化静态代码块！");
    }
}

public class CustomClassLoaderTest {

    public static void main(String[] args) throws Exception {
        // 获取当前系统类加载器
        ClassLoader classLoader = Thread.currentThread().getContextClassLoader();

        // 1.使用Class.forName()来加载类，默认会执行初始化静态代码块
        Class.forName(ClassTest.class.getName());

        // 2.使用Class.forName()来加载类，指定false，不会执行初始化静态代码块
//        Class.forName(ClassTest.class.getName(), false, classLoader);

        // 3.使用ClassLoader.loadClass()来加载类，不会执行初始化静态代码块
//        classLoader.loadClass(ClassTest.class.getName());
    }
}

运行结果如下：

初始化静态代码块！

切换不同的加载方式，会有不同的输出结果！

五、小结

从以上的介绍中，针对类加载器的机制，我们可以总结出以下几点：

• 全盘负责：当一个类加载器负责加载某个Class文件时，该Class所依赖的和引用的其他Class也将由该类加载器负责载入，除非显示使用另外一个类加载器来加载
• 双亲委派：在接受类加载请求时，会让父类加载器试图加载该类，只有在父类加载器无法加载该类或者没有父类时，才尝试从自己的类路径中加载该类
• 按需加载：用户创建的类，通常加载是按需进行的，只有使用了才会被类加载器加载
• 缓存机制：有被加载过的Class文件都会被缓存，当要使用某个Class时，会先去缓存查找，如果缓存中没有才会读取Class文件进行加载。这就是为什么修改了Class文件后，必须重启 JVM，程序的修改才会生效的原因

写到最后

不会有人刷到这里还想白嫖吧？点赞对我真的非常重要！在线求赞。加个关注我会非常感激！