Atomic classes

For this lesson, we'll start from the bug that makes atomics necessary, meet the family, learn the handful of methods you'll use every week, and then hit the two traps that catch experienced engineers: compound actions across two atomics, and "check, then act" on one. Interviewers like this topic because the first answer ("use AtomicInteger") is easy, and the follow-up ("so is this class thread-safe now?") is where they find out whether you understand what "atomic" actually covers.

01Picture it first: a ticket dispenser at the deli

Picture a busy deli counter. Version one: the next number is written on a paper sign. Asha reads "41", Ben reads "41" a moment later, both add one, both write "42" on the sign and both think they're next. One turn just vanished. That's count++ on a plain int: read, add, write, with a gap between each step where someone else can sneak in.

Version two: a red ticket dispenser. You pull, you get a number, and the dispenser advances, all in one motion. Three customers pull and get 42, 43 and 44. Nobody can grab "half a pull". That's an atomic class.

Here's the thing to hold on to: the dispenser protects one number. If the deli also keeps a separate "customers served today" tally on a whiteboard, the dispenser does nothing for that. Keep that in mind; it's the big trap later in the lesson.

02Quick recap: why count++ loses updates

We covered this properly in Race conditions, so here's the short version. count++ compiles to three bytecode-level steps: read the field, add one, write it back. If thread A and thread B both read 5 before either writes, both write 6. Two increments, one recorded.

Marking the field volatile doesn't change that. volatile makes each read and write visible to other threads and stops reordering around it, but read-add-write is still three separate steps. Let's prove it.

import java.util.concurrent.atomic.AtomicInteger;

public class CounterRace {
    static int plain = 0;
    static volatile int vol = 0;
    static final AtomicInteger atomic = new AtomicInteger();

    public static void main(String[] args) throws Exception {
        int threads = 32, perThread = 100_000;
        Thread[] ts = new Thread[threads];
        for (int i = 0; i < threads; i++) {
            ts[i] = new Thread(() -> {
                for (int j = 0; j < perThread; j++) {
                    plain++;                    // read, add, write: three steps
                    vol++;                      // still three steps, just visible ones
                    atomic.incrementAndGet();   // one indivisible step
                }
            });
            ts[i].start();
        }
        for (Thread t : ts) t.join();
        int expected = threads * perThread;
        System.out.printf("expected       %,d%n", expected);
        System.out.printf("int            %,d  (lost %,d)%n", plain, expected - plain);
        System.out.printf("volatile int   %,d  (lost %,d)%n", vol, expected - vol);
        System.out.printf("AtomicInteger  %,d  (lost %,d)%n", atomic.get(), expected - atomic.get());
    }
}

Two real runs of java CounterRace.java on JDK 26, Apple M4 Pro (14 cores). The lost counts change every run; the atomic line never does.

expected       3,200,000
int            279,172  (lost 2,920,828)
volatile int   650,280  (lost 2,549,720)
AtomicInteger  3,200,000  (lost 0)
---
expected       3,200,000
int            461,576  (lost 2,738,424)
volatile int   664,863  (lost 2,535,137)
AtomicInteger  3,200,000  (lost 0)

Notice three things:

1. The plain int lost over 85% of the increments. With 32 threads hammering one field, the read-add-write gap is hit constantly. (The JIT may also keep plain in a register for a while, which makes it worse.)
2. volatile lost almost as much. Visibility isn't atomicity. If this surprises you, you're in good company; it's the most common wrong answer to this question.
3. AtomicInteger was exact, every run, with no lock anywhere in the code.

03How it works: compare, then swap

So how does AtomicInteger add one without a lock? The core idea is compare-and-swap (CAS): one CPU instruction that says "if this memory location still holds 5, put 6 there; otherwise, tell me I lost". It's like the deli clerk saying "I'll serve number 42, but only if nobody's already called 42".

If you lose, nothing is written. You re-read the new value and try again. Nobody ever waits holding a lock, which is why we call these classes lock-free: some thread always makes progress. Here are both versions side by side.

The right side is the mental model, and it's exactly how updateAndGet works. For plain counting, HotSpot goes one better: incrementAndGet and getAndAdd are JIT intrinsics that become a single hardware fetch-and-add (LOCK XADD on x86, LDADDAL on ARMv8.1+), so there isn't even a retry loop. CAS itself, the ABA problem and the retry cost get their own lesson: Compare-and-swap and the ABA problem.

04Meet the family

The package is small. Here's what's in it and when you'd reach for each.

Underneath, since Java 9, the public foundation is VarHandle (java.lang.invoke). A VarHandle is a typed handle to a field or array slot that lets you do the same atomic operations (compareAndSet, getAndAdd, getAcquire, setRelease...) on any field, without a wrapper object. It replaced the internal sun.misc.Unsafe tricks library authors used to rely on (JEP 193). The atomic classes' Javadoc now defines every method's memory effect in VarHandle terms; AtomicReference and the arrays use VarHandles directly, while AtomicInteger and AtomicLong still call the JDK-internal Unsafe for bootstrapping reasons. You'll rarely need VarHandle in application code, but it's good to know they're two faces of the same machinery.

