Mastering Java CAS: How AtomicInteger Achieves Lock‑Free Concurrency

In high‑concurrency scenarios, traditional synchronization using synchronized or Lock incurs significant performance overhead due to heavyweight locking. The article introduces Compare‑And‑Swap (CAS) as a lock‑free, optimistic‑locking alternative that many interview questions and real‑world systems rely on.

What is CAS?

CAS stands for Compare And Swap . It is a CPU‑supported atomic instruction that reads a memory location, compares its current value with an expected value, and, if they match, writes a new value. This operation is atomic and enables non‑blocking synchronization.

In Java, CAS underpins classes like AtomicInteger, ConcurrentHashMap, etc. Java itself does not implement CAS directly; it delegates to native code via the Unsafe class (e.g., compareAndSwapInt), which invokes the underlying CPU instruction.

CAS Workflow

The process involves three values: the original value A read before computation, the new value B calculated by business logic, and the current memory value C read again before committing. If A equals C , the update succeeds; otherwise, the operation retries.

Using CAS with AtomicInteger

Without CAS, a thread‑safe increment might use a synchronized method:

public class ThreadSafeTest {
    public static volatile int i = 0;
    public synchronized void increase() {
        i++;
    }
}

With CAS, the same logic becomes concise and lightweight:

public class ThreadSafeTest {
    private final AtomicInteger counter = new AtomicInteger(0);
    public int increase() {
        return counter.addAndGet(1);
    }
}

AtomicInteger provides several atomic APIs such as get(), getAndSet(), getAndIncrement(), getAndAdd(int delta), and lazySet(int newValue).

Core Implementation

The key part of AtomicInteger is:

public final int incrementAndGet() {
    return unsafe.getAndAddInt(this, valueOffset, 1) + 1;
}

During class initialization, Unsafe.objectFieldOffset obtains the memory offset of the value field. The getAndAddInt method performs a CAS loop:

public final int getAndAddInt(Object obj, long offset, int delta) {
    int prev;
    do {
        prev = this.getIntVolatile(obj, offset);
    } while (!this.compareAndSwapInt(obj, offset, prev, prev + delta));
    return prev;
}

This loop embodies a spin‑wait: if the CAS fails because another thread modified the value, the method retries until it succeeds.

Unsafe and CAS Mechanics

sun.misc.Unsafe

exposes low‑level operations such as memory access and CAS primitives. Although powerful, it is intended for JDK internal use and not for regular application code.

The CAS operation ultimately maps to a native CPU instruction (e.g., cmpxchg on x86), guaranteeing atomicity.

Drawbacks of CAS

Long spin loops can cause high CPU consumption when contention is heavy.

CAS only guarantees atomicity for a single variable; complex updates involving multiple variables require additional coordination.

The ABA problem: a value may change from A to B and back to A, misleading a CAS check. Solutions include versioned stamps (e.g., AtomicStampedReference) or adding a counter.

ABA Example

Thread P1 reads A, gets pre‑empted, P2 changes the value to B then back to A, and P1 proceeds, falsely assuming no change.

Summary

The article covers CAS concepts, the basic workflow, how AtomicInteger leverages CAS via Unsafe, and the limitations of CAS such as spin‑wait overhead, single‑variable restriction, and the ABA issue, along with common mitigation techniques.