Java类加载生命周期各阶段按顺序开始但交叉混合执行，加载、验证、准备、初始化和卸载顺序确定，解析可延迟至初始化后以支持动态绑定，各阶段启动受字节码执行需求驱动。
Java 类加载机制中，生命周期各阶段并非严格串行执行，而是以“按顺序开始、交叉混合进行”为基本特征。这种设计兼顾了启动效率与运行时灵活性，尤其服务于动态绑定、懒加载等关键能力。
加载与连接阶段的交叉执行
加载阶段（Loading）主要负责获取字节码并生成 Class 对象，但 JVM 并不要求它完全结束才进入验证或准备。例如：
- 当类加载器读取到部分字节码后，验证器可能已开始校验前几段结构（如魔数、主次版本号），无需等待整个 class 文件读完；
- 在准备阶段分配静态变量内存的同时，JVM 可能已启动解析阶段对某些常量池项做初步符号引用检查；
- ClassLoader 的
defineClass()方法返回前，往往已完成部分验证和准备，但不保证全部完成。
解析阶段的延迟与动态性
解析（Resolution）是唯一明确允许推迟到初始化之后的阶段，其交叉性最典型：
- 若某方法调用使用了未解析的符号引用（如接口方法、虚方法），JVM 会在真正执行该字节码指令前触发解析，而非在类加载初期统一处理；
- 多态调用（如
invokevirtual）通常延迟解析，直到首次实际调用时才确定具体目标方法——这正是运行时绑定的底层支撑； - 反射调用（
Method.invoke()）或invokedynamic指令也依赖此类“按需解析”，避免提前锁定实现类。
初始化与使用的边界模糊
初始化（Initialization）虽定义为“首个主动使用触发”，但其内部也可能与其他阶段交织：
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
立即学习“Java免费学习笔记（深入）”；
- 静态字段赋值语句中若引用其他类，会触发被引用类的加载→连接→初始化流程，形成嵌套交叉；
- 静态代码块内若发生异常，JVM 会标记该类为“初始化失败”，后续任何使用都会抛出
NoClassDefFoundError，此时“使用”阶段实际上介入了初始化的异常处理逻辑； - 某些 JIT 编译优化（如类层次分析 CHA）会在初始化过程中收集类型信息，影响后续即时编译决策，属于运行时阶段反向影响初始化语义。
卸载阶段的被动性与时机不确定性
卸载（Unloading）本身不主动触发任何前置阶段，但它的发生条件依赖于前面所有阶段的执行结果：
- 只有当某类的所有实例、Class 对象、类加载器都不可达时，GC 才可能回收其方法区（元空间）数据；
- 而 ClassLoader 的生命周期又受应用上下文（如 Web 容器中的 ContextClassLoader）约束，导致卸载常与类加载器的销毁交叉发生；
- HotSpot 中元空间内存不足时触发 GC，可能顺带卸载无用类，此时卸载成为 GC 过程的一部分，而非独立阶段。
这些交叉不是随意的，而是由 JVM 规范明确定义的“按顺序开始”约束下的协同行为：每个阶段必须在前一阶段**开始之后**才能启动，但不必等其**完成**。真正决定何时切换的，是字节码指令的实际执行需求与资源就绪状态。
