Walk through the exact order of execution when constructing an object in an inheritance hierarchy, including field initializers and chained this() calls.

## The pieces involved When you write `new Child()`, several kinds of initialization code can run: - **Constructors** — `super(...)`/`this(...)` calls plus the constructor body. - **Instance field initializers** — e.g. `private int x = 5;`, the `= 5` part. - **Instance initializer blocks** — bare `{ ... }` blocks in the class body (no `static`). (Static fields and `static { }` blocks are different — they run once at *class load*, before any instance is created, and are not part of per-object construction.) ## The canonical per-object order For a single class, constructing an instance does: 1. Run the explicit `this(...)` or `super(...)` (or the implicit `super()`). 2. If step 1 was a `super(...)` (i.e. this constructor does *not* delegate to a sibling via `this(...)`), run this class's **instance field initializers and instance init blocks**, in the order they appear in source. 3. Run the rest of this constructor's body. Because `super(...)` is step 1 and it fully constructs the parent, the **parent is always completely initialized before the child's field initializers or body run**. Recursively, this means construction climbs to `java.lang.Object` first, then unwinds downward. ## Full trace for a two-level hierarchy ```java class A { int a = 1; // field init { System.out.println("A init block, a=" + a); } A() { System.out.println("A ctor body"); } } class B extends A { int b = 2; // field init { System.out.println("B init block, b=" + b); } B() { System.out.println("B ctor body"); } } ``` `new B()` prints: ``` A init block, a=1 A ctor body B init block, b=2 B ctor body ``` Expanded order: `B()` invoked -> implicit `super()` -> Object constructed -> A's field init (`a=1`) + A's init block -> A's body -> B's field init (`b=2`) + B's init block -> B's body. ## What this() changes A `this(...)` call delegates to another constructor *in the same class*. The field initializers and init blocks of that class run exactly **once**, attached to the constructor in the chain that actually calls `super(...)` (the non-delegating one). So: ```java class C { int x = 10; C() { this(99); System.out.println("no-arg, x=" + x); } // delegates C(int v) { System.out.println("int ctor, x=" + x); } // reaches super() } ``` `new C()` prints: ``` int ctor, x=10 no-arg, x=10 ``` The field initializer `x = 10` runs inside `C(int)` (the one that reaches `super()`), *before* its body; then control returns to `C()`'s body. It does **not** run twice. ## The famous pitfall: overridable method in a constructor Because the **parent constructor body runs before the child's field initializers**, calling an overridable method from a parent constructor invokes the *child's* override while the child's fields are still at their default values (0/null): ```java class Base { Base() { init(); } void init() {} } class Sub extends Base { int n = 42; @Override void init() { System.out.println(n); } // prints 0, not 42! } ``` `new Sub()` prints `0`: `Base()` calls the overridden `init()` before `n = 42` has executed. Hence the rule: **never call an overridable method from a constructor** (call only private/final/static methods, which can't be overridden). ## Why interviewers ask this It ties together overriding, dynamic dispatch, field-initializer timing, and chaining — and it explains real bugs (NPEs/zero values during construction in frameworks and serialization). Knowing the precise order lets you reason about and avoid them.