【JVM原理】类加载机制

今天药忘吃喽~ 2022-05-18 06:11 219阅读 0赞

# 前言 #

Github：[https://github.com/yihonglei/jdk-source-code-reading][https_github.com_yihonglei_jdk-source-code-reading]（java-jvm）

[JVM内存结构][JVM]

[JVM类加载机制][JVM 1]

[JVM内存溢出分析][JVM 2]

[HotSpot对象创建、内存、访问][HotSpot]

[JVM垃圾回收机制(1)--如何判定对象可以回收][JVM_1_--]

[JVM垃圾回收机制(2)--垃圾收集算法][JVM_2_--]

[JVM垃圾回收机制(3)--垃圾收集器][JVM_3_--]

[JVM垃圾回收机制(4)--内存分配和回收策略][JVM_4_--]

# 一 类加载的时机 #

类从被加载到虚拟机内存中开始，到卸载(GC)出内存为止，它的整个生命周期包括：

加载(Loading)、验证(Verification)、准备(Preparation)、解析(Resolution)、初始化(Initialization)、

使用(Using)和卸载(Unloading)七个阶段，如图：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lobF9qeHk_size_16_color_FFFFFF_t_70][]

其中加载、验证、准备、初始化、卸载这 5 个阶段的顺序是确定的，类的加载过程必须按照

这种顺序按部就班的进行，然而解析阶段不一定：它在某些情况下可以在初始化阶段之后

再开始，主要是为了支持 Java 语言的运行时绑定。关于初始化阶段，虚拟机规范严格规定

以下5种情况需要立即对类进行"初始化"（在此之前，加载、验证、准备需要完成）：

1）遇到 new、getstatic、putstatic 和 invokestatic 这四条字节码指令时，如果类没有进行过

初始化，需要进行初始化。这 4 条指令最常见的 Java 代码场景：使用 new 关键字实例化对象、

读取或设置一个类的静态字段、以及调用一个类的静态方法。

2）使用 java.lang.reflect 包的方法对类进行反射调用的时候，如果没有进行过初始化，

需要先进行初始化。

3）当初始化一个类的时候，如果发现其父类还没有进行初始化化，需要先触发父类初始化。

4）当虚拟机启动时，用户需要指定一个要执行的主类（包含main()方法的那个类），

虚拟机会先初始化这个主类。

5）当使用 JDK1.7 动态语言支持，如果一个 java.lang.invoke.MethodHandle 实例最后的解析

结果REF\_getStatic、REF\_putStatic、REF\_invokeStatic 的方法句柄，并且这个方法句柄所

对应的类没有进行过初始化，则需要先触发其初始化。

# 二 类加载的过程 #

**JVM 类加载分为加载、验证、准备、解析和初始化 5 个阶段。**

## 1、加载 ##

"加载"是"类加载"的一个阶段，在加载阶段，虚拟机需要完成以下 3 件事情：

1）通过一个类的全限定名来获取定义此类的二进制字节流。

2）将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构。

3）在内存中生成一个代表这个类的 java.lang.Class 对象，作为方法区这个类的各种数据的

访问入口。虚拟机规范的这 3 点要求其实并不算具体，虚拟机可以根据自己的情况实现。

比如我们可以从以下几个方面获取二进制字节流文件：

1）从 ZIP 包中读取，这个是 JAR、EAR、WAR 包基础。

2）从网络中获取，比如典型的 Applet。

3）运行时动态生成，比如动态代理技术。

4）从其他文件生成，比如 JSP 文件等等。

加载阶段完成后，虚拟机外部的二进制字节流就按照虚拟机所需要的格式存储在方法区之中，

方法区中的数据存储格式由虚拟机实现自行定义，虚拟机规范规定此区域的具体数据结构。

然后在内存中实例化一个 java.lang.Class 类的对象，这个对象将作为程序访问方法区中的这些

类型数据的外部接口。

**总结：**

通过类的完全限定名，查找类的字节码文件，利用字节码文件创建 Class 对象。

## 2、验证 ##

验证是连接阶段的第一步，这一阶段的目的是为了确保 Class 文件的字节流中包含的信息

符合当前虚拟机的要求，并不会危害虚拟机自身的安全。**验证大概分为 4 个阶段：**

**文件格式验证、元数据验证、字节码验证、符号引用验证。**

### 1、文件格式验证 ###

第一阶段验证字节流是否符合 Class 文件格式的规范，并能被当前版本的虚拟机处理。

主要包括以下验证点：

1）是否以魔数 0xCAFEBABE 开头。

2）主、次版本号是否在当前虚拟机处理范围之内。

3）常量池的常量中是否有不被支持的常量类型。

4）指向常量的各种索引值中是否有指向不存在的常量或不符合类型的常量。

