MediumExperience level: 8-15 years1 min read

How can static initialization order cause a subtle bug or even a deadlock?

Reviewed by Gurusankar M.

Asked inGoogleAmazonMicrosoft
#static#class loading#initialization#deadlock#singleton
Report issue

Short Answer

Static initializers run once at class load, in textual order, and can deadlock if two classes initialize each other from different threads. Circular static dependencies also yield half-initialized (null/zero) values.

On this page

Concept Made Simple

Coffee Chat Question

“How can static initialization order cause a subtle bug or even a deadlock?”

Remember It Faster

Mind Map Answer

Class init holds a per-class lock. If thread A loads ClassX (which needs ClassY) while thread B loads ClassY (which needs ClassX), each waits on the other's init lock → deadlock.

Learn by Doing

Hands-on Keyboard

java
class A { static int x = B.y + 1; }
class B { static int y = A.x + 1; } // circular init
// One of x/y reads the other while it's still 0

Think Beyond the Expected

What If?

An app hangs only at startup under load — how do you confirm a static-init deadlock?

Take a thread dump (jstack). You'll see two threads BLOCKED in <clinit> of different classes, each waiting on the other's class-init monitor. Fix by breaking the cycle or lazy-loading.

Real World

Static-init deadlocks surface as intermittent startup hangs in multi-threaded bootstrapping (e.g. parallel class loading, driver registration); the thread dump shows BLOCKED <clinit> frames.

Interviewer's Expectation

Keywords they're listening for:

  • <clinit> runs once, in order
  • per-class init lock
  • circular dependency → deadlock/partial init
  • thread dump diagnosis

Common Mistakes

  • Circular static dependencies between classes
  • Heavy work (I/O, network) in static initializers
  • Assuming static fields are set before another class reads them

Best Practices

  • Avoid cross-class static cycles
  • Use the holder idiom for lazy, thread-safe singletons
  • Keep static blocks trivial; do heavy init lazily

Follow-up Questions

  1. How does the JVM guarantee init runs once and thread-safely?
  2. Why is the initialization-on-demand holder idiom a safe lazy singleton?
  3. How do you read <clinit> frames in a thread dump?

Continue Learning with AI

Take this question deeper with your favourite AI assistant. Pick a depth, copy the prompt, or open it directly — AI is your learning companion, not a shortcut.

Plain-language foundations

I'm preparing for a software engineering interview and want to understand this from scratch, as a beginner.

Topic: JVM/Class loading (Core Java)
Interview question: "How can static initialization order cause a subtle bug or even a deadlock?"

Please:
1. Explain the core idea in simple, plain language, using an everyday analogy.
2. Define any technical terms you use.
3. Walk through one small, concrete example.
4. Finish with a single sentence I can easily remember.

Keep the tone friendly and assume I'm new to this topic.
Open inChatGPTGeminiClaude

Was this answer helpful?

Affiliate links

Tools for Your Developer Workspace

Equipment for a comfortable, productive setup.

As an Amazon Associate I earn from qualifying purchases.