Atomic operations and CAS: interview questions and how to answer them

What it actually is

An atomic operation is one that no other thread can observe half-completed. The hardware provides a small set: atomic load and store of a word, atomic exchange, fetch-and-add, and compare-and-swap. CAS takes an address, an expected value, and a new value; it writes the new value and reports success only if the memory still held the expected one. On x86 this is `LOCK CMPXCHG`; on ARM it is a load-linked/store-conditional pair.

Everything above it is composition. `AtomicInteger.incrementAndGet` is a loop: read the current value, compute value + 1, CAS; if the CAS fails because someone else moved it, read again and retry. The loop is what makes the operation *atomic in effect* even though it is not a single instruction — no thread ever observes an intermediate state, because a losing thread discards its work rather than publishing it.

This is where lock-free gets its guarantee. A lock-free algorithm guarantees that *some* thread makes progress at every step, because a failed CAS means someone else succeeded. It does not guarantee that a *given* thread makes progress — an unlucky thread can retry indefinitely, which is why lock-free is weaker than wait-free and why a CAS loop is not automatically fast.

Why it matters in production

Because it is the mechanism that removes blocking from hot paths without removing correctness. A counter behind a lock forces every incrementing thread through a context switch under contention; a CAS-based counter lets them all run and lets one win per round. At low to moderate contention that is dramatically faster, and it never parks a thread, so a thread killed or descheduled mid-operation cannot block anyone else — a property a lock cannot offer.

Because it is also the mechanism that inverts under high contention, and knowing where the crossover lies is what distinguishes experience from enthusiasm. Every CAS on a contended line invalidates that line in every other core's cache, so N threads hammering one `AtomicLong` spend their time bouncing a cache line between cores. Beyond a certain contention level a lock is faster, because parking threads reduces the traffic. `LongAdder` exists precisely because `AtomicLong` loses at high write contention.

And because CAS is the same idea as an optimistic database update, a conditional HTTP `If-Match`, and a Redis `WATCH`/`MULTI` transaction. A candidate who sees the pattern across those layers is the one who will design a conditional write correctly in a system that has no locks at all.

How it works

Implementing it

Use `AtomicInteger`/`AtomicLong` for counters and flags, and `LongAdder` when a counter is written by many threads and read rarely — metrics, request counts. The adder trades a cheap read for much cheaper writes.

Use `AtomicReference.updateAndGet` with an immutable value object to make multi-field state transitions atomic without a lock. Building a new immutable snapshot and CASing the reference is a clean pattern that avoids partially updated state entirely.

Bound CAS loops in code where the computation is expensive, and consider falling back to a lock after a few failures. A loop whose body costs microseconds is a livelock waiting to happen under contention.

Pad or separate hot atomics that share a cache line. Two unrelated counters in adjacent fields will contend through false sharing even though no thread touches both; `@Contended` or deliberate padding removes it.

// What incrementAndGet is doing underneath
int current, next;
do {
    current = value.get();
    next = current + 1;
} while (!value.compareAndSet(current, next));   // retry on a lost race

// Multi-field atomic transition without a lock: CAS an immutable snapshot
record State(long total, int count) {}
final AtomicReference<State> state = new AtomicReference<>(new State(0, 0));
void record(long v) {
    state.updateAndGet(s -> new State(s.total() + v, s.count() + 1));
}

// ABA-sensitive: compare a stamp alongside the reference
AtomicStampedReference<Node> head = new AtomicStampedReference<>(null, 0);
int[] stamp = new int[1];
Node h = head.get(stamp);
head.compareAndSet(h, h.next, stamp[0], stamp[0] + 1);

// Many writers, few readers: shard the cells instead of contending on one
final LongAdder requests = new LongAdder();
requests.increment();

Interview questions and how to answer them

Answers that lose the round

• Describing CAS as "a lock without blocking" — it is a conditional write, and the retry loop is the part that does the work
• Treating a failed CAS as an error to log or throw on, rather than as the normal signal to re-read and retry
• Computing the new value once and retrying the CAS with the same stale value, which either spins forever or writes a wrong result
• Claiming lock-free means faster; it means no thread can block another, and under heavy contention a lock often wins
• Assuming CAS solves ABA, or not knowing what ABA is when asked about a lock-free stack
• Using `AtomicLong` for a hot metric counter across dozens of threads instead of `LongAdder`, then blaming the JVM for the cache-line traffic
• Wrapping two atomic operations in sequence and calling the pair atomic

FAQ

Related

More backend concepts

• ACID transactions
• Transaction isolation levels
• Read committed vs repeatable read
• Serializable isolation
• MVCC
• Write-ahead logging
• Two-phase commit
• Saga pattern