A race condition isn't a rare timing gremlin you exorcise by sprinkling synchronized over everything that moves. It's a missing happens-before relationship — a spot where one thread writes and another reads, and nothing in your code guarantees the reader sees the write. Once you think in those terms, the fix stops being "add a lock" and becomes "pick the cheapest tool that creates the ordering I need." Sometimes that's a lock. Often it's something smaller.

This post is the practical version: just enough memory-model theory to make the fixes make sense, then the actual tools — atomics, locks, concurrent collections, immutability — and when to reach for each.

The short version (TL;DR)

• c++ is not one operation. It's read, add, write — and two threads can interleave those steps so one update vanishes.

• A race condition means correctness depends on timing. A data race is the memory-model version: two conflicting accesses with no happens-before edge between them. They overlap but aren't the same thing, and fixing one doesn't guarantee the other.

• Three separate problems hide under "race condition": atomicity, visibility, and ordering. volatile fixes two of them and not atomicity. This trips up everyone.

• The fix is the narrowest correct tool: immutability/confinement → atomics → locks → concurrent collections. Blanket synchronized is correct but usually the wrong default.

The counter++ that loses count

Here's the classic broken counter:

class Counter {
    private int c = 0;

    public void increment() { c++; }
    public void decrement() { c--; }
    public int  value()     { return c; }
}

It looks innocent. The problem is that c++ isn't atomic — that single expression decomposes into three steps: read the current value of c, add 1 to the value you read, and store the result back into c.

Three steps means two threads can interleave them. Thread A reads 0. Before A stores, Thread B also reads 0. Both increment their local copy to 1. Both store 1. Two increments happened; the counter went up by one. One update was silently overwritten.

Run a million increments split across threads and you won't get a million. You'll get something smaller, something different each run. That non-determinism is the signature of the whole problem.

What a race condition actually is (and what a data race is)

"Race condition" and "data race" get used interchangeably. They're related, but the distinction pays off.

A race condition is a flaw where the timing or ordering of events affects whether the program produces the right answer. Your counter qualifies — it only gives the right total if the threads happen not to step on each other.

A data race is the memory-model definition, and it's narrower: two accesses to the same variable, at least one of them a write, that are not ordered by a happens-before relationship. That's it — same location, conflicting, unordered.

Here's the part worth tattooing somewhere: these are distinct, and neither implies the other. You can have a race condition with no data race — for instance, two threads each calling thread-safe methods on a shared object in an order that produces a wrong result. And you can eliminate every data race and still be incorrect, because data-race-freedom says nothing about whether your higher-level invariants hold.

So "I added volatile, no more data race" is not the same sentence as "my program is correct." Keep them separate in your head.

The everyday symptoms fall into two buckets: thread interference (the interleaving we just saw) and memory consistency errors, where different threads have inconsistent views of what should be the same data. Both trace back to the same root cause, which is the next section.

Why it happens: atomicity, visibility, ordering

Three different problems wear the same "race condition" costume. Telling them apart is the single most useful skill here, because each tool fixes a different subset.

Atomicity. A compound action that has to happen all-at-once-or-not-at-all. c++ is read-modify-write. if (x == null) x = new T() is check-then-act. If another thread can wedge itself into the middle, you lose. These compound actions must execute atomically to stay thread-safe.

Visibility. One thread writes a field; another thread never sees the new value — or sees it much later. Without synchronization there is no guarantee that a write in one thread becomes visible to a read in another. A thread that prints an unsynchronized counter another thread just set to 1 may legitimately print 0.

Ordering. The compiler and CPU are allowed to reorder operations as long as a single thread can't tell. Across threads, that freedom can expose half-finished state. The happens-before relationship is what constrains it: a guarantee that the memory writes of one statement are visible to another specific statement.

Now the misconception that causes the most bad code:

volatile fixes visibility and ordering. It does not fix atomicity.

