JVM的类加载机制

圣诞叔

已于 2024-01-19 20:32:18 修改

阅读量847

点赞数 24

分类专栏： JVM 文章标签： jvm java 开发语言

于 2024-01-18 17:30:50 首次发布

本文链接：https://blog.csdn.net/zza062400/article/details/135644103

版权

JVM 专栏收录该内容

3 篇文章 0 订阅

订阅专栏

类加载运行全过程

首先我们看下这样一个test类

package com.sds;

/**
 * @author sds
 * @version 1.0
 * @date 2024-01-17
 **/
public class Test {
    public static final int init = 888;
    public static final DemoBean demoBean = new DemoBean();

    public static void main(String[] args) {
        Test test = new Test();
        test.compute();
    }

    public int compute() {
        int a = 1;
        int b = 2;
        return (a + b) * 10;
    }
}

当我们需要执行Test类中的main方法时，首先需要通过类加载器把主类加载到jvm的内存区域。

那么整个Test类的main方法从启动到结束的大体流程如下。

其中LoaderClass类加载过程分为以下几步

加载 >> 验证 >> 准备 >> 解析 >> 初始化 >> 使用 >> 卸载

加载：在硬盘上查找并通过IO读入字节码文件，使用到类时加载(懒加载)，如调用类的main()方法，new对象等，在加载阶段会生成一个代表这个类的java.lang.class唯一文件，作为方法区访问这个类各种数据(类的信息，如类的名称、父类、实现的接口、声明的字段和方法等)的入口
验证：验证这个类的class文件内容格式是否正确，是否符合jvm指令码的规范。
准备：给静态变量赋值一个java规定的默认值，比如int赋值为0，boolean赋值为null等
解析：符号引用转换为直接引用，等价于把符号引用转换为直接的jvm内存地址引用，比如test.compute()会直接指向compute()方法所在的内存地址。
初始化：对类的静态变量初始化为指定的值(比如初始化静态常量init的值为888)，执行静态代码块

类被加载到JVM内存区域的方法区后，主要包含 运行常量池，类型信息，字段信息，方法信息，类加载器的引用，对应class实例的引用等信息。

类加载器的引用：类到类加载器的实例引用

对应class实例的引用：类加载器加载类信息后放到方法区中后，会创创建一个对应的CLass类型的对象实例放到内存堆(heap)中,作为访问类定义的入口和切入点。

类加载器和双亲委派机制

类加载器分为以下几种

引导类加载器：负责加载支撑JVM运行的核心类库，位于JRE的lib目录下如rt.jar,charsets.jar等
扩展类加载器(ExtClassLoader)：负责加载支撑JVM运行的位于JRE的ext扩展目录下的jar类包
应用程序类加载器(AppClassLoader)：负责加载ClassPath路径下的类包，主要就是加载开发人员自己写的类
自定义类加载器：负责加载用户自定义路径下的类包，比如tomcat为了打破双亲委派机制自定义的类加载器

引导类加载器是由C++实现的，引导类加载器调用JVM启动器并实例化sun.misc.Launcher，launcher的构造函数创建 扩展类加载器(ExtClassLoader)，再创建应用程序类加载器(AppClassLoader) ，他们都继承了URLClassLoader。

扩展类加载器的父类加载器是引导类加载器

应用程序类加载器的父类加载器是扩展类加载器

自定义加载器的父类加载器是应用程序类加载器

类加载器初始化过程

参照类运行加载全过程图可以知道C++实现的引导类会创建JVM启动器实列sun.misc.Launcher。 sun.misc.Launcher初始化使用了单例模式，保证JVM虚拟机中只有一个sun.misc.Launcher实例

在Launcher构造方法内部会创建两个类加载器，分别是sun.misc.Launcher.ExtClassLoader(扩展类加载器)和sun.misc.Launcher.AppClassLoader(应用类加载器)。

JVM默认使用Launcher的 getClassLoader()方法返回的类加载器 AppClassLoader的实例加载我们

的应用程序。

