- **JVM 为什么需要类加载机制？**
- **类加载机制解决了哪些不可回避的系统性问题？**
- **不同工程方案（双亲委派、Tomcat、OSGi）背后遵循的统一抽象是什么？**
如果 JVM 只是"执行字节码的机器"，那么最简单的设计是启动时一次性加载所有类，用一个全局 Class 表管理。JVM 没有这样做，是因为它必须解决以下三个根本问题。
Java 的核心设计选择之一是：
类型在运行期才被引入 JVM，而非编译期全部确定
这直接带来类可能来自本地文件、网络、生成器、容器等多种来源，且类的生命周期可能短于 JVM 进程。结论：类必须被"按需引入"，而不是静态固化。类加载机制本质上是：
JVM 的 动态类型构建系统
在真实系统中，不可避免存在不同模块使用同名类、不同版本的依赖同时存在、插件/Web应用/中间件并存的情况。如果所有类共享一个全局命名空间，类型冲突不可避免，模块隔离无法实现。结论：类的唯一性不能只由"类名"决定。
这直接导向 JVM 的核心抽象：
Class =（Binary Name, ClassLoader）
ClassLoader 本质上是：
类型命名空间的边界定义者
JVM 必须回答一个安全问题：
谁可以定义
java.lang.String？
如果任意代码都能定义核心类、覆盖基础类型，那么 JVM 将失去安全基础。结论：
必须存在一个不可被篡改的"信任根"
这正是后续"双亲委派模型"的根本动机。
上述三个第一性问题（动态类型系统、命名空间隔离、安全信任根）决定了类加载必须做什么；五阶段拆分回答的是以什么顺序、在什么保证下做——每个阶段在前一阶段建立的不变量之上施加更强约束，阶段边界即 JVM 获得时序自由度（如延迟解析）的前提。
五阶段是一条依赖链——每个阶段的正确运行以前一阶段建立的不变量为前提：
| 前置阶段 | 建立的不变量 | 使得后续阶段可以… |
|---|---|---|
| 加载 | 类型身份确定 (Name, Loader)；类层级图已构建 |
验证可遍历合法的继承树、检查描述符引用 |
| 验证 | 字节码结构正确；描述符合法；类层级无环 | 准备安全分配字段（字段描述符已确认）；解析只需处理存在性与访问权而非结构合法性 |
| 准备 | 静态字段以零值存在；继承链的 loader constraints 已施加 | 解析在已一致的约束基底上追加新约束；<clinit> 执行时所有字段槽已就绪 |
| 解析 | 符号引用→直接引用 | 执行引擎可直接寻址 |
核心推论：延迟解析之所以安全，是因为验证已证明结构正确（延迟只会遇到"不存在/不可访问"，不会遇到"格式非法"导致 VM 崩溃），准备已建立约束基底（新约束无论先后施加，产生的冲突集合相同）。这与 ELF 动态链接器的 PLT 延迟绑定同构——安全性前提是加载时已完成重定位表的结构校验。
验证、准备、解析共享三个特征，使规范将其归为一个概念单元：
归组允许实现自由选择时序策略（验证和准备必须先于初始化，但解析可浮动），而不暴露实现细节为规范约束。
加载——建立 Binary Name → Class 映射，确定命名空间归属。数组类由 JVM 直接生成而不经字节码寻找，表明加载关注的是"类型身份引入"而非文件 I/O。
验证——代价最高的阶段（在 HotSpot 中占类加载耗时的主体）。设计哲学是"安全优先于性能"：拒绝结构非法的代码进入运行期，这是 JVM 作为安全运行时的底线而非可选优化。代价：验证会递归触发被引用类型的加载（但不触发其验证），形成加载扇出。
准备——为类变量分配确定的零值/null，建立"任何用户代码执行前类型状态已确定"的基线。同时为继承关系中的方法签名施加 loader constraints（N_L1 = N_L2），保证虚分派的类型安全。
解析——将符号引用绑定为直接引用。符号引用存在的根本原因：支持跨命名空间、跨加载器的延迟绑定——编译期无法确定目标类型由哪个加载器定义。一旦解析（成功或失败），结果永久缓存，使延迟解析在时序上确定性等价于急切解析。
初始化——执行 <clinit>，即类型级构造函数。三重约束：父类先于子类、只执行一次、类级锁保证线程安全，共同维护类型状态的全局一致性。代价/妥协：规范允许循环初始化（A 的 <clinit> 触发 B，B 的 <clinit> 回引 A）——此时 B 将观察到 A 的半初始化状态，这是规范对"禁止循环 vs 允许灵活组合"的权衡选择。
加载和链接的启动时机由实现自由选择，但初始化不可以——
<clinit>是有副作用的用户代码，时机不确定则程序行为不确定。因此规范必须精确划定哪些操作触发整条管道跑到初始化。
规范以"有且仅有"限定哪些操作触发类初始化（new、getstatic/putstatic/invokestatic、反射、子类初始化触发父类、启动类、接口默认方法解析），判定标准是：
操作的正确执行是否依赖
<clinit>副作用已经发生
依赖则触发（主动引用），不依赖则不触发（被动引用）：
| 操作 | 是否触发 | 原因 |
|---|---|---|
| getstatic | 触发 | 未执行 <clinit> 则读到准备阶段零值而非程序赋值 |
| new | 触发 | 构造函数可能依赖已初始化的静态状态 |
| 子类初始化 | 触发父类 | 子类 <clinit> 可能引用继承的静态字段 |
| 编译期常量引用 | 不触发 | 值已内联至调用方常量池，运行时不访问声明类状态 |
数组类型创建 new C[] |
不触发 | 只生成数组类型身份，不触及元素类型静态状态 |
| 通过子类访问父类静态字段 | 不触发子类 | 字段归属声明类，只需声明类完成初始化 |
初始化时机的精确性是一种可编程契约——开发者可以依赖它构建惰性模式。典型案例是 Holder 类单例：内部类在首次 getstatic 时才触发初始化，叠加 <clinit> 的线程安全保证，无需显式同步即获得安全惰性初始化。这个模式的正确性完全建立在规范对触发边界的精确承诺之上。
同名不同加载器的两个类型，JVM 视为毫不相干的两个类，即便字节码逐字节相同。由此逐层推出：
| 层面 | 必然后果 | 判定信号 |
|---|---|---|
| 类型系统 | 互不相容：classA == classB、isAssignableFrom、instanceof 全为 false，强转抛 ClassCastException |
X cannot be cast to X（同名却失败） |
| 静态状态 | 各持一套 static 字段与单例：同名类在不同加载器下状态互不可见 | 单例"失效"、静态缓存莫名读不到 |
| 跨界交互 | 通信必须经共享父加载器加载的公共接口；否则两侧无共同超类型可依 | 插件返回值只能 cast 到共享接口，不能 cast 到具体实现 |
一体两面：正向看，这三条后果正是 Tomcat/OSGi 隔离得以成立的机制来源——隔离不是额外机制，就是"类型不相容"本身。反向看，它们也是热部署（Spring DevTools 换加载器重载）、动态代理、序列化反序列化跨加载器场景下 ClassCastException 的根因：同名不代表同型。
因此，跨加载器共享的类型（接口、基类、DTO）必须上提至公共父加载器统一定义——这是一切插件/容器体系的隐性契约。
双亲委派不在 JVM 规范中——它是 java.lang.ClassLoader.loadClass() 的默认实现，属于类库层约定。JVM 的类型安全由 loader constraints 机制保证（链接时强制 N_L1 = N_L2），即便完全不用双亲委派也不会破坏类型安全。那么双亲委派解决什么问题？
它使两件事自动发生而无需显式管理：
没有双亲委派，这两件事仍然可能实现（手动管理委派路径、显式指定加载器），但不再自动——复杂性从框架侧转移到每个使用者。
何时失效：当父加载器需要调用子加载器定义的类型时（SPI、容器/插件体系、中间件扩展点），parent-first 的方向性与需求冲突——高层看不见低层的类。Thread Context ClassLoader 以"显式传入加载器"绕过自动委派，是对便利性约定的局部退出，而非对类型安全的破坏（loader constraints 仍在兜底）。
引用者的定义加载器，即被引用类型的"发起加载器"。 若类 X 引用类 Y，则由加载 X 的那个加载器发起对 Y 的加载。
这条"传导"规则解释了隔离为何能自动成立：只要让模块入口类由独立加载器加载，其引用的全部类型都会自动跟随同一加载器——隔离无需逐类干预，是传导的自然结果。
基于传导规则，工程变体的差异可以用两个自由度描述：
| 自由度一：谁发起加载 | 自由度二：委派策略 | |
|---|---|---|
| 标准双亲委派 | 引用者的加载器（传导默认） | 向上优先（parent-first） |
| Tomcat WebApp | 引用者的加载器（传导默认） | 先己后父（parent-last，隔离优先） |
| OSGi | 引用者的加载器（传导默认） | 查 wiring 图，交给该 package 的 exporter |
| SPI / TCCL | 显式替换为线程上下文加载器 | 被替换后的加载器自身的委派策略 |
多数变体只改变委派策略（自由度二），发起者保持传导默认。SPI/TCCL 是例外——它改变的是发起者本身（自由度一）：高层加载器（如 Bootstrap 加载的 DriverManager）无法看到低层类型（如 App ClassLoader 路径下的数据库驱动），传导方向与可见性冲突，只能用显式传入的加载器替换发起者。