Java类加载机制全解析

大家好，今天本人给大家带来文章《Java类加载机制详解》，文中内容主要涉及到，如果你对文章方面的知识点感兴趣，那就请各位朋友继续看下去吧~希望能真正帮到你们，谢谢！

类只在首次主动使用时初始化，且加载、验证、准备、解析、初始化五阶段有序进行，解析可延迟至首次使用符号引用时；仅五种情况触发初始化：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 的堆栈中，是否涉及尚未初始化的依赖类。

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于文章的相关知识，也可关注golang学习网公众号。