5）CONSTANT\_UTF8\_info 型的常量中是否有不符合 UTF8 编码的数据。

6）Class 文件中各个部分及文件本身是否有被删除的或附加的其他信息。

......

验证内容还有很多，这个阶段的验证时基于二进制字节流进行的，这个阶段验证通过，

字节流才会进入内存的方法区中进行存储，后面 3 个阶段的验证全部基于方法区中的

存储结构进行验证，不直接操作字节流。

### 2、元数据验证 ###

第二阶段是对字节码描述的信息进行语义的分析，以保证其描述的信息符合 Java 语义

规范的要求，主要包括以下验证点：

1）这个类是否有父类(除了 java.lang.Object 之外，所有的类都应当有父类，Object 为除

自身外的所有父类)。

2）这个类的父类是否继承了不允许被继承的类（被 final 修饰的类）。

3）如果这个类不是抽象类，是否实现了其父类或接口中要求实现的所有方法。

4）类中的字段、方法是否与父类产生矛盾。

......

这个阶段的目的主要是对元数据信息进行校验，保证不存在不符合 Java 语言规范的元数据信息。

### 3、字节码验证 ###

第三阶段比较复杂，主要目的是通过数据流和控制流分析，确定程序语义是合法的、

符合逻辑的。主要包括以下验证点：

这个阶段比较复杂，主要目的是通过数据流和控制流分析，确定程序语义是合法的、符合逻辑的。

1）保证任意时刻操作数栈的数据类型与指令代码序列都能配合工作。

2）保证跳转指令不会跳转到方法体以外的字节码指令上。

3）保证方法体中类型转换是有效的。

### 4、符号引用验证 ###

最后一个阶段的校验发生在虚拟机将符号引用转化为直接引用的时候，这个转化动作

将在连接的第三阶段，即解析阶段中发生。符号引用验证可以看做是对类自身以外的信息

进行匹配性校验，主要包括以下验证点：

1）符号引用中通过字符串描述的权限定名是否能找到对应的类。

2）在指定类中是否存在符合方法的字段描述符以及简单名称锁描述的方法和字段。

3）符号引用中的类、字段、方法的访问性是否可以被当前的类访问。

符号引用验证的目的是确保解析动作能正常执行。

对于虚拟机来说，验证很重要，但不是一定必要的阶段。如果锁运行的全部代码已经被

反复使用和验证过，那么在实施阶段接可以考虑使用 -Xvefify:none 来关闭大部分的类验证

措施，以缩短虚拟机类加载的时间。

**总结：**

确保 Class 文件符合当前虚拟机的要求，不会危害到虚拟机自身安全。

## 3、准备 ##

准备阶段是正式为类变量分配内存并设置类变量初始值的阶段，这些类变量所使用的内存

都将在方法区中进行分配。

首先，需要明确这个时候进行内存分配的仅包括类变量（被 static 修饰的变量），而不包括

实例变量，实例变量将会在对象实例化时随着对象一起分配在 Java 堆中。其次，这里所说的

初始值"通常情况"下是数据类型的零值，假设一个类变量的定义为：

public static int value = 123;

变量值在准备阶段过后的初始值为 0，而不是 123，因为这个时候尚未开始执行任何 Java 方法，

而把 value 赋值为 123 的 putstatic 指令是程序被编译后，存放于类构造器 <clinit> 方法之中，

所以把 value 赋值为 123 的动作将在初始化阶段才会执行。

但是有一种特殊情况就是常量定义:

public static final int value = 123;

在编译时 Javac 将会为 value 生成ConstanValue属性，在准备阶段虚拟机就会根据 ConstanValue

的设置将 value 赋值为 123。

**总结：**

进行内存分配，为 static 修饰的类变量分配内存，并设置初始值(0 或 null)。

不包含 final 修饰的静态变量，因为 final 变量在编译时分配。

## 4、解析 ##

解析阶段是指虚拟机将常量池中的符号引用替换为直接引用的过程。符号引用就是 class

文件中的：CONSTANT\_Class\_info，CONSTANT\_Field\_info，CONSTANT\_Method\_info

等类型的常量。**符号引用**与虚拟机实现的布局无关，引用的目标并不一定要已经加载到内存中。

各种虚拟机实现的内存布局可以各不相同，但是它们能接受的符号引用必须是一致的，

因为符号引用的字面量形式明确定义在 Java 虚拟机规范的 Class 文件格式中。

**直接引用**可以是指向目标的指针，相对偏移量或是一个能间接定位到目标的句柄。

如果有了直接引用，那引用的目标必定已经在内存中存在。

**总结：**

将常量池中的符号引用替换为直接引用的过程，直接引用为直接指向目标的指针或者

