Java类加载过程包括加载、验证、准备、解析、初始化5个阶段：加载从字节流生成Class对象；验证确保字节码合规；准备为静态变量设默认值；解析将符号引用转为直接引用；初始化执行方法赋值和静态块。
Java 程序不是直接跑在操作系统上的，javac 编译出的 .class 文件必须经 JVM 类加载器载入内存、完成链接和初始化后，才能执行 main 方法。跳过类加载阶段谈“运行”，等于只写了半条命令就按回车。
javac 编译生成的 .class 文件到底包含什么
它不是机器码，而是 JVM 能识别的二进制字节码，结构严格固定：
-
魔数（0xCAFEBABE）：前 4 字节，JVM 一读就知这是合法 Class 文件 -
版本号：如 major version 61 对应 JDK 17，版本不匹配会报UnsupportedClassVersionError -
常量池：存所有符号引用（类名、方法名、字段名、字符串字面量等），是解析阶段的关键输入 -
类/字段/方法表：描述访问标志（public/static）、名称、描述符（如([Ljava/lang/String;)V） -
Code 属性：每个方法的字节码指令（如iconst_1、astore_0、invokestatic）就在这里
用 javap -v MyClass 可直观看到这些内容。注意：javac 不做重排序、逃逸分析等激进优化，前端优化仅限常量折叠、死代码消除等轻量级操作。
类加载器不是“一股脑全塞进来”，而是分层委派+懒加载
真正触发加载的时机是“首次主动使用”，比如 new MyClass()、MyClass.class、调用静态方法或访问静态字段——**单纯声明变量或 import 不会触发**。
立即学习“Java免费学习笔记（深入）”；
-
Bootstrap ClassLoader：由 C++ 实现，加载$JAVA_HOME/jre/lib/rt.jar等核心类（java.lang.*），无父加载器 -
Extension ClassLoader：加载$JAVA_HOME/jre/lib/ext下的扩展类 -
Application ClassLoader：也叫系统类加载器，加载-classpath或CLASSPATH指定路径下的类
双亲委派模型意味着：当 Application ClassLoader 收到加载 java.lang.Object 的请求时，它会逐级向上委托，最终由 Bootstrap 加载——这保证了核心类不会被用户自定义类覆盖。自定义类加载器必须显式打破委派（重写 loadClass），否则仍走默认链路。
链接阶段的验证、准备、解析三步缺一不可
加载完字节码只是“拿到数据”，链接才是让类真正可用的关键校验：
-
验证：检查魔数、版本、常量池格式、字节码逻辑（比如跳转指令是否指向非法偏移），失败抛VerifyError -
准备：为static变量分配内存并设默认值（int x→0，Object o→null），但此时static int x = 5;中的= 5还没执行 -
解析：把常量池里的符号引用（如"java/io/PrintStream"、"println:(Ljava/lang/String;)V"）替换成内存中真实地址或偏移量；若类还没加载，这里会触发其加载
注意：final static 基本类型字面量（如 final static int VAL = 10;）会在准备阶段直接赋值，因为编译期已确定，属于“编译期常量”。
初始化阶段才真正执行 static 代码块和 static 变量赋值
这是类加载流程最后一步，也是 main 方法能被执行的前提：
- JVM 会为每个类生成一个
<clinit></clinit>方法，按源码顺序合并所有static变量赋值语句和static{}块 -
<clinit></clinit>是线程安全的：JVM 保证同一时间只有一个线程执行它，其他线程阻塞等待 - 父类
<clinit></clinit>总是在子类之前执行（继承链自顶向下）
常见陷阱：如果 static 块里调用了尚未初始化的其他类，可能引发死锁或 NoClassDefFoundError；又或者 static 字段初始化依赖外部资源（如配置文件读取失败），会导致类初始化失败，后续所有对该类的主动使用都会抛 ExceptionInInitializerError。
整个过程不是线性单通道，而是一个带条件分支、可中断、有并发控制的协作机制。最容易被忽略的是“懒加载”的触发边界——很多问题其实源于误以为类已被加载，实则连 prepare 都没走到；还有就是混淆 prepare（设默认值）和 <clinit></clinit>（执行赋值）两个阶段，导致对静态变量初值的误判。
