当前位置： 首页 > article >正文

彻底理解JVM类加载机制

article 2025/1/20 2:58:04

文章目录

  • 一、类加载器和双亲委派机制
    • 1.1、类加载器
    • 1.2、双亲委派机制
    • 1.3、自定义类加载器
    • 1.4、打破双亲委派机制
  • 二、类的加载

java代码的执行流程图片来源：图灵学院
  由上图可知，创建对象，执行其中的方法，在java层面，最重要的有获取类加载器以及加载类两部分

一、类加载器和双亲委派机制

1.1、类加载器

  在JVM中，类加载器分为：

  • 启动类加载器：最核心的类加载器，用于加载JRE的lib目录下的核心类库。
  • 扩展类加载器：负责加载位于JRE的lib目录下的ext扩展目录中的JAR类包。
  • 应用程序类加载器：负责加载ClassPath路径下的类包。
  • 自定义类加载器：用于加载用户自定义路径的类包。

  sun.misc包下的Launcher类，会在构造方法中对类加载器进行初始化：
在这里插入图片描述  构造方法中的关键部分：
在这里插入图片描述  sun.misc.Launcher.AppClassLoader#getAppClassLoader（获取应用程序类加载器方法）的最底层，将参数中传入的扩展类加载器，赋值给成员变量。
在这里插入图片描述  ExtClassLoader扩展类加载器继承自ClassLoader
在这里插入图片描述

1.2、双亲委派机制

  双亲委派机制的核心是，向上委派，向下加载：
在这里插入图片描述  即当加载某个类时，会从最底层的类加载器开始，逐个向上查找目标类，如果加载过，就直接返回。如果查找到最上层依旧没有，则从最上层自身负责的类加载路径中查找并加载。

  • 自己写的一个User类，第一次运行，应用程序类加载器没有找到，向上查找扩展类、启动类加载器，依然没有找到。就从最顶层的启动类加载器开始，查看该类是否在自己的加载范围内。很显然自定义的类，不在启动类加载器的范围内，向下委派到扩展类加载器，发现依旧不在自身的范围内，就再次委派给应用程序类加载器，这次发现在自己的加载范围内，就会加载。
  • java.lang包下的String类，第一次运行，应用程序类加载器没有找到，向上查找扩展类、启动类加载器，依然没有找到。就从最顶层的启动类加载器开始，查看该类是否在自己的加载范围内。java.lang包下的String类属于核心类库，启动类加载器发现它在自己应该加载的范围内，就会进行加载。

  双亲委派机制在源码中的体现在于java.lang.ClassLoader#loadClass(java.lang.String, boolean)：

