skip to content

Initialization Order

5 roadmaps5 questions

Statics run once at class initialization, parent before child; then per instance, field initializers and instance blocks run in textual order before the constructor body. Interviewers hand you a two-class hierarchy and ask for the exact print order.

part ofJavaoverview, primer and where to startread it →
on this pageshow

explore

questions

5

In Java, what is the difference between static initialization and instance initialization, and when does each one run?

level: juniorimportance: must knowfreq 70%

answer

  1. static = class, once at load
  2. instance = object, every new
  3. static block can't see instance fields
  4. instance code can read static fields
  5. textual order within each phase

basics

~20 s

Static initializers (static fields and static blocks) run once, when the class is first loaded. Instance initializers (instance fields and instance blocks) run every time you create an object with new, just before the constructor body.

solid answer

~40 s

Java has two distinct initialization phases. Static initialization covers static field assignments and static { } blocks; it runs exactly once, when the class is first used (loaded and initialized by the JVM), and the members belong to the class itself. Instance initialization covers instance field assignments and instance { } blocks; it runs once per object, every time new is called, after the super constructor returns and before the body of the current constructor executes. Within each phase, members run in the textual order they appear in the source file. So static setup is one-time per class, while instance setup repeats for each object. A common follow-up is that a static block can never see instance fields, but instance code can read static fields because the class is already initialized by then.

go deeper

for a junior

Can state that static runs once at class load and instance runs on every new, before the constructor body.

for a middle

Explains the lazy class-loading trigger and that members run in textual order within each phase.

for a senior

Distinguishes class initialization from class loading/linking and knows compile-time constants don't trigger init.

for a principal

Discusses implications for singletons, lazy holders, and initialization deadlocks under concurrent class loading.

## What "initialization" means When you declare a field with a value, e.g. `int x = 5;`, that assignment is *initialization code*. Java also lets you write standalone blocks of code that run during initialization. There are two completely separate kinds, distinguished by the keyword `static`. ## Static members vs instance members - A **static** field or block belongs to the **class** itself — there is one copy, shared by everyone, no matter how many objects exist (or even if none do). - An **instance** (non-static) field or block belongs to **each object** — every `new` creates a fresh, independent copy. ```java class Counter { static int created = 0; // ONE shared copy int id; // one per object } ``` ## When static initialization runs The JVM loads a class lazily — only when it is *first actively used* (first `new`, first access to a static member, etc.). At that moment, exactly once for the whole program, the JVM runs the class's **static initialization**: all static field initializers and all `static { ... }` blocks, in the order they appear in the source. This never repeats. ```java class Config { static int n = compute(); // runs once static { System.out.println("loaded"); } // runs once } ``` ## When instance initialization runs Every time you write `new SomeClass(...)`, the JVM performs **instance initialization** for that one object: all instance field initializers and all `{ ... }` (non-static, "instance") blocks run, in source order, and then the constructor body runs. This repeats for every object you create. ```java class Box { int v = 10; // runs every new { System.out.println("made a box"); } // instance block, runs every new Box() { /* body runs last */ } } ``` ## The key ordering fact at this level By the time any instance code runs, the class has already been loaded and statically initialized. That is why an instance block can freely read a static field, but a static block cannot read an instance field (no object exists yet during static init). This ordering — static once, then instance per-object — is the foundation for the more detailed cross-hierarchy rules. ## Summary table | | Belongs to | Runs | How often | |---|---|---|---| | static field / `static {}` | class | first use of class | once | | instance field / `{}` | object | each `new` | every object |

  • Can a static initializer block read an instance field?
    No. Static init runs at class load when no object exists, so there is no instance field to read; the compiler rejects it.
  • What triggers static initialization of a class?
    The first active use: creating an instance, accessing a static field (non-constant), calling a static method, or reflective initialization.

saying these in an interview costs you the question

  • Thinking static blocks run on every new (they run once)
  • Thinking instance fields are initialized at class load
  • Believing a static block can reference this or an instance field

context

resolving links…

open as a page

Walk through the exact order of operations when you call new on a subclass: default values, super constructor, instance initializers, field initializers, and the constructor body. Why is this order important?

level: middleimportance: must knowfreq 68%

basics

~20 s

On new: fields first get default values (0/null/false), then the parent constructor runs fully, then this class's instance field initializers and instance blocks run top-to-bottom, and finally the constructor body runs. Parent is always fully built before the child.

open as a page

What initialization-order pitfalls can produce wrong values, NullPointerExceptions, or ExceptionInInitializerError, and how do you avoid them?

level: seniorimportance: should knowfreq 40%

basics

~20 s

Common traps: a static field reads another static field declared later (gets default value), a constructor calls an overridable method that sees uninitialized subclass fields, and an exception in a static initializer becomes an ExceptionInInitializerError that permanently breaks the class. Avoid by ordering declarations carefully and not calling overridable methods from constructors.

open as a page

How does static initialization run across a class hierarchy, and exactly when is a superclass's static initialization triggered relative to a subclass's?

level: seniorimportance: should knowfreq 45%

basics

~20 s

A class's static initialization runs once, and a superclass is always initialized before its subclass. So when a subclass is first used, the JVM initializes the parent's statics first, then the child's. Each happens at most once.

open as a page

How does constructor chaining with this(...) interact with instance field initializers and instance blocks, and how many times do those initializers run?

level: middleimportance: nice to knowfreq 28%

basics

~20 s

When a constructor calls this(...) to delegate to another constructor of the same class, the instance field initializers and instance blocks run only once, in the constructor that actually calls super(...). Delegating constructors do not re-run them.

open as a page