What Is a Race Condition in Java?

A race condition is when the correctness of a program depends on the relative timing of two or more threads. The result changes from run to run because the interleaving of the operations changes, and there is no synchronisation that forces one order over another.

The classic shape is a read-modify-write on shared state. Two threads both read a counter, both add one, and both write it back — one increment is lost. Neither thread did anything wrong on its own; the problem is that the three steps were not atomic together.

Why they are so hard to reproduce is worth understanding, because it changes how you test for them. The interleaving that triggers the bug may only happen once in a million runs, so a passing test suite tells you almost nothing. The bug may only appear on a machine with several cores, so a developer on a laptop may never see it while production fails regularly. And the symptom appears far from the cause: a lost increment shows up as a slightly wrong total hours later, and a corrupted collection shows up as an exception in an unrelated part of the program.

Two things make it worse. The Java Memory Model allows the JIT compiler to reorder operations and the CPU to cache writes, so a thread can observe a stale value even when the code looks as if it is in the right order. And a bug that only manifests under load will often be blamed on the load rather than on the code.

The practical consequence is that you should not try to reproduce a suspected race by running the test repeatedly. Instead, reason about which shared state is unguarded, and fix it by construction.

The demonstration is a plain counter incremented from two threads. If the counter is not protected, the final value is frequently lower than the expected total, because the increments interleave. Note that the failure is probabilistic — on a single-core machine it may well produce the right answer, which is precisely the point.

import java.util.concurrent.atomic.AtomicInteger;

public class Main {
    public static void main(String[] args) throws InterruptedException {
        UnsafeCounter unsafe = new UnsafeCounter();
        AtomicCounter safe = new AtomicCounter();

        Thread t1 = new Thread(() -> {
            for (int i = 0; i < 100_000; i++) {
                unsafe.increment();
                safe.increment();
            }
        });
        Thread t2 = new Thread(() -> {
            for (int i = 0; i < 100_000; i++) {
                unsafe.increment();
                safe.increment();
            }
        });

        t1.start();
        t2.start();
        t1.join();
        t2.join();

        System.out.println("unsafe count : " + unsafe.value() + " (expected 200000)");
        System.out.println("safe count   : " + safe.value() + " (expected 200000)");
    }
}

class UnsafeCounter {
    private int count;

    void increment() {
        count = count + 1;   // read, add, write - not atomic
    }

    int value() {
        return count;
    }
}

class AtomicCounter {
    private final AtomicInteger count = new AtomicInteger();

    void increment() {
        count.incrementAndGet();
    }

    int value() {
        return count.get();
    }
}

The output shows the difference. The atomic counter always reaches exactly 200000, because every increment is a single atomic operation. The unsafe counter frequently ends up below that, because some increments were lost — though on a single-core machine it may well reach the right total, which is exactly what makes this bug so elusive.

How to fix it, roughly in order of preference. Remove the shared state. If each thread has its own accumulator and you combine them at the end, there is no race at all — this is what the stream reduce and the ForkJoin framework do. Use an atomic class for a single value, an AtomicInteger or an AtomicReference, which gives you a lock-free but correct update. Use a lock when you need to protect several fields consistently, and remember to hold it only for the critical section. And use the concurrent collections rather than the ordinary ones when you share a collection.

The Java Memory Model is the specification of when a write by one thread is guaranteed to be visible to another. It exists because modern CPUs reorder instructions and cache writes, so the source order of your code is not the order the hardware executes it in. Without a model, every concurrent program would be ambiguous.

The model is defined in terms of happens-before edges. If action A happens-before action B, then A is visible to B and the two are not reordered. Most of the time you never write happens-before explicitly — you get it from the concurrency primitives. A write to a volatile field happens-before every subsequent read of that field. Unlocking a monitor happens-before every subsequent lock of the same monitor. Writing to a final field before a constructor finishes happens-before any read of that field after the object is published. And the actions in a thread happen-before any other action in that same thread, which is called program order.

import java.util.concurrent.CountDownLatch;

public class Main {
    public static void main(String[] args) throws InterruptedException {
        // The latch creates a happens-before edge: everything the writer did
        // before countDown is visible to the reader after await.
        Data data = new Data();
        CountDownLatch ready = new CountDownLatch(1);
        CountDownLatch go = new CountDownLatch(1);

        Thread reader = new Thread(() -> {
            ready.countDown();
            try {
                go.await();
            } catch (InterruptedException e) {
                Thread.currentThread().interrupt();
            }
            System.out.println("reader sees    : " + data.value);
        });
        reader.start();

        ready.await();
        data.value = 42;
        go.countDown();
        reader.join();
        System.out.println("writer wrote   : 42");
    }
}

class Data {
    int value;    // a plain field, made visible by the latch
}

The output shows the reader seeing 42. The field is a plain int with no volatile and no lock, yet the value is visible — because the latch establishes a happens-before edge between the writer's assignment and the reader's read.

Without such an edge the behaviour is not defined: the reader might see 42, might see 0, or might see a partially constructed object. That last case is why safe publication matters so much. If one thread publishes an object before its constructor has finished, another thread can see the fields in whatever order the CPU felt like, and the object can be half-initialised.