深入理解JVM类加载与运行机制-优快云博客

本文链接：https://blog.youkuaiyun.com/weixin_38007377/article/details/117840355

本文详细阐述了JVM的类加载全过程，包括加载、验证、准备、解析和初始化五个步骤。介绍了类加载器的层次结构，如引导类加载器、扩展类加载器和应用程序类加载器，以及双亲委派机制的工作原理。此外，文章还讨论了自定义类加载器的实现和为何有时需要打破双亲委派机制，以Tomcat为例进行了说明。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

JVM之类加载运行全过程

public class ClassLoading{
   
    public static final int data = 666;
    public static User user = new User();
    public int handle() {
   
        int a = 1;
        int b = 2;
        int c = a + b;
        return c;
    }
    public static void main(String[] args) {
   
        Math math = new Math();
        math.compute();
    }
}

以上面的类为例，当我们用java命令运行类的main函数启动程序时，首先会启动jvm实例进行进行一系列的类加载的前期准备和类记载过程。过程如下图
在这里插入图片描述
其中loadClass的类加载过程有如下几步：
加载 >> 验证 >> 准备 >> 解析 >> 初始化 >> 使用 >> 卸载

1.加载：

通过一个类的全限定名获取定义此类的二进制字节流；
将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构；
在内存中生层一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据的访问入口。
加载.class文件的方式：
从本地系统中直接加载
通过网络获取，典型场景: Web Applet
从zip压缩包中读取，成为日后jar、war格式的基础
运行时计算生成，使用最多的是: 动态代理技术
由其他文件生成，典型场景：JSP应用
从专有数据库中提取. class文件，比较少见
从加密文件中获取，典型的房Class文件被反编译的保护措施
类被加载到方法区中后主要包含运行时常量池、类型信息、字段信息、方法信息、类加载器的引用、对应class实例的引用等信息。
类加载器的引用：这个类到类加载器实例的引用
对应class实例的引用：类加载器在加载类信息放到方法区中后，会创建一个对应的Class 类型的对象实例放到堆(Heap)中, 作为开发人员访问方法区中类定义的入口和切入点。
注意，主类在运行过程中如果使用到其它类，会逐步加载这些类。
jar包或war包里的类不是一次性全部加载的，是使用到时才加载。

2.验证

校验字节码文件的正确性

3.准备

给类的静态变量分配内存，并赋予默认值

4.解析

将符号引用替换为直接引用，该阶段会把一些静态方法(符号引用，比如main()方法)替换为指向数据所存内存的指针或句柄等(直接引用)，这是所谓的静态链接过程(类加载期间完成)，动态链接是在程序运行期间完成的将符号引用替换为直接引用

5.初始化

对类的静态变量初始化为指定的值，执行静态代码块，注意只有静态的。

类加载器

上面的类加载过程主要是通过类加载器来实现的，Java里有如下几种类加载器。
引导类加载器：
负责加载支撑JVM运行的位于JRE的lib目录下的核心类库，比如rt.jar、charsets.jar等。
扩展类加载器：
负责加载支撑JVM运行的位于JRE的lib目录下的ext扩展目录中的JAR类包
应用程序类加载器：负责加载ClassPath路径下的类包，主要就是加载你自己写的那些类。
自定义加载器：负责加载用户自定义路径下的类包

类加载器初始化过程：

参见上图中类运行加载全过程可知其中会创建JVM启动器实例sun.misc.Launcher。
在Launcher构造方法内部，其创建了两个类加载器，分别是sun.misc.Launcher.ExtClassLoader(扩展类加载器)和sun.misc.Launcher.AppClassLoader(应用类加载器)。
JVM默认使用Launcher的getClassLoader()方法返回的类加载器AppClassLoader的实例加载我们的应用程序。
可以自行去看Launcher的源码，这里附一段Launcher初始化源码：

//Launcher的构造方法
public Launcher() {
   
    Launcher.ExtClassLoader var1;
    try {
   
        //构造扩展类加载器，在构造的过程中将其父加载器设置为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");
    。。。。。。//省略一些不需关注代码
}

双亲委派机制

JVM类加载器是有亲子层级结构的，如下图
在这里插入图片描述
这里类加载其实就有一个双亲委派机制，加载某个类时会先委托父加载器寻找目标类，找不到再委托上层父加载器加载，如果所有父加载器在自己的加载类路径下都找不到目标类，则在自己的类加载路径中查找并载入目标类。
比如我们的ClassLoading类，最先会找应用程序类加载器加载，应用程序类加载器会先委托扩展类加载器加载，扩展类加载器再委托引导类加载器，顶层引导类加载器在自己的类加载路径里找了半天没找到ClassLoading类，则向下退回加载ClassL