Race Conditions and Synchronization

A counter that loses count

This program looks obviously correct and is not:

class Counter {
    private int count = 0;

    void increment() {
        count++;
    }

    int get() { return count; }
}

Counter counter = new Counter();

Thread a = new Thread(() -> { for (int i = 0; i < 100_000; i++) counter.increment(); });
Thread b = new Thread(() -> { for (int i = 0; i < 100_000; i++) counter.increment(); });

a.start(); b.start();
a.join();  b.join();

System.out.println(counter.get());     // expected 200000 — usually less

Run it and you get some number below 200,000, different each time.

Why

count++ is not one operation. It is three:

1. Read the current value
2. Add one
3. Write the result back

Two threads can interleave between those steps:

thread A reads count  -> 5
thread B reads count  -> 5
thread A computes 6, writes -> 6
thread B computes 6, writes -> 6

Two increments happened; the count rose by one. The update from A was overwritten.

This is a race condition: the result depends on the timing of threads, and that timing is not under your control.

synchronized

Marking a method synchronized means only one thread may be inside it at a time, for a given object:

class Counter {
    private int count = 0;

    synchronized void increment() {
        count++;
    }

    synchronized int get() { return count; }
}

Now the total is 200,000 every time.

Every Java object has an intrinsic lock. A synchronized instance method acquires that object’s lock on entry and releases it on exit — including when an exception is thrown.

get() must be synchronized too. Locking only the writer still leaves readers able to see a stale or half-written value. Both sides of shared state need protection.

You can also lock a smaller region:

class Tracker {
    private final Object lock = new Object();
    private int count = 0;

    void record() {
        expensiveWorkNeedingNoLock();

        synchronized (lock) {         // only this part is protected
            count++;
        }
    }
}

Holding a lock for less time lets more work proceed in parallel. Using a dedicated private lock object — rather than this — also prevents outside code from locking on your object and interfering.

volatile

volatile solves a different problem: visibility, not atomicity.

Without it, one thread’s write may never become visible to another. The compiler and processor are allowed to cache values in registers, so this loop can run forever even after running becomes false:

class Worker {
    private boolean running = true;         // BUG: not volatile

    void stop() { running = false; }

    void run() {
        while (running) {                   // may never see the change
            doWork();
        }
    }
}

Adding volatile forces reads and writes to go to main memory:

private volatile boolean running = true;

private volatile int count = 0;

void increment() {
    count++;                       // STILL a race condition
}

Atomic types

For counters and similar, java.util.concurrent.atomic is simpler and faster than locking:

import java.util.concurrent.atomic.AtomicInteger;

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

    void increment() { count.incrementAndGet(); }
    int get()        { return count.get(); }
}

incrementAndGet performs the whole read-modify-write as one indivisible step, using a processor instruction rather than a lock.

Choosing a tool

Deadlock

Locks introduce a failure of their own. Two threads each holding a lock the other wants will both wait forever:

// thread A
synchronized (lockOne) {
    synchronized (lockTwo) { ... }
}

// thread B
synchronized (lockTwo) {          // opposite order — deadlock risk
    synchronized (lockOne) { ... }
}

Neither can proceed. The program does not crash; it simply stops.

The better approach

Locks are a way to make shared mutable state safe. The alternative is to not share mutable state.

Why these bugs are so unpleasant

A race condition may appear in one run in ten thousand, vanish under a debugger, and behave differently on another machine. Tests passing does not mean the code is correct — only that the bad interleaving did not occur this time.

That is why the design-level advice above matters more than the locking mechanics. Code with nothing shared cannot race.

Next

Related