import java.lang.invoke.MethodHandles;
import java.lang.invoke.VarHandle;

class Hits {
    private volatile long count;                    // a plain field, no AtomicLong object
    private static final VarHandle COUNT;
    static {
        try { COUNT = MethodHandles.lookup().findVarHandle(Hits.class, "count", long.class); }
        catch (ReflectiveOperationException e) { throw new ExceptionInInitializerError(e); }
    }
    long hit() { return (long) COUNT.getAndAdd(this, 1L) + 1; }   // same effect as incrementAndGet()
}

05The core API, in one sitting

You'll use about eight methods. Here's the one rule that makes the names easy: the word order tells you which value comes back. getAndIncrement gets, then increments, so it returns the old value (like i++). incrementAndGet increments, then gets, so it returns the new value (like ++i).

import java.util.concurrent.atomic.AtomicInteger;

public class AtomicTour {
    public static void main(String[] args) {
        AtomicInteger ticket = new AtomicInteger(41);

        System.out.println("getAndIncrement() returned " + ticket.getAndIncrement() + ", now " + ticket.get());
        System.out.println("incrementAndGet() returned " + ticket.incrementAndGet() + ", now " + ticket.get());

        boolean ok = ticket.compareAndSet(43, 100);   // expect 43: it is 43, so swap
        System.out.println("compareAndSet(43, 100) -> " + ok + ", now " + ticket.get());
        ok = ticket.compareAndSet(43, 200);           // expect 43: it is 100, so refuse
        System.out.println("compareAndSet(43, 200) -> " + ok + ", now " + ticket.get());

        System.out.println("updateAndGet(x -> x * 2) -> " + ticket.updateAndGet(x -> x * 2));
        System.out.println("accumulateAndGet(5, Math::max) -> " + ticket.accumulateAndGet(5, Math::max));
        System.out.println("getAndSet(0) returned " + ticket.getAndSet(0) + ", now " + ticket.get());
    }
}

getAndIncrement() returned 41, now 42
incrementAndGet() returned 43, now 43
compareAndSet(43, 100) -> true, now 100
compareAndSet(43, 200) -> false, now 100
updateAndGet(x -> x * 2) -> 200
accumulateAndGet(5, Math::max) -> 200
getAndSet(0) returned 200, now 0

Here's the whole API on one card:

That "like a volatile" column matters. An AtomicReference.set(config) publishes the object: a thread that later get()s it sees the fully built config, for the same happens-before reasons as a volatile write.

06The function may run more than once

updateAndGet(fn) is a loop: read the current value, call fn, try compareAndSet(old, fn(old)), and if another thread got there first, call fn again. The Javadoc says it directly: the function "should be side-effect-free, since it may be re-applied when attempted updates fail due to contention among threads".

Let's count how often that happens. This program deliberately breaks the rule by counting calls inside the lambda.

import java.util.concurrent.atomic.AtomicInteger;
import java.util.concurrent.atomic.AtomicLong;

public class RetryCount {
    public static void main(String[] args) throws Exception {
        AtomicLong total = new AtomicLong();
        AtomicInteger calls = new AtomicInteger();   // how many times our lambda ran
        int threads = 8, perThread = 100_000;
        Thread[] ts = new Thread[threads];
        for (int i = 0; i < threads; i++) {
            ts[i] = new Thread(() -> {
                for (int j = 0; j < perThread; j++) {
                    total.updateAndGet(x -> {
                        calls.incrementAndGet();      // a side effect: exactly what you should NOT do
                        return x + 1;
                    });
                }
            });
            ts[i].start();
        }
        for (Thread t : ts) t.join();
        System.out.printf("updates applied  %,d%n", total.get());
        System.out.printf("lambda calls     %,d  (%,d re-runs)%n", calls.get(), calls.get() - total.get());
    }
}

updates applied  800,000
lambda calls     3,753,540  (2,953,540 re-runs)

800,000 updates, almost 3.8 million lambda calls on this run (another run gave 4.2 million). The sum is still exact, which is the point of CAS. But if that lambda had sent an email, logged an audit line or charged a card, it would have done so almost five times per update. Keep the function pure: compute a new value from the old one, nothing else.

07The big trap: two atomics are not one atomic

This is the bit that trips up people who already "know" atomics. Each atomic makes one variable safe. The moment correctness depends on two variables agreeing, you're back to a race, even if both are atomic.

Here's a real bug shape. Two wallets, Alice and Bob, start with 500 each. A mover thread shifts 10 back and forth, so the total should always be 1,000. An auditor thread keeps checking.

import java.util.concurrent.atomic.AtomicLong;
import java.util.concurrent.atomic.AtomicReference;

public class TwoAtomics {
    // Two wallets. Money only moves between them, so the total must always be 1,000.
    static final AtomicLong alice = new AtomicLong(500);
    static final AtomicLong bob = new AtomicLong(500);