A write to a volatile field happens-before every subsequent read of that field, so every read sees the most recent write — a volatile write behaves like a lock release and a volatile read like a lock acquire. That handles visibility and ordering completely.

But a volatile int does nothing for c++, because the read and the write are still two separate operations with a gap in between. Marking the counter volatile makes the staleness go away and leaves the lost-update bug intact. People declare a field volatile, watch one symptom vanish, and ship the other one to production.

The other classic: check-then-act and lazy init

The counter is read-modify-write. Its evil twin is check-then-act, and the textbook example is lazy initialization:

// Broken: two threads can both pass the null check
public Singleton getInstance() {
    if (instance == null) {            // check
        instance = new Singleton();    // act
    }
    return instance;
}

Two threads hit getInstance() at once, both see null, both construct a Singleton. The "single line" logical operation raced.

The infamous attempted fix is double-checked locking — check, lock, check again. Don't write it from memory, because the obvious version is broken. Without a volatile field, a second thread can observe a partially constructed object: the reference is published before the constructor's writes are visible, so the reader gets a non-null pointer to an object whose fields aren't there yet. Double-checked locking was broken before Java 5, and it's only correct now if the field is volatile.

The cleaner answer is to not write double-checked locking at all. For lazy initialization, use the initialization-on-demand holder idiom:

public class Singleton {
    private Singleton() {}

    private static class Holder {
        static final Singleton INSTANCE = new Singleton();
    }

    public static Singleton getInstance() {
        return Holder.INSTANCE;   // class init is thread-safe, lazy, lock-free on the hot path
    }
}

The JVM guarantees a class is initialized exactly once, lazily, the first time it's used — so the language hands you the correctness for free. No volatile to forget, no second check to get subtly wrong.

How do you even catch these?

Race conditions are miserable to detect because they're non-deterministic. They pass your unit tests. They pass them a thousand times. Then they show up under production load on a Tuesday. Ordinary tests can't prove the absence of a race — a green run just means this particular interleaving happened to work.

So lean on tooling that actually understands concurrency, in roughly three tiers.

Static analysis. SpotBugs (successor to FindBugs) inspects bytecode without running your code and ships a Multithreaded correctness category of bug patterns — inconsistent synchronization of a field, non-atomic sequences of calls on a concurrent collection, waiting without a guard, and similar. It's cheap to wire into CI and catches real mistakes, but like all static analysis it produces false positives, so read its findings rather than worship them.

Stress testing. When you're verifying an actual concurrency primitive — a lock-free queue, a tricky publish — use jcstress, the OpenJDK concurrency stress harness. It runs many threads that rendezvous on shared state, then tabulates which outcomes actually occurred, surfacing the rare interleavings ordinary tests never hit. This is the serious tool.

Dynamic detection. There's an OpenJDK JEP draft for a Java Thread Sanitizer — a runtime data-race detector for Java and JNI, in the spirit of C++'s ThreadSanitizer. Worth knowing it exists, but it's a draft proposal, not something the JDK ships today. Don't plan around it.

Fix #1 — synchronized, the blunt-but-honest instrument

synchronized does two things at once: it gives you mutual exclusion (only one thread in the guarded region at a time) and it establishes happens-before — an unlock on a monitor happens-before every subsequent lock on that same monitor. That's the whole package: atomicity, visibility, and ordering for the guarded region.

class Counter {
    private int c = 0;
    public synchronized void increment() { c++; }
    public synchronized void decrement() { c--; }
    public synchronized int  value()     { return c; }
}

This counter is correct. Two caveats, both load-bearing.

First, both threads must lock on the same monitor. A write under lock A and a read under lock B share no happens-before edge — you've paid for synchronization and gotten none of its guarantees. This is a depressingly common bug.

Second, synchronization introduces contention: threads pile up waiting on the same resource. Correct, but it serializes access, and if you wrap everything in one fat lock you've built a concurrent program that runs like a single-threaded one.

