How Do Atomic Classes Avoid Locks?

The classes in java.util.concurrent.atomic provide atomic read-modify-write operations on a single variable without taking a lock. The mechanism is a compare-and-set instruction provided by the processor — a single CPU operation that atomically compares the current value with an expected value and swaps in a new one if they match. Because the hardware performs the whole thing as one indivisible step, no other thread can interleave with it.

That makes them lock-free rather than merely fast: no thread ever blocks waiting for a monitor, so there is no contention and no priority inversion. It also means there is no deadlock risk from them.

The operations are consistent across the family. get and set read and write. incrementAndGet, decrementAndGet, addAndGet and getAndIncrement do the arithmetic atomically, with the difference being whether the new or the old value is returned. compareAndSet swaps only if the value is still what you expect, and returns a boolean. updateAndGet applies a function to the current value atomically, and accumulateAndGet does the same with a binary function.

There are specialised classes for the primitive types — AtomicInteger, AtomicLong, AtomicBoolean, and the floating-point pair — plus AtomicReference for objects and AtomicReferenceArray for arrays. And the array classes have a notable design: unlike the plain atomic classes, they support weakly consistent iteration, where the iterator reflects the state at or since the iteration began rather than throwing when the array is modified.

Start with the simple operations. incrementAndGet does an atomic increment and returns the new value. compareAndSet swaps the value only if it is still what you expect, which is how you build a lock-free update without a lock. And updateAndGet applies a function to the current value atomically, which is the most expressive of the three.

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

public class Main {
    public static void main(String[] args) {
        AtomicInteger counter = new AtomicInteger(0);

        // incrementAndGet is atomic.
        counter.incrementAndGet();
        counter.addAndGet(5);
        System.out.println("counter      : " + counter.get());

        // compareAndSet only changes the value if it is still what we expect.
        boolean swapped = counter.compareAndSet(6, 100);
        System.out.println("swapped      : " + swapped);
        System.out.println("counter      : " + counter.get());

        boolean failed = counter.compareAndSet(6, 200);
        System.out.println("failed swap  : " + failed);

        // updateAndGet runs a function atomically.
        int doubled = counter.updateAndGet(v -> v * 2);
        System.out.println("doubled      : " + doubled);

        // AtomicReference works with any object.
        AtomicReference<String> ref = new AtomicReference<>("first");
        ref.compareAndSet("first", "second");
        System.out.println("reference    : " + ref.get());
    }
}

The output shows the semantics. The counter reaches 6, the first compareAndSet succeeds because the value is still 6, and the second fails because the value is now 100. The updateAndGet doubles whatever is there atomically.

The ABA problem is the limitation you should know about. Between the compare and the swap, another thread can change the value away and back again. The compare-and-set then succeeds, even though the value has been through a different state in between. If the code cares about that intermediate state — for example if the value is a reference to a mutable object that was replaced and replaced back, or a version number that other code also modifies — the update is wrong even though the atomic operation succeeded.

The classic fix is to pack the version into the same atomic value, which is what AtomicStampedReference provides: it holds both the reference and a stamp, and the compare-and-swap checks both. The alternative is to make the value truly immutable so that its identity cannot be reused, which is another argument for records and for defensive copies.