//Launcher的构造方法
 public Launcher() {
 Launcher.ExtClassLoader var1;
 try {
 //构造扩展类加载器，在构造的过程中将其父加载器设置为null，因为其父类加载器是引导类加载器由C++实现所以为null
 var1 = Launcher.ExtClassLoader.getExtClassLoader();
 } catch (IOException var10) {
 throw new InternalError("Could not create extension class loader", var10);
 }

 try {
 //构造应用类加载器，在构造的过程中将其父加载器设置为ExtClassLoader，
 //Launcher的loader属性值是AppClassLoader，我们一般都是用这个类加载器来加载我们自
己写的应用程序
 this.loader = Launcher.AppClassLoader.getAppClassLoader(var1);
 } catch (IOException var9) {
 throw new InternalError("Could not create application class loader", var9);
 }

 Thread.currentThread().setContextClassLoader(this.loader);
 String var2 = System.getProperty("java.security.manager");
 。。。 。。。 //省略一些不需关注代码

 }

双亲委派机制

在应用程序类加载器中查看是否已经加载过这个Test类(如果已经加载了则直接返回)，如果没有则会委托应用程序类加载的父类加载器(扩展类加载器)的classLoader加载，
同样扩展类加载器会先在自己已经加载的类集合中查看是否已经加载Test类(如果已经加载了则直接返回)，如果没有则会调用扩展类加载器的父类加载器引导类加载器加载
同样引导类加载器会先查看自己已经加载的类集合中是否已经加载了Test类(如果已经加载了则直接返回)，如果没有加载则尝试去自己的类路径中去加载
如果引导类加载器没有加载成功则由子加载器(扩展类加载器)自己去加载
如果扩展类加载器没有加载成功则由子加载器(应用程序类加载器)自己去加载
如果应用程序类加载器如果还没由加载成功则会抛出异常

我们来看下应用程序类加载器AppClassLoader加载类的双亲委派机制源码，AppClassLoader

的loadClass方法最终会调用其父类ClassLoader的loadClass方法，该方法的大体逻辑如下：

1. 首先，检查一下指定名称的类是否已经加载过，如果加载过了，就不需要再加载，直接

返回。

2. 如果此类没有加载过，那么，再判断一下是否有父加载器；如果有父加载器，则由父加

载器加载（即调用parent.loadClass(name, false);）.或者是调用bootstrap类加载器来加

载。

3. 如果父加载器及bootstrap类加载器都没有找到指定的类，那么调用当前类加载器的

findClass方法来完成类加载

 //ClassLoader的loadClass方法，里面实现了双亲委派机制
 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();
                try {
                    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);//都会调用URLClassLoader的findClass方法在加载器的类路径里查找并加载该类

                    // 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;
        }
    }

为什么要设计双亲委派机制

看一个类加载示例：

package java.lang;

 public class String {
 public static void main(String[] args) {
 System.out.println("**************My String Class**************");
 }
 }

运行结果：
 错误: 在类 java.lang.String 中找不到 main 方法, 请将 main 方法定义为:
 public static void main(String[] args)
 否则 JavaFX 应用程序类必须扩展javafx.application.Application

1.这里的类路径和类名和java自己的String类一摸一样，那么通过双亲委派机制最总引导类加载器会将String类加载JVM内存中，但是JVM内存中的String.class是java自己的String.class 而不是自己定义的。所以就会报错。这样子的好处是什么呢？-沙箱安全机制

2.这里的String类在引导类加载器中已经被加载了，那么就不需要在子类加载器重复加载了。-避免类的重复加载

沙箱安全机制：自己写的java.lang.String.class类不会被加载，这样便可以防止核心

API库被随意篡改

避免类的重复加载：当父亲已经加载了该类时，就没有必要子ClassLoader再加载一

次，保证 被加载类的唯一性

全盘负责委托机制

一个类中可能会引用到其它的类，那么当这个类被加载所用到的类加载器，也会被当作其他引用类的类加载器来使用。除非显式的指定其它的引用类需要用其它的类加载器加载

自定义类加载器示例

自定义类加载器只需要继承 java.lang.ClassLoader 类，该类有两个核心方法，一个是

loadClass(String, boolean)，实现了 双亲委派机制 ，还有一个方法是findClass，默认实现是空

方法，所以我们自定义类加载器主要是重写 findClass 方法

package test;

import java.io.FileInputStream;
import java.lang.reflect.Method;

/**
 * @author sds
 * @version 1.0
 * @date 2024-01-17
 **/
public class MyClassLoaderTest {

    // 自定义类加载器只需要完成两步就行
    // 1.继承ClassLoader类
    // 2.重写findClass方法

    static class MyClassLoader extends ClassLoader {
        /**
         * 加载类的路径
         */
        private String classPath;