相对偏移量等。

## 5、初始化 ##

初始化阶段是类加载最后一个阶段，前面的类加载阶段之后，除了在加载阶段可以自定义

类加载器以外，其它操作都由 JVM 主导和控制。到了初始阶段，才开始真正执行类中定义

的 Java 程序代码（或者说字节码）。

初始化阶段是执行类构造器 <client> 方法的过程。<client> 方法是由编译器自动收集类中的

类变量的赋值操作和静态语句块中的语句合并而成的。虚拟机会保证 <client> 方法执行之前，

父类的 <client> 方法已经执行完毕。

注意： 如果一个类中没有对静态变量赋值也没有静态语句块，那么编译器可以不为这个类

生成 <client>() 方法。

**注意以下几种情况不会执行类初始化：**

1）通过子类引用父类的静态字段，只会触发父类的初始化，而不会触发子类的初始化。

2）定义对象数组，不会触发该类的初始化。

3）常量在编译期间会存入调用类的常量池中，本质上并没有直接引用定义常量的类，

不会触发定义常量所在的类。

4）通过类名获取 Class 对象，不会触发类的初始化。

5）通过 Class.forName 加载指定类时，如果指定参数 initialize 为 false 时，也不会触发

类初始化，其实这个参数是告诉虚拟机，否要对类进行初始化。

6）通过 ClassLoader 默认的 loadClass 方法，也不会触发初始化动作。

**总结：**

1）主要完成静态块执行以及静态变量的赋值，先初始化父类，再初始化当前类，只有对

类主动使用时才会初始化。

2）触发条件包括，创建类的实例时，访问类的静态方法或静态变量的时候，

使用 Class.forName 反射类的时候，或者某个子类初始化的时候。

# 三 类加载器 #

## 1、类和类加载器 ##

虚拟机设计团队把加载动作放到 JVM 外部实现，以便让应用程序决定如何获取所需的类。

类加载虽然只能用于实现类的加载动作，但它在 Java 程序中的作用却远远不限于类的加载阶段。

对于任意一个类，都需要由加载它的类加载器和这个类本身一同确立其在 JVM 中的唯一性，

每一个类加载器都拥有一个独立的类命名空间。也就是说，比较两个类是否"相等"，只有在这

两个类来源于同一个 Class 文件，被同一个虚拟机加载，只要加载它们的类加载不同，

哪这两个类必定不相等。相等是指 equals()、isInstance() 方法、instanceof 返回结果。

package com.jpeony.jvm.loadclass;
    
    import java.io.IOException;
    import java.io.InputStream;
    
    /**
     * 类加载器与instanceof关键字演示：
     *
     * obj为自定义累加器加载对象，而ClassLoaderTest为另外一个类加载器加载的，所以，通过instanceof比较返回结果为false。
     *
     * @author yihongeli
     */
    public class ClassLoaderTest {
        public static void main(String[] args) throws Exception {
            ClassLoader myLoader = new java.lang.ClassLoader() {
                @Override
                public Class<?> loadClass(String name) throws ClassNotFoundException {
                    try {
                        String fileName = name.substring(name.lastIndexOf(".") + 1) + ".class";
                        InputStream is = getClass().getResourceAsStream(fileName);
                        if (is == null) {
                            return super.loadClass(name);
                        }
    
                        byte[] b = new byte[is.available()];
                        is.read(b);
                        return defineClass(name, b, 0, b.length);
                    } catch (IOException e) {
                        throw new ClassNotFoundException(name);
                    }
                }
            };
    
            Object obj = myLoader.loadClass("com.jpeony.jvm.loadclass.ClassLoaderTest").newInstance();
            System.out.println(obj.getClass());
            System.out.println(obj instanceof ClassLoaderTest);
        }
    }

**运行结果：**

![20200722201056278.png][]

从结果可以看出，obj 为自定义累加器加载对象，而 ClassLoaderTest 为另外一个类加载器

加载的，但是，所以，通过 instanceof 比较返回结果为 false。

## 2、双亲委派模型 ##

类加载器双亲委派模型图：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lobF9qeHk_size_16_color_FFFFFF_t_70 1][]

**1）启动类加载器（Bootstrap ClassLoader）**

启动类加载器负责加载最后基础、最为重要的类。比如加载 JRE 的 lib 目录下 jar 包中的类。

**2）扩展类加载器（Extension ClassLoader）**

扩展类加载器的父类加载器是启动类加载器。负责加载相对次要、但又通用的类，

比如，放在 JRE 的 lib/ext 目录下的 jar 包中的类。这个类加载器由 sun.misc.Launcher

中的静态内部类 ExtClassLoader 负责实现。

