Memory Inconsistency and Java Memory Model
Fast recall
Quick revision
Core answer
Whether the candidate understands the JMM conceptually — a strong differentiation point for freshers
Not knowing the JMM exists or thinking Java memory is always consistent across threads
Name the key happens-before rules: program order, monitor lock, volatile, thread start and join
Interview-ready guide
Interview answer
Memory inconsistency happens when threads share data but the program has no Java Memory Model rule ordering the writer and reader. A reader may keep seeing an old flag, or it may see a publication flag without safely seeing all the state that was meant to accompany it.
The JMM solves this through happens-before relationships. For example, writes done before releasing a monitor become visible to a thread that later acquires the same monitor. Writes before a volatile publication become visible after another thread observes that volatile write. Thread.start() and successful completion observed through join() also create ordering. I explain it this way instead of saying Java literally flushes every value to 'main memory,' because the specification promises observable ordering and visibility, not one cache implementation.
Memory Inconsistency and Java Memory Model
Direct Answer
Memory inconsistency means a thread is allowed to observe stale or unexpectedly ordered effects of another thread because the program has no required happens-before relationship. The Java Memory Model defines the guarantees. A volatile hand-off, release and later acquire of the same monitor, thread start/join, and concurrent utilities can create the needed ordering.
Common Mistakes & Pitfalls
- Reasoning only from CPU caches: the JMM defines observable ordering across JVM and hardware implementations.
- Assuming elapsed time publishes a write: sleeping or waiting longer does not create happens-before.
- Forgetting monitor identity: unlock orders a later lock of that same monitor.
- Using volatile for a multi-step invariant: a volatile field does not make related updates one transaction.
- Calling every differing observation a bug in Java: without the required ordering, the program itself has not established the visibility it expects.
Check your understanding
Answer these without looking back at the article.
- Why is wall-clock order not sufficient for memory visibility?
- What is instruction reordering in the JVM?
- What are the visibility guarantees of starting a thread?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.