    record Wallets(long alice, long bob) { }
    static final AtomicReference<Wallets> both = new AtomicReference<>(new Wallets(500, 500));

    public static void main(String[] args) throws Exception {
        long deadline = System.nanoTime() + 1_000_000_000L;      // run for 1 second

        Thread mover = new Thread(() -> {
            while (System.nanoTime() < deadline) {
                alice.addAndGet(-10); bob.addAndGet(10);          // each step atomic, the pair is not
                bob.addAndGet(-10);   alice.addAndGet(10);
                both.updateAndGet(w -> new Wallets(w.alice() - 10, w.bob() + 10));
                both.updateAndGet(w -> new Wallets(w.alice() + 10, w.bob() - 10));
            }
        });
        mover.start();

        long checks = 0, badTwo = 0, badOne = 0, example = 1_000;
        while (mover.isAlive()) {
            checks++;
            long total = alice.get() + bob.get();
            if (total != 1_000) { badTwo++; example = total; }
            Wallets w = both.get();
            if (w.alice() + w.bob() != 1_000) badOne++;
        }
        System.out.printf("audits run                  %,d%n", checks);
        System.out.printf("two AtomicLongs, wrong      %,d  (e.g. total = %d)%n", badTwo, example);
        System.out.printf("one AtomicReference, wrong  %,d%n", badOne);
    }
}

audits run                  153,978,859
two AtomicLongs, wrong      5,129,948  (e.g. total = 990)
one AtomicReference, wrong  0

Over 5 million bad audits in one second (other runs: 6.5 and 7.0 million, sometimes showing 1,010). Notice the fix: we didn't add a lock. We made the two numbers one value, an immutable Wallets record, and swapped the whole thing with one CAS. That's the go-to pattern when the state is small. When it isn't, or when you also need to wait for a condition, use synchronized (see synchronized and monitors).

The same trap hides inside a single atomic too: check-then-act. if (sold.get() < 100) sold.incrementAndGet(); reads, decides, then writes, as two separate atomic calls. With 32 threads released at once through a CountDownLatch, three of my five runs sold 101 seats out of 100. Rewriting it as sold.getAndUpdate(n -> n < 100 ? n + 1 : n) puts the check inside the CAS, and every run sold exactly 100.

08Counting page views: grow the answer

Let's solve a real one the way you'd grow into it in an interview: 32 request threads each record page views, and a dashboard reads the total every few seconds.

The harness behind those numbers is small: start 32 threads, each calls one of these a million times, join, time it, and repeat once so the JIT has warmed up. Timings vary a lot by CPU and JVM; treat them as a shape, not a benchmark (use JMH for real numbers).

Runnable viaLock   = () -> { synchronized (lock) { syncCount++; } };
Runnable viaAtomic = atomic::incrementAndGet;   // AtomicLong
Runnable viaAdder  = adder::increment;          // LongAdder

One run, second round. Across three runs AtomicLong ranged from 766 to 1,446 ms and LongAdder from 17 to 21 ms.

synchronized  32,000,000 views in  924 ms
AtomicLong    32,000,000 views in  766 ms
LongAdder     32,000,000 views in   21 ms

09Real world

10Advanced: memory modes, intrinsics and edge cases

Memory modes. Since Java 9 every atomic class exposes the VarHandle access modes: plain (getPlain/setPlain), opaque, acquire/release (getAcquire/setRelease) and volatile (get/set). lazySet is the old name for setRelease: writes before it can't move after it, but a later volatile read in the same thread may be reordered before it, so it skips the expensive store-load fence on x86. It's useful for "I'm the only writer and readers can see it a few nanoseconds late", like clearing a slot in a single-producer queue. Doug Lea's "Using JDK 9 Memory Order Modes" is the reference.

Weak CAS. weakCompareAndSetPlain / weakCompareAndSetVolatile may fail spuriously (return false even when the value matched). On ARM, which implements CAS with load-linked / store-conditional pairs, that can be cheaper inside a retry loop. The old weakCompareAndSet was deprecated in Java 9 because its name hid that it had plain memory semantics.

Hardware. On x86, compareAndSet becomes LOCK CMPXCHG and getAndAdd becomes LOCK XADD, both full fences. On ARMv8.1+ with LSE (my M4 reports UseLSE = true), HotSpot emits CASAL and LDADDAL; older ARM uses LDAXR/STLXR loops. "Lock-free" means no Java lock and no blocking. It does not mean free: a contended atomic still costs a cache-line transfer between cores on every write.

False sharing. Two hot AtomicLongs allocated next to each other can share a 64-byte cache line, so threads updating different counters still slow each other down. LongAdder's cells are padded with @jdk.internal.vm.annotation.Contended (JEP 142) for exactly this reason.

11How to say it in the interview

When I ask about atomics, I'm listening for three things. First, can you say why count++ fails and why volatile alone doesn't fix it? Second, do you know atomics cover one variable, and can you spot the multi-variable or check-then-act bug? Third, do you know the trade-off between AtomicLong, LongAdder and a lock, with a reason rather than "atomics are faster"?