类只在首次主动使用时初始化，且加载、验证、准备、解析、初始化五阶段有序进行，解析可延迟至首次使用符号引用时；仅五种情况触发初始化：new指令、读写非final静态字段、调用静态方法、反射Class.forName（默认true）、主类启动。
ClassLoader 的行为不是“自动运行”的魔法，而是由 JVM 严格按规则触发的确定性流程。类加载机制的核心结论是：**类只在首次主动使用时才被初始化，且加载、验证、准备、解析、初始化这五个阶段有明确顺序约束，但解析可延迟到首次使用符号引用时才发生**。
什么时候会真正触发 Class 初始化？
很多开发者误以为“类被加载了就等于初始化了”，其实加载（load）和初始化（initialize）是两个分离阶段。只有以下五种情况才会强制触发
- 遇到
new指令创建实例（如new UserService()） - 读写静态字段（
getstatic/putstatic），但final static编译期常量除外（如public static final int PORT = 8080;不会触发初始化） - 调用静态方法（
invokestatic） - 通过反射访问类，如
Class.forName("com.example.User")（注意：Class.forName(name, false, loader)中第二个参数为false时不会初始化） - JVM 启动时指定的主类（含
main方法的类）
典型陷阱：子类引用父类的静态字段（Sub.NUM）只会加载并初始化父类 Sup，Sub 自身不初始化——这点常导致静态代码块未执行、配置未加载等“神秘”问题。
双亲委派模型不是设计选择，而是安全刚需
当你的代码调用 MyClassLoader.loadClass("java.lang.String")，它不会自己去加载，而是层层向上委托：
- 先问应用类加载器（
AppClassLoader）→ 它转手交给扩展类加载器（ExtClassLoader） - 扩展类加载器再交给启动类加载器（
BootstrapClassLoader） - 启动类加载器发现自己能加载
java/lang/String.class
（来自 rt.jar或modules），直接返回Class对象 - 后续加载器不再尝试，整个链路终止
（来自 这个模型防止你用自定义的恶意 java.lang.String 替换核心类——一旦绕过双亲委派（比如重写 loadClass 并跳过 super.loadClass），就可能引发 NoClassDefFoundError 或 LinkageError，尤其在 OSGi、热部署、JDBC 驱动加载（ServiceLoader）等场景中极易暴露。
准备阶段赋的是“零值”，不是代码写的初始值
看这段代码：
public class Config {
public static int TIMEOUT = 3000;
public static final int MAX_RETRY = 5;
}
在准备阶段：
-
TIMEOUT被分配内存并设为0（int 零值），不是3000 -
MAX_RETRY因为是static final基本类型且编译期可确定，**直接在准备阶段就赋值为5**
真正的 TIMEOUT = 3000 是在初始化阶段，由 TIMEOUT，输出是 0；如果该字段被其他类在初始化前反射读取（比如通过 Field.get(null)），拿到的也是 0，而非预期值。
解析阶段可延迟，但符号引用必须“真存在”
解析是把常量池里的符号引用（如字符串 "com.example.Dao"）转成内存中的直接引用（比如类对象地址）。它通常发生在初始化前，但 JVM 允许延迟到首次真正使用该符号引用时才解析——这就是支持动态绑定的基础。
但延迟不等于宽容：如果某处写了 invokestatic com/example/Utils.log:(Ljava/lang/String;)V，而 Utils 类根本不存在或方法签名不匹配，哪怕你没走到那行代码，只要 JVM 在解析时发现异常，就会抛出 NoSuchMethodError 或 NoClassDefFoundError。常见于：
- 接口默认方法被子类覆盖，但子类 jar 未升级，导致解析旧方法失败
- 使用了高版本 JDK 编译的类（如
String.strip()），却在低版本 JVM 上运行 - 混淆工具错误处理了反射调用的目标类名，导致解析时找不到类
最隐蔽的坑在于：这些错误往往不在编译时报出，也不在类加载日志里明显提示，而是在某个特定业务路径第一次调用时突然爆发——所以线上排查要重点看 ClassNotFoundException 和 LinkageError 的堆栈中，是否涉及尚未初始化的依赖类。
