Race Condition.

Hook: A race condition is the bug that hides in plain sight: each thread looks fine alone, but two threads arriving together can corrupt the result.

Question: What is a race condition in Java multithreading?

Answer: A race condition happens when the result depends on the timing or interleaving of two or more threads. In Java, it usually appears when threads share mutable data, like a counter or a list, without proper synchronization. The code may work most of the time, then fail randomly under load.

Interview-Ready Answer: A race condition is when multiple threads access shared mutable state and the final result depends on who runs first. For example, counter++ is not atomic, so two threads can both read the same old value and one update gets lost. I fix it with synchronized, Lock, or atomic classes like AtomicInteger, depending on whether I need simplicity or higher concurrency.

Detailed Explanation: The easiest way to remember a race condition is: same shared data + no proper coordination + unlucky timing. The bug is not that threads exist; the bug is that the program assumes they will take turns nicely, and the CPU does not promise that.

How it works under the hood

1. Two or more threads touch the same mutable variable, object, or collection.
2. Each thread performs a read-modify-write sequence. For counter++, that means read the current value, add 1, then write it back.
3. The scheduler can switch threads between those steps. A context switch is just the CPU pausing one thread and running another.
4. Both threads may read the same old value before either write happens.
5. One write overwrites the other, creating a lost update.
6. Java also cares about visibility and ordering. Visibility means another thread can see your write; ordering means operations are observed in a sensible sequence. The Java Memory Model defines this with happens-before, which is the guarantee that one action becomes visible before another.

That is why volatile is not enough for count++. volatile helps visibility, but it does not make the whole read-add-write sequence atomic, which means indivisible.

When and why to use fixes

You use synchronization when multiple threads must safely update shared state. If you can avoid shared mutable state entirely, that is even better. Immutable data, meaning data that never changes after creation, is the cleanest defense because there is nothing to race over.

Performance and complexity

The logical cost of a simple update is still O(1), but real speed depends on contention, meaning how many threads fight over the same lock or variable. On a server with 8 to 32 worker threads, a single shared counter can become a hotspot very quickly. AtomicInteger uses CAS, short for compare-and-set, which retries if another thread wins first; this is often fast, but under heavy contention it can spin and waste CPU. synchronized blocks, on the other hand, may block threads instead of retrying, which is simpler but can reduce throughput.

Important edge cases

• Check-then-act: if (!list.contains(x)) list.add(x) is a race unless the whole check and add are protected together.
• Shared collections: a synchronized wrapper does not make iteration magically safe unless you also synchronize while iterating.
• Lazy initialization: double-checked locking needs volatile on the instance field.
• Read-only is not always safe: reading a mutable object while another thread writes it can still show stale or inconsistent data.

Memory hook: think of one whiteboard and two people writing at once. If both erase and rewrite the same line without agreeing on turns, someone’s message disappears.

Real-World Example: Imagine a checkout service during a flash sale. The inventory table says there is exactly one headset left. Two request threads enter the purchase flow at nearly the same time, both see stock = 1, and both try to reserve it. Without synchronization, both orders may succeed logically, then one inventory update is lost or the stock goes negative. Users see weird errors like duplicate reservations, payment captured but order cancelled later, or logs such as remainingStock=-1. In production, that bug turns into angry customers, manual refunds, and support tickets that are hard to reproduce because the timing window is tiny.

Follow-up & Tricky Questions:

• How is a race condition different from a data race? A race condition is the broader idea that outcome depends on timing; a data race is the Java-level symptom where threads access shared mutable data without proper synchronization.
• Why does volatile not fix counter++? Because volatile gives visibility, not atomicity. The read, add, and write can still be interrupted by another thread.
• What is the difference between synchronized and ReentrantLock? Both give mutual exclusion, but ReentrantLock adds tryLock, timed waits, and fairness options. synchronized is simpler and releases automatically when the block exits.
• What is CAS? CAS means compare-and-set. It updates only if the current value still matches the expected value, and if not, it retries; this is how atomic classes avoid many locks.
• How do you make a check-then-act sequence safe? Put the whole sequence inside the same lock or redesign it so one atomic operation owns the decision and the update together.
• Can a program have a race condition even if it has only one writer? Yes. A reader can still observe stale or partially coordinated state if the writer does not publish updates safely.
• Does testing on your laptop prove there is no race? No. Races are timing bugs, so they often disappear under light load and reappear in production when the thread schedule changes.
• Is every race condition a deadlock? No. A race condition is about wrong results from timing; a deadlock is when threads wait forever for each other.
• Can two synchronized methods on different objects still race? Yes. They only protect data if they use the same lock for the same shared state.

Common Mistakes:

• Using volatile for increments: wrong fix; use synchronized or atomic classes for compound updates.
• Locking the wrong object: a lock only works if every thread uses the same monitor for the same data.
• Protecting only half the logic: if you synchronize the update but not the check, the race still exists.
• Assuming local tests are enough: a race can pass 1,000 times and fail on the 1,001st under real traffic.

Memory Hook: Picture two people erasing and rewriting the same line on a whiteboard at the same time. Whoever writes last wins, and the other person’s change disappears.

Cheat Sheet:

• Race condition = result depends on thread timing.
• counter++ is not atomic.
• volatile gives visibility, not safety for compound actions.
• synchronized and Lock provide mutual exclusion.
• AtomicInteger uses CAS for lock-free updates.
• Best fix is often to avoid shared mutable state.

Practice Tasks:

• Change the demo to use AtomicLong and compare the result.
• Replace the unsafe counter with a ReentrantLock version and verify correctness.
• Write a safe if not present, then add helper for a shared list.