Java类加载机制分加载、链接（含准备）、初始化三阶段：加载时仅载入字节码并生成Class对象，静态变量未分配内存；准备阶段为其分配内存并设默认零值；初始化阶段执行<clinit>方法，按源码顺序赋值静态变量和执行静态块。
Java类加载机制不是简单的“把class文件读进来”，它直接决定了静态变量何时分配内存、何时赋值、何时可见——而ClassLoader不仅是加载入口，更是整个初始化行为的调度者和隔离边界。
类加载三阶段与静态变量生命周期
类加载分为加载、链接（含准备）、初始化三个关键阶段，静态变量的命运在每个阶段都有明确归属：
- 加载阶段：仅将.class字节码载入方法区，生成Class对象；此时静态变量尚未分配内存，更无值可言。
- 准备阶段：为所有static变量分配内存，并设为默认零值（如int为0、Object为null）；注意：此处不执行任何赋值语句或静态代码块。
-
初始化阶段：真正执行
<clinit>方法——即按源码顺序合并的静态变量显式赋值 + 静态代码块；这是静态变量获得“业务含义”的唯一时刻。
ClassLoader如何影响静态变量的可见性与初始化时机
同一个类被不同ClassLoader加载，会得到两个完全独立的Class对象，彼此的静态变量互不干扰：
- AppClassLoader加载的
Config类，其public static String ENV = "prod"只对该加载器实例有效； - 若Web容器用自定义ClassLoader再次加载同一份
Config.class，新类中的ENV初始为null，直到它自己的<clinit>被执行； - 双亲委派机制确保核心类（如
java.lang.String）不会被子加载器重复加载，从而避免静态状态分裂；但绕过委派（如重写loadClass）极易引发LinkageError或静态变量“隐身”问题。
静态变量初始化顺序的底层逻辑
初始化不是按字母或随机顺序，而是严格遵循源码声明顺序+继承链深度优先：
立即学习“Java免费学习笔记（深入）”；
- 父类静态变量和静态块先于子类执行；
- 同一类中，变量声明位置靠前的先初始化；若某静态变量依赖另一个（如
static int b = a + 1;），则a必须已初始化完成； - 循环依赖会导致
IllegalAccessError或静默使用默认值（如int为0），调试时需特别留意日志中<clinit>的执行轨迹。
哪些操作真正触发初始化（而非仅加载）
只有主动引用才会走到初始化阶段，ClassLoader在此刻才真正“启动”静态变量的赋值流程：
- new对象、调用静态方法、读写非final静态字段；
- 反射调用
Class.forName("X")（注意：Class.forName("X", false, loader)第二个参数为false时跳过初始化）； - 子类初始化时强制触发父类初始化；
- 反例：访问
final static String API_URL = "https://a.com"（编译期常量）不触发类初始化；数组声明MyClass[] arr只加载不初始化。
