Synchronization: interview questions & scenarios

Model answer

A race condition is a bug where the result depends on the timing of threads, and nobody controls that timing. Run the code a thousand times and it's right 999 times. That's what makes it nasty.

Picture two cashiers sharing one paper ledger. Both read "100", both add their own sale, both write their answer back. One sale vanishes. Nobody did anything wrong on their own; the order of their steps did the damage.

Almost every race you'll meet in Java is one of two shapes:

// check-then-act on a bank account
if (account.balance >= 100) {      // thread A checks: 150, fine
                                   // thread B checks: 150, fine
    account.balance -= 100;        // A: 50
}                                  // B: -50. Overdrawn.

The fix is always the same idea: make the check and the act (or the read and the write) one indivisible step, with synchronized, a Lock, or an atomic operation that does both at once.

Model answer

public class LostUpdates {
    static int count = 0;

    public static void main(String[] args) throws InterruptedException {
        Runnable work = () -> {
            for (int i = 0; i < 1_000_000; i++) count++;
        };
        Thread a = new Thread(work);
        Thread b = new Thread(work);
        a.start(); b.start();
        a.join();  b.join();
        System.out.println("expected 2000000, got " + count);
    }
}

Five real runs on Java 21 (java LostUpdates.java, 14-core laptop):

expected 2000000, got 1026781
expected 2000000, got 1017385
expected 2000000, got 1016983
expected 2000000, got 1024829
expected 2000000, got 1012349

The honest answer to "what does it print?" is "some number up to 2,000,000, different every run". Here almost half the increments vanished. On another machine you might lose 5% or 60%. On a rare run you could even get exactly 2,000,000.

Why? count++ looks like one step, but it's three. Here's the real bytecode from javap -c:

getstatic     #28    // Field count:I    (1. read count)
iconst_1
iadd                                      (2. add one)
putstatic     #28    // Field count:I    (3. write it back)

If thread A reads 41 and thread B reads 41 before either writes, both write 42. Two increments, one result. That's a lost update.

Three fixes, simplest first:

static final AtomicInteger count = new AtomicInteger();   // count.incrementAndGet()
static synchronized void inc() { count++; }               // a lock around all three steps
static final LongAdder hits = new LongAdder();            // hits.increment(), best under heavy contention