Atomic Variables & Compare-and-Swap

#Introduction

Locking a whole block just to increment a counter is heavy. The java.util.concurrent.atomic package provides classes whose operations are atomic without locks, built on a CPU instruction called compare-and-swap (CAS). They're the go-to tool for counters, sequence numbers, flags and single-reference state.

#The Counter, Fixed with AtomicInteger

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

    public void increment() {
        count.incrementAndGet();    // atomic — no lost updates
    }

    public int getCount() {
        return count.get();         // always sees the latest value
    }
}

The race-condition program from earlier now always prints 200000, without any synchronized.

#Common Atomic Classes

#Key Methods

AtomicInteger stock = new AtomicInteger(10);

stock.addAndGet(5);                          // 15
stock.updateAndGet(v -> v * 2);              // 30
stock.accumulateAndGet(4, Math::max);        // 30
boolean ok = stock.compareAndSet(30, 0);     // true → 0

#How Compare-and-Swap Works

CAS is a single atomic CPU instruction (CMPXCHG on x86):

CAS(memoryLocation, expectedValue, newValue):
    if *memoryLocation == expectedValue:
        *memoryLocation = newValue
        return true
    else:
        return false

incrementAndGet() is essentially a retry loop around CAS:

public int incrementAndGet() {
    int current, next;
    do {
        current = get();            // read
        next = current + 1;         // compute
    } while (!compareAndSet(current, next));   // write only if nobody changed it meanwhile
    return next;
}

If another thread updated the value in between, the CAS fails and the loop simply retries with the fresh value — no thread ever blocks. This is called lock-free or optimistic concurrency.

#updateAndGet — Atomic Read-Modify-Write with a Function

AtomicReference<BigDecimal> balance = new AtomicReference<>(BigDecimal.ZERO);

balance.updateAndGet(b -> b.add(new BigDecimal("100.00")));

#AtomicReference for Immutable State

Combine AtomicReference with an immutable object to update several values atomically:

record Range(int low, int high) { }

class RangeHolder {
    private final AtomicReference<Range> range = new AtomicReference<>(new Range(0, 10));

    public void setLow(int low) {
        range.updateAndGet(r -> {
            if (low > r.high()) throw new IllegalArgumentException("low > high");
            return new Range(low, r.high());
        });
    }
}

The invariant low <= high can never be broken, because the whole Range is swapped in one CAS.

#The ABA Problem

CAS checks only that the value looks the same, not that it didn't change:

Thread 1 can't tell that the value changed twice. For counters this is harmless; for lock-free data structures (stacks, linked lists) where A is a node that was removed and reused, it can corrupt the structure.

Fix: AtomicStampedReference pairs the reference with a version stamp that increases on every change:

AtomicStampedReference<Node> top = new AtomicStampedReference<>(null, 0);

int[] stampHolder = new int[1];
Node current = top.get(stampHolder);
top.compareAndSet(current, newNode, stampHolder[0], stampHolder[0] + 1);

(It's the same idea as optimistic locking with a @Version column in JPA.)

#LongAdder — Counters Under Heavy Contention

When many threads hammer one AtomicLong, they all CAS the same memory location and most attempts fail and retry. LongAdder spreads updates across multiple internal cells and sums them on read:

LongAdder requests = new LongAdder();

requests.increment();          // very cheap even with hundreds of threads
long total = requests.sum();   // adds up all cells

ConcurrentHashMap uses the same idea internally to count its entries, and Micrometer counters use it too.

#When Atomics Aren't Enough

Atomic classes make one variable atomic. Two separate atomics updated one after the other are not atomic together:

AtomicInteger available = new AtomicInteger(10);
AtomicInteger reserved  = new AtomicInteger(0);

// ❌ Another thread can observe available + reserved != 10 in between
available.decrementAndGet();
reserved.incrementAndGet();

Either put both values in one immutable object behind an AtomicReference, or use a lock.

#Key Takeaways

• Atomic classes provide lock-free, thread-safe single-variable operations.
• They're built on CAS: compare, and swap only if unchanged; otherwise retry.
• Lock-free means no blocking and no deadlock, but possible retries under contention.
• The ABA problem is solved with version stamps (AtomicStampedReference).
• LongAdder beats AtomicLong for heavily contended counters.