One forward-looking note for Java 21: a virtual thread that blocks inside a synchronized block gets pinned to its carrier thread. Pinning doesn't make code incorrect, but it can hinder scalability, so the guidance is to guard frequently-contended, long-running I/O with ReentrantLock instead of synchronized. (Short, in-memory critical sections are fine.)

synchronized is the right answer when you genuinely need a compound action to be atomic and the region is short. It's the wrong answer as a reflex applied to everything.

Fix #2 — Explicit locks when synchronized isn't enough

ReentrantLock gives you the same memory semantics as synchronized plus capabilities the keyword can't express: timed acquisition (tryLock(timeout)), interruptible locking, non-block-structured locking, and optional fairness. The price is that you own the unlock — and you must release it in a finally, or one exception leaks the lock forever:

private final ReentrantLock lock = new ReentrantLock();

public void update() {
    lock.lock();
    try {
        // critical section
    } finally {
        lock.unlock();   // non-negotiable
    }
}

For read-heavy data where reads vastly outnumber writes, a ReadWriteLock lets many readers proceed concurrently while writers get exclusive access. And StampedLock (Java 8+) adds an optimistic read mode: grab a stamp, read, then validate that no write happened meanwhile — fast when writes are rare, at the cost of more careful code.

Default to synchronized for simple, short critical sections — it's harder to misuse and the JVM optimizes it well. Reach for explicit locks when you specifically need one of their features: a timeout, interruptibility, or read/write separation.

Fix #3 — Atomics, for single-variable updates

For a lone counter or flag, you don't need a lock at all. The java.util.concurrent.atomic classes give you lock-free read-modify-write:

class AtomicCounter {
    private final AtomicInteger c = new AtomicInteger(0);
    public void increment() { c.incrementAndGet(); }
    public void decrement() { c.decrementAndGet(); }
    public int  value()     { return c.get(); }
}

incrementAndGet() performs the whole read-modify-write as one indivisible operation, so the lost-update bug is gone. Under the hood these use compare-and-set (CAS): read the current value, compute the new one, and swap it in only if the value hasn't changed — retrying if it has. No mutual exclusion, no blocking.

The memory semantics are first-class too: an atomic's get/set behave like reads and writes of a volatile field, so a set happens-before any subsequent get on the same variable. You get visibility without synchronization.

On performance, stay honest. Atomic-variable access is generally more efficient than synchronized access on modern hardware, and the advantage is strongest under low-to-moderate contention. Under heavy contention the CAS retry loop can thrash. So atomics are an excellent default for single-variable state, not a guaranteed speedup you can quote a multiplier for.

The catch is in the name — single variable. The moment two fields must change together atomically, a single atomic won't do it, and you're back to a lock (or a single atomic reference to an immutable holder object).

Fix #4 — Concurrent collections instead of wrapped ones

If your shared state is a map or a list, the common mistake is wrapping a plain collection (Collections.synchronizedMap) and then doing check-then-act on it:

// Still racy: two threads can both see the key missing, both put
if (!map.containsKey(key)) {
    map.put(key, compute(key));
}

Each individual call is synchronized, yet the sequence races — exactly the "thread-safe building blocks, unsafe combination" trap from earlier. A thread-safe collection doesn't make your compound action thread-safe.

Purpose-built concurrent collections fix this by giving you the compound operation as a single atomic method:

map.putIfAbsent(key, compute(key));      // atomic check-then-act
map.computeIfAbsent(key, this::compute); // atomic, computes only if absent

ConcurrentHashMap, CopyOnWriteArrayList, and the BlockingQueue implementations are built for concurrent access and expose atomic compound operations like putIfAbsent, compute, and merge. A ConcurrentHashMap also scales better under concurrent writes than a fully synchronized wrapper, because it doesn't hold one lock over the entire map — though the real speedup depends entirely on your access pattern, so don't reach for a fixed number.

The rule: if multiple threads touch a collection, use a collection designed for it, and use its atomic methods rather than rolling your own check-then-act on top.

Fix #5 — The cheapest fix: no shared mutable state

