Race Conditions & synchronized

#Introduction

When two threads read and write the same mutable data without coordination, the result depends on the exact timing of their steps — a race condition. This chapter shows how races happen, why even count++ is unsafe, and how the synchronized keyword fixes them.

#A Race Condition in Action

class Counter {
    private int count = 0;

    public void increment() {
        count++;
    }

    public int getCount() {
        return count;
    }
}

public class Main {
    public static void main(String[] args) throws InterruptedException {
        Counter counter = new Counter();

        Runnable task = () -> {
            for (int i = 0; i < 100_000; i++) {
                counter.increment();
            }
        };

        Thread t1 = new Thread(task);
        Thread t2 = new Thread(task);
        t1.start();
        t2.start();
        t1.join();
        t2.join();

        System.out.println(counter.getCount());
    }
}

137492

The result changes from run to run and is almost never 200,000.

#Why count++ Is Not Atomic

count++ looks like one operation but is really three:

When two threads interleave these steps, one update is lost:

This pattern is called read-modify-write. The other classic race pattern is check-then-act:

// Check-then-act race: two threads can both see "not present" and both insert
if (!cache.containsKey(key)) {
    cache.put(key, loadValue(key));
}

#Key Terms

#The synchronized Keyword

Every Java object has an intrinsic lock (also called a monitor). synchronized makes a thread acquire that lock before entering a block of code, and release it when leaving — giving mutual exclusion and memory visibility.

synchronized Methods

class Counter {
    private int count = 0;

    public synchronized void increment() {   // locks on 'this'
        count++;
    }

    public synchronized int getCount() {     // reads must be synchronized too
        return count;
    }
}

Now the program always prints 200000.

synchronized Blocks

Lock only the part that needs it, which keeps the critical section short:

public void placeOrder(Order order) {
    validate(order);                 // no shared state — runs concurrently

    synchronized (this) {            // critical section
        inventory.reserve(order);
        orderCount++;
    }

    sendConfirmationEmail(order);    // slow I/O outside the lock
}

Using a Private Lock Object

class Inventory {
    private final Object lock = new Object();
    private int stock;

    public void reserve(int qty) {
        synchronized (lock) {
            if (stock < qty) throw new IllegalStateException("Out of stock");
            stock -= qty;
        }
    }
}

A private final lock can't be locked by outside code, so no other class can accidentally (or maliciously) hold your lock and stall you. synchronized (this) and synchronized methods use a lock that any caller holding a reference can also grab.

#Object Locks vs Class Locks

class IdGenerator {
    private static long nextId = 1;

    public static synchronized long next() {   // locks IdGenerator.class
        return nextId++;
    }
}

#Rules of synchronized

• Only one thread at a time can hold a given object's lock; others block (BLOCKED state).
• Threads synchronizing on different objects don't block each other — every thread must lock the same object to protect the same data.
• The lock is released when the block exits normally or by an exception.
• You can't synchronize on a primitive, and synchronized (null) throws NullPointerException.
• Constructors can't be synchronized (and don't need to be — the object isn't shared yet, unless this escapes).

Don't Synchronize on These

synchronized ("LOCK") { }          // ❌ string literals are interned and shared JVM-wide
synchronized (Integer.valueOf(1))  // ❌ boxed values are cached and shared
synchronized (count) { count++; }  // ❌ reassigning the field changes the lock object

#Reentrancy

Intrinsic locks are reentrant — a thread that already holds a lock can acquire it again:

class Account {
    public synchronized void transfer(Account to, int amount) {
        withdraw(amount);    // also synchronized on 'this' — no self-deadlock
        to.deposit(amount);
    }

    public synchronized void withdraw(int amount) { ... }
    public synchronized void deposit(int amount) { ... }
}

The JVM keeps a hold count per lock; the lock is released only when the count returns to zero. Without reentrancy, a synchronized method calling another synchronized method on the same object would deadlock itself. (transfer locking two accounts can still deadlock with another thread — see the deadlock chapter.)

#Compound Actions Need One Lock

Making each method of a class thread-safe doesn't make sequences of calls atomic:

List<String> list = Collections.synchronizedList(new ArrayList<>());

// ❌ Each call is synchronized, but the check-then-act sequence is not
if (!list.contains("x")) {
    list.add("x");
}

// ✅ Hold the same lock for the whole compound action
synchronized (list) {
    if (!list.contains("x")) {
        list.add("x");
    }
}

Iterating a synchronized collection also requires holding its lock for the entire loop.

#Race Conditions in Spring Applications

Spring beans are singletons by default — one instance shared by every request thread:

@Service
public class ReportService {

    private int processedCount;                         // ❌ shared by all requests
    private final SimpleDateFormat format =
            new SimpleDateFormat("yyyy-MM-dd");         // ❌ not thread-safe

    public String generate(Report r) {
        processedCount++;                               // lost updates under load
        return format.format(r.getDate());              // corrupted output
    }
}

Fixes:

• Keep services stateless — use local variables and method parameters.
• Use thread-safe types: AtomicInteger for counters, DateTimeFormatter (immutable) instead of SimpleDateFormat.
• For data shared across instances of your service (several pods), an in-memory lock is useless — use the database (row locks, optimistic locking with @Version) or a distributed lock.

#Cost of synchronized

Uncontended synchronized is cheap on modern JVMs. The cost is contention: when many threads want the same lock, they queue up and the critical section becomes a bottleneck. Keep critical sections short, never do I/O or remote calls inside them, and consider finer-grained locks, ReentrantReadWriteLock, atomics or concurrent collections for hot paths.

#Key Takeaways

• A race condition happens when threads interleave on shared mutable state — typically read-modify-write or check-then-act.
• count++ is three steps and isn't atomic.
• synchronized provides mutual exclusion and visibility using an object's intrinsic lock.
• Instance methods lock this, static methods lock the Class object — they're different locks.
• Intrinsic locks are reentrant.
• Compound actions need one lock around the whole sequence.