volatile Keyword in Java
Fast recall
Quick revision
Core answer
volatile gives a field Java Memory Model visibility and ordering guarantees. A write to a volatile field happens-before a later read that observes it, so it can safely publish earlier writes. It does not make compound actions such as count++ atomic, and Java does not define it as bypassing CPU caches or always reading physical main memory.Understanding of volatile's guarantees and limitations in concurrent Java programming
Thinking volatile makes a variable fully thread-safe for all operations like incrementing counters
Explain the difference between visibility (what volatile gives) and atomicity (what it doesn't), using a concrete counter example
Interview-ready guide
Interview answer
volatile is a Java Memory Model tool for visibility and ordering. When one thread writes a volatile field and another later observes that write, the earlier actions are ordered and visible to the reader. A stop flag is a common example.
I would not explain it as every read going to physical main memory, because that is not the specification. The important limit is atomicity: a volatile read or write has the documented semantics, but count++ is still a compound read-modify-write and can lose updates. I use an atomic class for one counter and a lock when several values must stay consistent together.
volatile Keyword in Java
Direct Answer
volatile gives a field Java Memory Model visibility and ordering guarantees. A write to a volatile field happens-before a later read that observes it, so it can safely publish earlier writes. It does not make compound actions such as count++ atomic, and Java does not define it as bypassing CPU caches or always reading physical main memory.
Code Example
class TaskRunner implements Runnable {
private volatile boolean running = true;
@Override
public void run() {
while (running && !Thread.currentThread().isInterrupted()) {
processOneUnit();
}
}
void stop() {
running = false;
}
}
A volatile write publishes the new flag value under the Java Memory Model. It does not promise instant scheduling or wake a thread blocked in I/O; interruption or a resource-specific cancellation action may also be needed.
Common Mistakes & Pitfalls
- Using volatile for
count++: the compound read-modify-write can lose updates. - Calling volatile a lightweight lock: it provides no mutual exclusion.
- Explaining it as physical main-memory access: the JMM promises ordering and visibility, not one cache algorithm.
- Assuming one writer is a language requirement: several writers are valid when plain last-write-wins semantics are enough.
- Expecting a flag to unblock I/O: a volatile value does not itself wake a blocked operation.
Check your understanding
Answer these without looking back at the article.
- What is the difference between volatile and synchronized?
- Can volatile replace synchronized?
- Is double or long reading atomic without volatile in Java?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.