JVM学习笔记(8) 第三部分虚拟机执行子系统第7章虚拟机类加载机制

文章目录

[第7章虚拟机类加载机制](#第7章虚拟机类加载机制)
- [7.0 个人感悟](#7.0 个人感悟)
- [7.1 概述](#7.1 概述)
- [7.2 类加载的时机](#7.2 类加载的时机)
- - [7.2.1 类的生命周期](#7.2.1 类的生命周期)
  - [7.2.2 类初始化的时机（主动引用）](#7.2.2 类初始化的时机（主动引用）)
  - [7.2.3 被动引用示例](#7.2.3 被动引用示例)
- [7.3 类加载的过程](#7.3 类加载的过程)
- - [7.3.1 加载（Loading）](#7.3.1 加载（Loading）)
  - [7.3.2 验证（Verification）](#7.3.2 验证（Verification）)
  - [7.3.3 准备（Preparation）](#7.3.3 准备（Preparation）)
  - [7.3.4 解析（Resolution）](#7.3.4 解析（Resolution）)
  - [7.3.5 初始化（Initialization）](#7.3.5 初始化（Initialization）)
- [7.4 类加载器](#7.4 类加载器)
- - [7.4.1 类与类加载器](#7.4.1 类与类加载器)
  - [7.4.2 双亲委派模型](#7.4.2 双亲委派模型)
  - [7.4.3 破坏双亲委派模型](#7.4.3 破坏双亲委派模型)
- [7.5 Java模块化系统](#7.5 Java模块化系统)
- - [7.5.1 模块的兼容性](#7.5.1 模块的兼容性)
  - [7.5.2 模块化下的类加载器](#7.5.2 模块化下的类加载器)
  - - （1）类加载器结构的变化
    - （2）模块优先的委派逻辑
    - （3）模块路径与三类模块
    - [（4）JDK 8与JDK 9类加载器差异总结](#（4）JDK 8与JDK 9类加载器差异总结)

第7章虚拟机类加载机制

7.0 个人感悟

1. 类加载机制是Java动态性的灵魂。 以前背八股"重载和重写的区别"时提到编译期绑定和运行时绑定，深入了解了.class文件结构、类加载、连接、初始化的完整流程，才真正理解代码执行时如何确保动态性，找到正确的方法

2. 双亲委派模型很有意思。 这种"先向上委派，父加载器处理不了再由自己加载"的模式，既保证了核心类库的安全性，又给了开发者定制加载逻辑的空间

3. 模块化设计很有远见。 JDK 9引入模块化毫无疑问提高了学习成本，但了解它的设计初衷后才发现，这是Java从"大而全"走向"可定制"的关键一步，也是第1章提到的java要做大做强需要接受的挑战

7.1 概述

虚拟机类加载机制

Java程序中的.java文件经过编译后变成.class字节码文件，而虚拟机类加载机制就是指Java虚拟机把描述类的数据从Class文件加载到内存，并对数据进行校验、转换解析和初始化，最终形成可以被虚拟机直接使用的Java类型的过程。

特性

与C/C++等在编译时就需要进行连接的语言不同，Java语言中类型的加载、连接和初始化过程都是在程序运行期间完成的。这种策略虽然会让类加载时稍微增加一些性能开销，但却为Java应用提供了极高的扩展性和灵活性

7.2 类加载的时机

7.2.1 类的生命周期

一个类型从被加载到虚拟机内存中开始，到卸载出内存为止，它的整个生命周期包含七个阶段：

text 复制代码

加载（Loading）→ 验证（Verification）→ 准备（Preparation）→ 解析（Resolution）→ 初始化（Initialization）→ 使用（Using）→ 卸载（Unloading）

其中，验证、准备、解析三个阶段统称为连接（Linking）

阶段顺序的规律：

加载、验证、准备、初始化和卸载这五个阶段的开始顺序是确定的，必须按部就班地进行
解析阶段则不一定：它在某些情况下可以在初始化阶段之后再开始，这是为了支持Java语言的运行时绑定特性（也称为动态绑定或晚期绑定）
注意是"开始"顺序确定，而不是"进行"或"完成"顺序确定------这些阶段通常是互相交叉地混合进行的

7.2.2 类初始化的时机（主动引用）

对于"加载"阶段，《Java虚拟机规范》没有强制约束，交给虚拟机自由把握。但对于初始化阶，规范严格规定了有且只有六种情况必须立即对类进行初始化（而加载、验证、准备自然在此之前开始）：

触发场景	典型Java代码示例
遇到 new、getstatic、putstatic、invokestatic 四条字节码指令	使用 new 实例化对象、读取/设置静态字段（final 常量除外）、调用静态方法
使用反射对类进行调用	Class.forName("xxx")
初始化子类时父类未初始化	先触发父类初始化（接口不要求父接口初始化）
虚拟机启动时指定的主类	包含 main()方法的类
JDK 7+ 动态语言支持	MethodHandle 解析结果为静态方法句柄时
接口中定义了 default 方法且有实现类初始化	JDK 8+ 新增场景

以上六种场景称为主动引用 ，除此之外的引用方式都不会触发初始化，称为被动引用

7.2.3 被动引用示例

示例1：通过子类引用父类的静态字段

java 复制代码

public class Test1 {  
    class SuperClass {  
        static {  
            System.out.println("SuperClass init!");  
        }  
  
        public static int value = 123;  
    }  
  
    class SubClass extends SuperClass {  
        static {  
            System.out.println("SubClass init!");  
        }  
    }  
  
    public static void main(String[] args) {  
        // 只会输出：SuperClass init!  
        // SubClass 不会被初始化  
        System.out.println(SubClass.value);  
    }  
}

输出：

复制代码

SuperClass init!
123

示例2：通过数组定义来引用类

java 复制代码

public class Test2 {  
    class SuperClass {  
        static {  
            System.out.println("SuperClass init!");  
        }  
  
        public static int value = 123;  
    }  
  
    static void main() {  
        // 不会触发 SuperClass 的初始化  
        SuperClass[] arr = new SuperClass[10];  
    }  
}

输出：

复制代码

Process finished with exit code 0

示例3：引用编译期常量

java 复制代码

public class Test3 {  
    class ConstClass {  
        static {  
            System.out.println("ConstClass init!");  
        }  
  
        public static final String HELLO = "hello world";  
    }  
  
    public static void main(String[] args) {  
        System.out.println(ConstClass.HELLO);  
    }  
}

输出：

复制代码

hello world

7.3 类加载的过程

7.3.1 加载（Loading）

加载是类加载过程的第一个阶段，需要完成三件事：

通过一个类的全限定名获取定义此类的二进制字节流。来源非常灵活，可以来自本地文件、网络、数据库、运行时动态生成等。
将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构。
在内存中生成一个代表这个类的 java.lang.Class对象 ，作为方法区这个类的各种数据的访问入口。
数组类本身不通过类加载器创建，而是由Java虚拟机直接在内存中动态构造出来。

7.3.2 验证（Verification）

验证是连接阶段的第一步，目的是确保Class文件的字节流符合规范要求，不会危害虚拟机安全。主要分为四个子阶段：

（1）文件格式验证

验证二进制字节流能否正确解析并存储于方法区，检查点包括：

是否以魔数 0xCAFEBABE 开头
主、次版本号是否在虚拟机接受范围内
常量池中是否有不被支持的常量类型
指向常量的索引是否指向不存在的常量
Class文件中是否有被删除或附加的其他信息

（2）元数据验证

对字节码描述的信息进行语义分析，检查点包括：

这个类是否有父类（除 Object 外）
父类是否继承了不允许被继承的类（如 final 类）
非抽象类是否实现了接口要求的所有方法
类中的字段、方法是否与父类产生矛盾

（3）字节码验证

最复杂的验证阶段，通过数据流和控制流分析，确保程序语义合法：

保证操作数栈的数据类型与指令代码序列能配合工作
保证跳转指令不会跳转到方法体以外的字节码指令
保证方法体中的类型转换是有效的

（4）符号引用验证

发生在解析阶段，验证符号引用能否正确解析为直接引用：

符号引用描述的全限定名能否找到对应的类
指定类中是否存在符合描述的方法和字段
符号引用中的类、字段、方法的访问性是否可被当前类访问

7.3.3 准备（Preparation）

准备阶段是正式为类变量（static变量）分配内存并设置初始值的阶段。注意两点：

分配的内存都在方法区中
设置的是零值（如 int 为 0，boolean 为 false，引用为 null），真正的赋值在初始化阶段完成

java 复制代码

public static int value = 123;  // 准备阶段 value = 0，初始化阶段 value = 123
public static final int value = 123;  // 特殊情况：编译期常量，准备阶段直接赋值为 123

7.3.4 解析（Resolution）

解析阶段是将常量池内的符号引用替换为直接引用的过程。

符号引用：用一组字符串来描述所引用的目标，与虚拟机内存布局无关。
直接引用 ：直接指向目标的指针、相对偏移量或能间接定位到目标的句柄，与内存布局相关。
解析动作主要针对类或接口、字段、类方法、接口方法这四类符号引用进行。由于解析阶段可能发生在初始化之后，这为Java的运行时绑定提供了支持。

7.3.5 初始化（Initialization）

初始化阶段就是执行类构造器 () 方法的过程。

() 方法由编译器自动收集类中所有类变量的赋值动作和静态代码块中的语句合并产生，收集顺序与语句在源文件中出现的顺序一致。

关键特性：

虚拟机会保证子类的 () 执行前，父类的 () 已经执行完毕。
() 方法在多线程环境下会被正确加锁同步，保证同一个类只被初始化一次。
接口的 () 执行不需要先执行父接口的 ()，只有用到时才初始化。

7.4 类加载器

7.4.1 类与类加载器

类加载器负责实现"通过一个类的全限定名获取二进制字节流"这个动作。对于任意一个类，都必须由加载它的类加载器和这个类本身共同确立其在Java虚拟机中的唯一性。

比较两个类是否"相等"，只有在这两个类由同一个类加载器加载的前提下才有意义。否则，即使来自同一个Class文件、被同一个虚拟机加载，只要加载它们的类加载器不同，这两个类就必定不相等。

7.4.2 双亲委派模型

Java虚拟机存在三种系统提供的类加载器：

类加载器	负责范围
启动类加载器（Bootstrap ClassLoader）	<JAVA_HOME>/lib 核心类库，如 rt.jar，由C++实现，无法直接引用
扩展类加载器（Extension ClassLoader）	<JAVA_HOME>/lib/ext 目录或 java.ext.dirs 指定路径
应用程序类加载器（Application ClassLoader）	用户类路径 classpath 上的类，是默认的类加载器

双亲委派模型的工作流程 ：

一个类加载器收到类加载请求后，首先将请求委派给父类加载器，只有当父类加载器反馈无法完成时，才尝试自己加载。

双亲委派模型的优势：

保证Java核心类库的安全性和一致性------比如 java.lang.Object 无论被哪个类加载器请求，最终都由启动类加载器加载。
防止用户自定义的类覆盖核心API，如用户定义 java.lang.String 会因双亲委派机制而无法被加载。

7.4.3 破坏双亲委派模型

双亲委派模型并非强制约束，在以下几种场景下会被破坏：

JDK 1.2之前：为了兼容历史代码，重写 loadClass() 方法。
线程上下文类加载器：如JNDI、JDBC等SPI机制，基础类需要调用用户代码，通过线程上下文类加载器来"逆向"加载。
追求程序动态性：如OSGi的模块化热部署、代码热替换等场景。

7.5 Java模块化系统

JDK 9引入了Java模块化系统（Project Jigsaw），这是对Java技术的一次重要升级，旨在实现可配置的封装隔离机制，并对类加载器架构进行了相应调整。

7.5.1 模块的兼容性

为了使可配置的封装隔离机制能够兼容传统的类路径查找机制，JDK 9提出了与"类路径"（ClassPath）相对应的**"模块路径"（ModulePath）概念。

某个类库是作为传统的JAR包还是作为模块来使用，只取决于它存放在哪种路径上：放在类路径上就被当作传统JAR包（归属匿名模块），放在模块路径上则被当作模块来对待。
规则一：JAR包在类路径上（匿名模块）对外看起来整个JAR包所有内容都是exported（即可被外部访问），而在模块路径上（具名模块）只有主动exported的内容才可被外部访问。
规则二：JAR包在类路径上时可以访问所有模块路径上的包（即匿名模块的requires是隐式作用于所有模块），而模块路径上的包不能访问任何类路径上的包（即具名模块不能声明依赖匿名模块，这一点与OSGi不同）。
向后兼容设计：未加 module-info.java 的项目仍可运行，JVM将其视为匿名模块；classpath上的类能访问模块路径中导出的包（反向则不行），维持了老项目调用新模块的能力。

此外，Java模块化系统目前不支持在模块定义中加入版本号来管理和约束依赖，本身也不支持多版本号的概念和版本选择功能。如果同一个模块发行了多个不同的版本，只能由开发者在编译打包时人工选择好正确版本的模块来保证依赖的正确性。

7.5.2 模块化下的类加载器

JDK 9的模块化系统没有从根本上动摇双亲委派模型（该模型已有20多年历史），但为了保证模块化系统的顺利运行，对类加载器架构做了适当调整。

（1）类加载器结构的变化

JDK 9之前的类加载器结构为三层：Bootstrap → Extension → Application。JDK 9中调整为：

变化项	JDK 8及以前	JDK 9及以后
扩展类加载器	Extension ClassLoader（<JAVA_HOME>/lib/ext）	被平台类加载器（Platform ClassLoader）取代
启动类加载器	纯C++实现，无Java表示	保留了Java类作为访问入口（jdk.internal.loader.ClassLoaders$BootClassLoader）
职责划分	三层委派	三者分工更清晰，无继承关系，通过显式协作完成加载

平台类加载器（Platform ClassLoader）专门负责加载 java.sql、java.logging`等非核心平台模块，而启动类加载器则专注于 java.base 等基石模块。

JDK本身基于模块化构建，已经天然满足了可扩展性的要求，因此不再需要 <JAVA_HOME>/lib/ext 目录这种扩展机制，扩展类加载器被平台类加载器取代顺理成章。

（2）模块优先的委派逻辑

模块化系统对双亲委派模型的核心调整在于：类加载前先查模块，再定委派路径。传统双亲委派中，AppClassLoader收到请求后直接向上委托给父加载器；而在JDK 9中，AppClassLoader会先检查目标类是否属于某个已知模块（如 java.lang.String 属于 java.base 模块），若属于，则跳过常规父委派，直接交由负责该模块的加载器处理。

模块归属判断发生在委派动作之前，是新增的第一道筛选。模块路径（--module-path）中的类优先走模块加载流程，而类路径（-cp）中的类仍走传统委派路径。即便AppClassLoader的父加载器是PlatformClassLoader，它也不会盲目委托------模块信息比加载器层级更权威。

（3）模块路径与三类模块

--module-path 不是 classpath 的简单别名，而是模块系统的入口机制，支持三类模块源：

具名模块（Named Module） ：含有 module-info.class 的JAR或目录，可声明 requires（依赖其他模块）和 exports（导出包供其他模块访问）。
自动模块（Automatic Module） ：普通JAR被放入模块路径时，JVM根据文件名自动生成模块名（如 guava-32.1.3-jre.jar → guava.32.1.3.jre），自动导出所有包。
匿名模块（Unnamed Module） ：来自classpath的类被归入一个共享的无名模块，只能读取其他模块，不能被导出或依赖。
模块路径让JVM在启动时就能构建模块图（Module Graph） ，实现编译期与运行期的依赖可见性校验。

（4）JDK 8与JDK 9类加载器差异总结

对比维度	JDK 8及以前	JDK 9及以后
核心类加载器	Bootstrap → Extension → AppClassLoader	Bootstrap → Platform → AppClassLoader
扩展机制	lib/ext 目录扩展	模块化系统自带扩展能力
委派逻辑	纯粹的双亲委派	模块优先 + 双亲委派
依赖查找	基于类路径	基于模块图 + 模块路径
访问控制	依赖访问修饰符（public/private等）	增加 exports/opens 模块级控制
反射访问	通过 setAccessible(true) 即可突破	必须满足模块的 opens 或add-opens`声明

总结：

JDK 9模块化系统没有推翻双亲委派模型，而是在保留"委托优先"逻辑骨架的基础上，将"是否委派"和"委派给谁"的决策权从加载器层级关系转向了模块归属判断。这种设计既保证了向后兼容，又实现了更细粒度的封装隔离。

JVM学习笔记(8) 第三部分 虚拟机执行子系统 第7章 虚拟机类加载机制

文章目录

第7章 虚拟机类加载机制

7.0 个人感悟

7.1 概述

7.2 类加载的时机

7.2.1 类的生命周期

7.2.2 类初始化的时机（主动引用）

7.2.3 被动引用示例

7.3 类加载的过程

7.3.1 加载（Loading）

7.3.2 验证（Verification）

（1）文件格式验证

（2）元数据验证

（3）字节码验证

（4）符号引用验证

7.3.3 准备（Preparation）

7.3.4 解析（Resolution）

7.3.5 初始化（Initialization）

7.4 类加载器

7.4.1 类与类加载器

7.4.2 双亲委派模型

7.4.3 破坏双亲委派模型

7.5 Java模块化系统

7.5.1 模块的兼容性

7.5.2 模块化下的类加载器

（1）类加载器结构的变化

（2）模块优先的委派逻辑

（3）模块路径与三类模块

（4）JDK 8与JDK 9类加载器差异总结

JVM学习笔记(8) 第三部分虚拟机执行子系统第7章虚拟机类加载机制

第7章虚拟机类加载机制