Java 中对象初始化全流程中代码块执行顺序如何验证

Ja va对象的初始化顺序，其实有一个非常清晰的规矩：静态成员（变量和代码块）按声明顺序执行，并且只在类加载时跑一次；之后每次 new 对象时，先走父类的实例成员（变量和代码块），再走子类的实例成员，最后才轮到构造方法。这个顺序是固定的，但很多人在实际写代码时容易踩坑，尤其是遇到继承链、构造器重载或者 `super()`/`this()` 的时候。

要验证这个顺序，最直接的办法就是在各种代码块和构造方法里埋上日志输出，然后观察控制台的打印结果。静态部分只执行一次，实例部分每次 new 都来一遍，最后才是构造方法体——这是总纲。

静态成员优先执行

类加载的那一瞬间，静态变量赋值和静态代码块就会严格按照它们在源码中的出现顺序执行，而且只执行一次。哪怕你创建一百个对象，这一部分也只会触发一次。

• 静态变量初始化表达式（比如 static int a = getValue();）的位置决定了它是在对应静态代码块之前还是之后执行——全看它在代码里的前后顺序。
• 多个静态代码块之间的执行顺序也完全由书写顺序决定，别指望编译器帮你调顺序。
• 一个简单的验证技巧：在 main 方法前面加一行 System.out.println("main start");，对比日志就能看到静态部分早在 main 执行之前就跑完了。

实例成员按声明顺序执行

每次 new 对象时，系统会先从父类开始，执行父类的实例变量赋值和实例代码块，然后再轮到子类。同一个类内部，实例变量和实例代码块也是按文本顺序依次执行的。

• 父类的实例代码块和变量初始化一定在子类之前执行，这是继承链上的铁律。
• 即使子类构造器第一行写了 super(...)，也不会打乱实例块的执行顺序——`super()` 只是控制父类构造器的调用时机，而父类的实例块早在 `super()` 的内部就已经执行完毕了。
• 建议在每个实例代码块和变量初始化处打印带类名和序号的日志，比如 System.out.println("SubClass instance block 1");，这样一眼就能看出执行顺序。

构造方法总是最后执行

构造方法体里的代码，必须等当前类所有的实例变量赋值和实例代码块都跑完之后，才会开始运行。需要注意的是，`this(...)` 或 `super(...)` 虽然必须是构造方法的第一句，但它们只是触发父类或本类的其他构造器，并不会改变“实例块 → 构造体”这个大顺序。

• 如果构造方法里用了 this()，程序会先跳去执行另一个构造器——但那个构造器也得先把自己的实例块跑完，才会执行自己的方法体。
• 一个实用的调试习惯：在每个构造方法的第一行和最后一行都加上日志，这样能清晰看到构造方法的执行边界。
• 注意一个经典陷阱：不要在构造器中调用可能被子类重写的方法。因为此时子类的实例块还没执行，方法里可能访问到未初始化的字段，结果全乱套。

验证技巧与常见陷阱

最可靠的验证方式，就是写一个带继承关系的最小可测类，在每个关键位置插入唯一标识的打印语句，然后直接运行看输出。重点盯住这条链条：父类静态 → 子类静态 → 父类实例 → 子类实例 → 父类构造 → 子类构造。

• 不要依赖 IDE 的代码折叠或格式化显示顺序——一定要以源码的实际行号为准。
• 编译器可能会对常量表达式做优化，比如 static final int x = 1; 可能被内联成字面量，这会影响日志位置的判断，要小心。
• 使用匿名内部类或 Lambda 时，不会触发外部类的实例块重复执行，但如果外部类还没加载，会触发其静态部分的执行。