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

已于 2024-10-22 15:16:25 修改
阅读量1.1k 收藏 17
点赞数 21
分类专栏： java 虚拟机 文章标签： jvm java 开发语言
于 2024-10-11 11:55:10 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/dxflqm_pz/article/details/142850326
版权

最近对 JVM 技术知识进行了重新整理，再次献上 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，程序的修改才会生效的原因

写到最后

最后。如果感觉文章内容不错，帮忙动动小指头点个赞，点赞对我真的非常重要！加个关注我会非常感激！

志哥聊技术
关注
专栏目录
JVM的类加载器，以及双亲委派模型都是什么？
流楚丶格念的博客
08-22 1405
反之，如果没有使用双亲委派模型，都由各个类加载器自行去加载的话，如果用户自己也编写了一个名为java.lang.Object的类，并放在程序的ClassPath中，那系统中就会出现多个不同的Object类，Java类型体系中最基础的行为也就无从保证，应用程序将会变得一片混乱。例如类java.lang.Object，它存放在rt.jar之中，无论哪一个类加载器要加载这个类，最终都是委派给处于模型最顶端的启动类加载器进行加载，因此Object类在程序的各种类加载器环境中都能够保证是同一个类。
自定义类加载器
08-07
简单的自定义类加载器问候世界hello word，基于磁盘的ClassLoader
类加载器和双亲委派
最新发布
流浪猫
10-10 866
双亲委派模式要求除了顶层的启动类加载器之外，其余的类加载器都应该有自己的父类加载器，但是在双亲委派模式中父子关系采取的并不是继承的关系，而是采用组合关系来复用父类加载器的相关代码。如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加载这个类，而是把这个请求委派给父类加载器去完成，每一个层次的类加载器都是如此，因此所有的加载请求最终都应该传送到顶层的启动类加载器中，只有当父加载器反馈自己无法完成这个加载请求（它的搜索范围中没有找到所需的类）时，子加载器才会尝试自己去加载。
自定义类的加载器
实践求真知
08-21 351
一 为什么要自定义类加载器？ 隔离加载类 在某些框架内进行中间件与应用的模块隔离，把类加载到不同的环境。比如：阿里内某容器框架通过自定义类加载器确保应用中依赖的 jar 包不会影响到中间件运行时使用的 jar 包。再比如：Tomcat 这类 Web 应用服务器，内部自定义了好几种类加载器，用于隔离同一个 Web 应用服务器上的不同应用程序。 修改类加载的方式 类的加载模型并非强制，除 Bootstrap 外，其他的加载并非一定要引入，或者根据实际情况在某个时间点进行按需进行动态加载。
[自定义类加载器]
波波
01-25 238
目录 [类中对类的主动使用触发的类加载] [不同命名空间类的可见性] public class TestClassLoader extends ClassLoader { @Override protected Class<?> findClass(String name) throws ClassNotFoundException { System.out.println("进入自定义加载器"); byte[] data = loa.
【JVM】类加载器与双亲委派模型
12-21
总之，JVM的类加载器体系和双亲委派模型是Java平台稳定性和安全性的基石，它们确保了类加载的正确性和一致性，防止了类的混乱和安全风险。了解和掌握这一机制对于理解和优化Java应用程序的运行至关重要。
jvm(一)-类加载过程、类加载器及双亲委派模型
weixin_43520586的博客
10-21 162
一、JVM结构 jvm主要由类加载器、运行时数据区、执行引擎组成 一个 java 文件被编译后由 jvm 加载到执行的过程： 二、类加载过程 加载 —> 连接（验证—>准备—>解析）—> 初始化 —> 使用 —> 卸载 1、加载 1.1、 通过一个类的全限定名来获取定义此类的二进制字节流（并没有指明要从 一个Class文件中获取，可以从其他渠道，譬如：本地磁盘、网络下载.class文件、war,jar下加载.class文件、从数据库中读取、将java源文件动态
简单认识 JVM —— 了解类加载机制和双亲委派模型
AlinaQ05的博客
06-13 764
JVM 是 Java Virtual Machine 的简称，Java 虚拟机。虚拟机是指通过软件模拟具有完整硬件功能、运行在一个完全隔离的环境中的完整计算机系统。JVM 是主流虚拟机，其他常见的虚拟机还有：VMwave, Virtual Box.JVM 是 Java 运行的基础，也是实现一次编译到处执行的关键。一个 java 文件从编译到执行需要经过以下四个阶段。JVM 结构图： 总结来看，JVM 主要通过四个部分来执行程序。分别是： 类加载器（ClassLoader）、运行时数据区（Runntime D
JVM启动类加载器与双亲委派模型详解
本文主要探讨的是Java虚拟机（JVM）中的类加载器与双亲委派模型。类加载器是JVM的关键组件，它的作用是在运行时动态地将.class文件加载到方法区，确保程序的类和资源能够被正确、安全地找到并加载。 首先，文章介绍...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值