怎么理解类加载过程中静态代码块与构造块的执行先后顺序

来到golang学习网的大家，相信都是编程学习爱好者，希望在这里学习文章相关编程知识。下面本篇文章就来带大家聊聊《怎么理解类加载过程中静态代码块与构造块的执行先后顺序》，介绍一下，希望对大家的知识积累有所帮助，助力实战开发！

静态代码块在类加载时执行且仅一次，构造块在new对象时、super()后执行；继承中父类静态块先于子类执行，构造块按父→子顺序插入各构造方法开头。

静态代码块在类加载时执行，构造块在 new 对象时才执行

静态代码块（static {}）属于类级别，JVM 加载类到方法区时就触发，且只执行一次；构造块（{}）属于实例级别，每次调用 new 创建对象时才执行，且一定在对应构造方法体之前。

关键区别在于触发时机：类加载 ≠ 实例化。哪怕你从不 new 任何对象，只要类被主动使用（比如访问 SomeClass.SOME_STATIC_FIELD 或调用 SomeClass.staticMethod()），static{} 就会运行；而 {} 完全不参与类加载流程，它被编译器“插入”到每个构造方法开头，是对象初始化的一部分。

有继承时，父类静态块一定先于子类静态块执行

当首次使用子类（如 new Child()），JVM 先检查父类是否已加载。没加载则递归加载父类——这意味着父类的 static{} 总是先跑，然后才是子类的 static{}。这个顺序由类加载器委托机制决定，不是靠代码书写位置。

• 多个 static{} 在同一类中，按源码声明顺序执行
• 父类和子类的 static{} 各自独立，但加载顺序固定为 父 → 子
• 即使子类没写 static{}，父类的仍会执行；反之，若只引用子类静态成员，父类也会被拉进来加载

构造块执行发生在 super() 返回之后、构造方法体开始之前

构造块（{}）实际被编译进每个构造方法的第一行（在显式或隐式 super() 调用之后）。所以完整链条是：父类构造块 → 父类构造方法体 → 子类构造块 → 子类构造方法体。

容易踩的坑：

• 在父类构造方法中调用被子类重写的方法，此时子类字段尚未执行显式初始化（仍是默认值 0 或 null），而子类的构造块还没跑 —— 这是典型的“过早暴露 this”问题
• 误以为构造块能访问子类的非静态字段：它确实可以，但前提是该字段已在子类中声明（哪怕未初始化），且其显式赋值语句（如 int x = 5;）和构造块按文本顺序执行，二者谁在前谁先发生

验证执行顺序最可靠的方式是实测输出

别死记“父静→子静→父构块→父构→子构块→子构”，直接写个带 System.out.println 的父子类，跑一次 new Child() 看控制台输出。你会发现：静态部分只在第一次 new 时打印；第二次 new 时，只有构造块和构造方法的内容再出现。

真正容易被忽略的是：静态块里的逻辑不能依赖任何实例状态，而构造块虽然写在类体里，但它本质上是构造方法的前置逻辑——它和构造方法共享 this，也共享对象创建过程中的字段初始化阶段。这点在设计工具类或单例时尤其关键。

今天关于《怎么理解类加载过程中静态代码块与构造块的执行先后顺序》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！