静态与实例变量加载顺序解析

本文深入剖析了Java中静态变量与实例变量的初始化优先级与执行顺序，揭示了JVM类加载机制如何严格规定“静态内容仅在类首次加载时按源码顺序执行一次，而实例内容则每次new对象时从父类到子类完整重走一遍”，并通过父子类实战案例和典型陷阱（如静态块中提前new对象导致未初始化）直观展现易错点，最后给出可落地的日志验证与调试方法，帮助开发者精准区分“类准备”与“对象构建”两个关键阶段，从根本上规避初始化混乱引发的隐蔽Bug。

静态变量先于实例变量加载，这是由JVM类加载机制决定的——类必须先完成初始化，才能创建对象。实战中真正影响行为的，不是“谁先声明”，而是“谁属于类、谁属于对象”，以及它们在类中出现的顺序。

静态内容只在类加载时执行一次

只要程序首次触发类加载（比如调用静态方法、访问静态字段、或执行 new 操作），JVM 就会按源码书写顺序：

• 为静态变量分配内存并赋予默认值（如 int → 0，Object → null）
• 按从上到下顺序执行静态变量显式初始化（如 static String s = "hello";）
• 再执行每个 static{} 块（同样按出现顺序）

这个过程全局仅发生一次。哪怕后续创建 100 个对象，静态部分也不会重跑。

实例内容每次 new 都重新走一遍

当执行 new MyClass() 时，JVM 在堆中分配对象内存后，立即开始实例初始化流程，顺序严格对应代码位置：

• 为所有实例变量分配内存并设默认值
• 按源码从上到下执行实例变量显式初始化（如 String name = getName();）
• 再依次执行每个普通代码块 {}
• 最后才调用构造器

注意：如果实例变量初始化过程中调用了本类构造器（比如 static MyClass inst = new MyClass();），就会提前触发实例流程——此时静态初始化尚未结束，容易引发未完全初始化的问题。

实战中容易踩坑的典型场景

下面这段代码看似简单，但执行顺序常被误判：

class Parent {
    static { System.out.println("Parent static"); }
    { System.out.println("Parent init"); }
}

class Child extends Parent {
    static { System.out.println("Child static"); }
    { System.out.println("Child init"); }
    public Child() { System.out.println("Child ctor"); }
}

执行 new Child() 时输出是：

• Parent static（父类先加载）
• Child static（子类加载）
• Parent init（进入实例流程，先执行父类实例块）
• Child init（再执行子类实例块）
• Child ctor（最后调用子类构造器）

关键点：静态部分按继承链自顶向下加载；实例部分则按“父类实例块 → 子类实例块 → 构造器”展开，且每次 new 都完整走这一趟。

如何验证和调试加载顺序

不依赖猜测，用日志直接观察：

• 在每个静态变量初始化表达式里加 System.out（如 static int x = logAndReturn(1);）
• 给每个 static{} 和 {} 块打唯一标识日志
• 避免在静态初始化中调用可能触发类加载的外部逻辑（如 Class.forName、反射、或 new 其他尚未加载的类）
• 使用 JVM 参数 -XX:+TraceClassLoading 查看实际类加载时间点

这样能清晰区分“类准备好了吗”和“对象建好了吗”两个阶段，避免把静态逻辑错当成实例逻辑来维护。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《静态与实例变量加载顺序解析》文章吧，也可关注golang学习网公众号了解相关技术文章。