Race Condition and synchronized Prevention
Fast recall
Quick revision
Core answer
synchronized prevents a particular race only when every competing path guards the complete critical operation with the same monitor. It provides mutual exclusion for that monitor and a happens-before relationship between unlock and a later lock.Whether the candidate can explain race conditions with a concrete example, not just abstract theory.
Saying two threads run at the same time without explaining why concurrent access to shared data produces incorrect results.
Explain the read-modify-write sequence at the CPU instruction level using the classic counter increment example, showing how operations interleave.
Interview-ready guide
Interview answer
A race condition means concurrent actions on shared state can interleave and produce a wrong result. For example, with a shared counter at 10, two threads can both read 10 and both write 11, so one increment is lost.
A synchronized region fixes that race only when every competing path uses the same monitor and the complete read-modify-write stays inside the critical section. Then one thread owns that monitor at a time. Releasing the monitor also happens-before a later acquisition, so the next owner sees the protected writes. Synchronizing one method is not enough if another method reaches the same state without the monitor, and two blocks synchronized on different lock objects do not protect each other. The locking rule belongs to the shared invariant, not merely to one line of code.
Race Condition and synchronized Prevention
Direct Answer
A race condition occurs when an unsafe interleaving of actions on shared state can make the result incorrect. synchronized prevents a particular race only when every competing path guards the complete critical operation with the same monitor. It provides mutual exclusion for that monitor and a happens-before relationship between unlock and a later lock.
Common Mistakes & Pitfalls
- Assuming single Java statements are atomic: Freshers think
count++is a single indivisible operation, but it compiles to multiple conceptual steps that can interleave. Only assignments of references and primitives up to 32 bits are atomic without synchronization. - Not synchronizing reads: Protecting writes with synchronized but leaving reads unsynchronized still causes race conditions—readers might see partially updated state or stale cached values.
- Using separate lock objects: If Thread A synchronizes on
lockAand Thread B synchronizes onlockBwhile accessing the same shared variable, both can enter the critical section simultaneously because they're not contending for the same lock.
Check your understanding
Answer these without looking back at the article.
- Is int assignment atomic in Java?
- What is AtomicInteger and how is it different from synchronized?
- What is a data race vs a race condition?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.