        // 创建有参构造
        public MyClassLoader(String classPath) {
            this.classPath = classPath;
        }

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

        /**
         * 读取需要加载的类的字节数据
         *
         * @param name 类名
         * @return 字节数组
         * @throws Exception
         */
        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;
        }
    }

    public static void main(String[] args) throws Exception{
        //初始化自定义类加载器，会先初始化父类ClassLoader，其中会把自定义类加载器的父加载器设置为应用程序类加载器AppClassLoader
        MyClassLoader myClassLoader = new MyClassLoader("D:/test");
        Class<?> clazz = myClassLoader.loadClass("com.sds.jvm.User1");
        Object obj = clazz.newInstance();
        Method method = clazz.getDeclaredMethod("sout", null);
        method.invoke(obj,null);
        System.out.println(clazz.getClassLoader().getClass().getName());
    }
}

package com.sds.jvm;

/**
 * @author sds
 * @version 1.0
 * @date 2024-01-17
 **/
public class User1 {
    private String name;

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

    public void sout(){
        System.out.println("=======自己的加载器加载类调用方法=======");
    }
}

运行结果：

46 ======= 自己的加载器加载类调用方法 =======

47 com . tuling . jvm . MyClassLoaderTest$MyClassLoader

打破双亲委派机制

需要打破双亲委派机制就需要重写自定义类加载器父类的loadClass()方法，

需要注意的是，只能对自己定义的类路径下的类实现打破双亲委派机制，其它的类还是需要走双亲委派机制。

package test;

import java.io.FileInputStream;
import java.lang.reflect.Method;

/**
 * @author sds
 * @version 1.0
 * @date 2024-01-17
 **/
public class MyClassLoaderTest {

    // 自定义类加载器只需要完成两步就行
    // 1.继承ClassLoader类
    // 2.重写findClass方法

    static class MyClassLoader extends ClassLoader {
        /**
         * 加载类的路径
         */
        private String classPath;

        // 创建有参构造
        public MyClassLoader(String classPath) {
            this.classPath = classPath;
        }

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

        /**
         * 读取需要加载的类的字节数据
         *
         * @param name 类名
         * @return 字节数组
         * @throws Exception
         */
        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;
        }

        @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) {
                    // If still not found, then invoke findClass in order
                    // to find the class.
                    long t1 = System.nanoTime();
                    // 非自定义的类必须要走双亲委派机制 ，因为存在沙箱安全机制
                    if (!name.startsWith("com.sds.jvm")) {
                        c = this.getParent().loadClass(name);
                    } else {
                        c = findClass(name);
                    }

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

        }
    }

    public static void main(String[] args) throws Exception {
        //初始化自定义类加载器，会先初始化父类ClassLoader，其中会把自定义类加载器的父加载器设置为应用程序类加载器AppClassLoader
        MyClassLoader myClassLoader = new MyClassLoader("D:/test");
        Class<?> clazz = myClassLoader.loadClass("com.sds.jvm.User1");
        Object obj = clazz.newInstance();
        Method method = clazz.getDeclaredMethod("sout", null);
        method.invoke(obj, null);
        System.out.println(clazz.getClassLoader().getClass().getName());
    }
}

Tomcat打破双亲委派机制

对于tomcat来说，它为什么要打破双亲委派机制呢？

我们从以下几个问题分析：

有时我们可能会在tomcat中部署多个应用，多个应用之间共用了相同的类库但是版本不一样。这个时候就不能使用默认的类加载机制了，无法加载两个相同类库的不同版本，只会根据全限定类名加载一份，需要自定义类加载器去加载应用程序自己的类库。
web容器也有自己的类库，不能和应用程序相混淆，应该与应用程序隔离开来。这个时候也不能使用默认的类加载机制了，需要web容器自己定义类加载器去加载自己的类库。
对于部署了多个应用程序，他们大多数的类库都是相同的版本号也一致。这种情况下应该使用双亲委派机制，可以使相同类库的相同版本共享
对于tomcat修改jsp时候的热加载。实现jsp文件的热加载，如果jsp修改了就直接卸载掉这个jsp类加载器，重新创建类加载器，重新加载jsp文件。(详细理解可以参考这篇文章tomcat9调优3：Tomcat类加载机制及其热部署热加载原理剖析_tomcat9 热加载-CSDN博客)