protected Class<?> loadClass(String name, boolean resolve)
    throws ClassNotFoundException
{
    synchronized (getClassLoadingLock(name)) {
        //首先查看当前的类加载器是否加载过目标（底层是c/c++实现的方法）
        Class<?> c = findLoadedClass(name);
        //当前的类加载器没有加载过
        if (c == null) {
            long t0 = System.nanoTime();
            try {
            	  //扩展类加载器进行查找
            	  //这里的parent属性是当前类加载器的父加载器
                if (parent != null) {
                    c = parent.loadClass(name, false);
                }//启动类加载器进行查找 
                else {
                    c = findBootstrapClassOrNull(name);
                }
            } catch (ClassNotFoundException e) {
                // ClassNotFoundException thrown if class not found
                // from the non-null parent class loader
            }
            //都没有加载过
            if (c == null) {
                // If still not found, then invoke findClass in order
                // to find the class.
                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;
    }
}

  第一次加载某个自定义类时的流程：
  应用程序类加载器发现自身没有加载过，去执行扩展类加载器的loadClass方法：
在这里插入图片描述  扩展类加载器发现自身没有加载过，去找启动类加载器（底层由c/c++执行）在这里插入图片描述  启动类加载器返回的c为空，在扩展类加载器进入if判断，尝试自己加载，但是自定义的类不在自己的加载范围内，将null值的c返回到应用程序类加载器:
在这里插入图片描述  应用程序类加载器得到扩展类加载器的返回为空，就尝试自己加载并且返回：在这里插入图片描述

1.3、自定义类加载器

  自定义类加载器，需要继承ClassLoader，并且重写其中的findClass，loadClass方法：

public class MyClassLoaderTest1 {
    static class MyClassLoader extends ClassLoader {
        private String classPath;

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

        private byte[] loadByte(String name) throws Exception {
            name = name.replaceAll("\\.", "/");
            FileInputStream fis = new FileInputStream(classPath + "/" + name
                    + ".class");
            int len = fis.available();
            byte[] data = new byte[len];
            fis.read(data);
            fis.close();
            return data;
        }

        protected Class<?> findClass(String name) throws ClassNotFoundException {
            try {
                byte[] data = loadByte(name);
                //defineClass将一个字节数组转为Class对象，这个字节数组是class文件读取后最终的字节数组。
                return defineClass(name, data, 0, data.length);
            } catch (Exception e) {
                e.printStackTrace();
                throw new ClassNotFoundException();
            }
        }

    }

    public static void main(String args[]) throws Exception {
        //初始化自定义类加载器，会先初始化父类ClassLoader，其中会把自定义类加载器的父加载器设置为应用程序类加载器AppClassLoader
        MyClassLoader classLoader = new MyClassLoader("D:/test");
        //D盘创建 test/com/tuling/jvm 几级目录，将User类的复制类User1.class丢入该目录
        Class clazz = classLoader.loadClass("com.itbaima.jvm.User");
        Object obj = clazz.newInstance();
        Method method = clazz.getDeclaredMethod("sout", null);
        method.invoke(obj, null);
        System.out.println(clazz.getClassLoader().getClass().getName());
    }
}

  上面的自定义类加载器，目的是为了加载D盘test文件夹下的com.itbaima.jvm的User.class文件，假设目前的classpath下和D盘指定目录下都有该文件？
在这里插入图片描述
在这里插入图片描述  那么根据双亲委派机制，User类应该由应用程序类加载器，而非自定义类加载器加载。原因很简单，当User类被启动类加载器向下加载时，在应用程序类加载器这一层，发现属于自己的classpath范围内有这个类，就会进行加载。
在这里插入图片描述  把classpath下的User类删除，则由自定义类加载器进行加载：
在这里插入图片描述

1.4、打破双亲委派机制

  打破双亲委派机制的关键在于自定义实现loadClass方法。在1.3案例的基础上，继续重写loadClass方法：

@Override
protected Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException {
    synchronized (getClassLoadingLock(name)) {
        // First, check if the class has already been loaded
        Class<?> c = findLoadedClass(name);
        if (c == null) {
            long t0 = System.nanoTime();
            // If still not found, then invoke findClass in order
            // to find the class.
            long t1 = System.nanoTime();
            //让父类去加载Object
            if (!name.startsWith("com.itbaima.jvm")) {
                c = this.getParent().loadClass(name);
            }else {
                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;
    }

  在重写的loadClass方法中，去除了向上委派的逻辑，而是由自身进行加载，为什么还要加上

if (!name.startsWith("com.itbaima.jvm")) {
    c = this.getParent().loadClass(name);
 }

的判断？原因在于，用当前的类加载器去加载User类没有问题，但是User类继承了java.lang包下的Object类，如果把判断条件去除：
在这里插入图片描述  如果把Object.class文件复制一份到指定的目录呢？
在这里插入图片描述  答案也是否定的，因为在类加载的过程中JVM还有自己的安全监测机制，是不会允许核心的类被自定义加载的。在这里插入图片描述

二、类的加载

  类的加载，通过loadClass方法，会经历验证、准备、解析、初始化四个阶段：

  • 验证阶段：主要是校验class文件是否符合规范，以及对正确性进行校验，最经典的是cafe babe模数校验。
  • 准备阶段：给类的静态属性分配内存，并且赋初值(基本数据类型为默认值，引用类型为null)。
  • 解析阶段：将符号引用转变为直接引用，符号引用简单可以理解为类中的方法名，变量名等。而直接引用，是符号引用真正指向的内存地址。
  • 初始化：在这一步才是给类的静态属性赋值，并且执行静态代码块。

  静态代码块的执行先于构造方法：
在这里插入图片描述


http://www.kler.cn/a/510111.html

相关文章：

  • 万字长文介绍ARINC 653，以及在综合模块化航空电子设备（IMA）中的作用
  • vscode离线安装插件--终极解决方案
  • 快速入门：如何注册并使用GPT
  • vue3常用的组件的通信方式
  • 智能学习平台系统设计与实现(代码+数据库+LW)
  • 【JavaEE】Spring Web MVC
  • 企业可以通过以下方式利用全星QMS软件提高质量管理的效率和准确性
  • PCL 计算点云的最大距离【2025最新版】
  • 蓝桥杯训练—芯片测试
  • 安装httpd
  • CentOS 7.9下安装Docker
  • WEB渗透技术研究与安全防御
  • 乘联会：1月汽车零售预计175万辆 环比暴跌33.6%
  • 构建安全防线：基于视频AI的煤矿管理系统架构创新成果展示
  • MobileNet：轻量级卷积神经网络引领移动设备图像识别新时代
  • 广东打造低空经济发展平台，CES Asia 2025助力科技腾飞
  • 国内微电子（集成电路）领域重点高校的特色与优势
  • 【scrapy】信号量—扩展随笔
  • 利用@WebMvcTest测试Spring MVC应用
  • MySQL、HBase、ES的特点和区别
  • 初学stm32 --- flash模仿eeprom
  • AI-Talk开发板之替换唤醒词
  • K8S中Pod控制器之Deployment(Deploy)控制器
  • Prompt-人工智能领域的核心技术与创新理念
  • 设置 Git 默认推送不需要输入账号和密码【Ubuntu】
  • 使用libwebsocket技术总结