Every fix so far manages access to shared mutable state. The best move is often to not have any.

Immutable objects are inherently thread-safe. There are no writes to race on — once constructed, the object never changes, so every thread sees the same consistent value. Java's record types make this nearly free for data carriers.

The memory model even gives immutable objects a special guarantee. When an object is properly constructed — meaning its this reference doesn't escape during the constructor — the values assigned to its final fields are visible to all other threads without synchronization. Build it once with final fields, publish it safely, and readers see it correctly with zero locking.

One sharp edge: final guarantees the reference won't change, not that what it points to is immutable. A final List<String> whose contents you keep mutating is still shared mutable state and still races. Deep immutability means immutable all the way down (or an unmodifiable copy).

When the data has to be mutable, the other escape hatch is confinement — don't share it at all. ThreadLocal gives each thread its own copy; stack confinement (a local variable never handed to another thread) is even simpler and race-proof by construction. No sharing, no race.

Which tool, when — the decision guide

Top to bottom, stop at the first match.

1. Can you avoid sharing mutable state? Make it immutable, or confine it to one thread. Cheapest correct fix; no synchronization to get wrong.

2. Is it a single variable (counter, flag, reference)? Use an Atomic* class. Lock-free, simple, fast under normal contention.

3. Is it a shared collection? Use a concurrent collection and its atomic compound methods (computeIfAbsent, putIfAbsent, merge).

4. Do you need a compound action across multiple fields to be atomic? Use synchronized for short, simple regions; ReentrantLock/ReadWriteLock/StampedLock when you need timeouts, interruptibility, or read/write separation.

The principle underneath all four: reach for the narrowest correct tool. Wrapping everything in synchronized is correct, and it's also how you build a program that's slow and hides its design problems behind a lock. The narrow tool both performs better and forces you to understand what state is actually shared — which is the real win.

A race-condition review checklist

Steal this for code review:

• Is there a field written by one thread and read by another? If so, what creates the happens-before edge between them? If you can't name it, it's a data race.

• Does a "single" operation actually decompose into read-modify-write or check-then-act? Those need to be atomic.

• Are all accesses to a guarded field using the same lock/monitor?

• Did you reach for volatile to fix something that's actually an atomicity problem? (It won't.)

• Is there a final reference to a mutable object you keep mutating? That's still shared mutable state.

• For a shared collection: are you doing check-then-act on it instead of using an atomic method like computeIfAbsent?

• Could this just be immutable or thread-confined and dodge the whole question?

The mental model that ties it together: a race condition is a missing happens-before relationship. Every tool here — atomics, locks, concurrent collections, safe publication of immutable objects — is just a different way to create that relationship. Pick the cheapest one that does the job, name why it works, and move on.

Sources

• Oracle — The Java Tutorials, Concurrency lesson (thread interference, memory consistency, synchronization, atomic variables): https://docs.oracle.com/javase/tutorial/essential/concurrency/

• Oracle — The Java Language Specification, Java SE 21, Chapter 17 (Threads and Locks): https://docs.oracle.com/javase/specs/jls/se21/html/jls-17.html

• Oracle — Java SE 21 Core Libraries: Concurrency & Virtual Threads: https://docs.oracle.com/en/java/javase/21/core/concurrency.html

• JSR-133 (Java Memory Model) FAQ — Manson & Goetz: https://www.cs.umd.edu/~pugh/java/memoryModel/jsr-133-faq.html

• Java Concurrency in Practice — Goetz et al.: https://jcip.net/

• John Regehr — "Race Condition vs. Data Race": https://blog.regehr.org/archives/490

• OpenJDK jcstress (concurrency stress harness): https://github.com/openjdk/jcstress

• SpotBugs — bug descriptions (Multithreaded correctness): https://spotbugs.readthedocs.io/en/latest/bugDescriptions.html

• OpenJDK — JEP draft: Java Thread Sanitizer: https://openjdk.org/jeps/8208520