**3）应用程序类加载器（Application ClassLoader）**

应用类加载器的父类加载器是扩展类加载器。负责加载应用程序路径下的类。

比如虚拟机参数 -cp/-classpath、系统变量 java.class.path 或环境变量 CLASSPATH

所指定的路径。这个类加载器由 sun.misc.Launcher 中的静态内部类 AppClassLoader 负责实现。

默认情况下，应用程序中包含的类便是由应用类加载器加载的。

**4）用户自定义类加载器（User ClassLoader）**

负责加载用户自定义路径下的 jar 包。

在我们的应用程序都是由前 3 个类加载器互相配合进行加载的，如果有必要，可以加入自定

义类加载器。类加载器之间的这种层次关系，称为类加载器的双亲委派模型（Parents

Deletation Model）。双亲委派模型要求除了顶层的类加载器外，其余的类加载器都应当

有自己的父类加载器。这些类加载器之间的父子关系不是通过继承（Inheritance）的关系来实现，

而都是通过组合（Composition）的关系来复用父加载器的代码。

**双亲委派模型的工作过程：**当一个类加载器收到类加载请求，它首先不会去尝试加载这个类，

而是把这个请求委派给父类加载器去完成，每个层的类加载器都是如此，因此最终加载任务

都会传递到顶层的启动类加载器，只有当父类加载器无法完成加载任务时，子加载器才会

尝试自己去执行加载请求。

## 3、双亲委派机制的优势 ##

**1）沙箱安全机制**

防止核心 API 被串改，JDK 核心类，都由引导类加载器或扩展类加载器加载，

比如自己写的 String.class 类，会被委托到顶层加载，顶层类加载器直接从 rt.jar 里面

就能够加载String，则我们自己写的 String.class 就不会被加载。

**2） 避免类的重复加载**

当父类已经加载了该类时，子类加载器就没有必要再加载一次。

比如加载位于 rt.jar 包中的类 java.lang.Object，不管是哪个加载器加载这个类，

最终都是委托给顶层的启动类加载器进行加载，这样就保证了使用不同的类加载器

最终得到的都是同样一个 Object 对象。

**双亲委派模型对于保证 java 程序的稳定运作非常重要，咱们看下源码是如何实现的，**

**这里是 jdk8 的源码：**

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 {
                    // 遵循双亲委派的模型，首先会通过递归从父加载器开始找，
                    // 直到父类加载器是Bootstrap ClassLoader为止。
                    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.
                    // 如果父类加载器无法加载的时候，调用本身的findClass进行类加载
                    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;
        }
    }

源码分析：

1、首先通过 Class c = findLoadedClass(name); 判断一个类是否已经被加载过。

2、如果没有被加载过执行 if (c == null) 中的程序，遵循双亲委派的模型，首先会通过

递归从父加载器开始找，直到父类加载器是 Bootstrap ClassLoader 为止。

3、最后根据 resolve 的值，判断这个 class 是否需要解析。

而上面的 findClass() 的实现如下，直接抛出一个异常，并且方法是 protected，很明显这是

留给我们开发者自己去实现的。

**总结：**

1）双亲委派模式加载器加载类的时候，先把请求委托给自己的父类加载器执行，

直到顶层的启动类加载器。父类加载器能够完成加载则成功返回，不能则子类加载器

才自己尝试加载。

2）优点就是沙箱机制即避免核心 api 被篡改，同时避免类的重复加载。

# 参考文献 #

**《深入理解Java虚拟机》 (第二版) 周志明 著；**

[https_github.com_yihonglei_jdk-source-code-reading]: https://github.com/yihonglei/jdk-source-code-reading
[JVM]: https://blog.csdn.net/yhl_jxy/article/details/80882595
[JVM 1]: https://blog.csdn.net/yhl_jxy/article/details/81295635
[JVM 2]: https://blog.csdn.net/yhl_jxy/article/details/80946511
[HotSpot]: https://blog.csdn.net/yhl_jxy/article/details/80893288
[JVM_1_--]: https://blog.csdn.net/yhl_jxy/article/details/80950336
[JVM_2_--]: https://blog.csdn.net/yhl_jxy/article/details/80953776
[JVM_3_--]: https://blog.csdn.net/yhl_jxy/article/details/80956479
[JVM_4_--]: https://blog.csdn.net/yhl_jxy/article/details/80968456
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lobF9qeHk_size_16_color_FFFFFF_t_70]: /images/20220518/4fe621a242c24296baf968ea1ceb4148.png
[20200722201056278.png]: /images/20220518/20d8601a94d442478a43c1292b832e03.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lobF9qeHk_size_16_color_FFFFFF_t_70 1]: /images/20220518/cf4ff562235b4f5fad132264e0f66329.png