Unlocking Java’s Unsafe: How CAS Powers High‑Performance Concurrency

Unsafe

Java cannot directly access the operating system; it uses native methods instead. The JDK provides a hidden class Unsafe that offers hardware‑level atomic operations. Although its methods are public, they are restricted to trusted code, and the JDK itself can use them freely.

Key native methods include:

public native long staticFieldOffset(Field paramField);
public native int arrayBaseOffset(Class paramClass);
public native int arrayIndexScale(Class paramClass);
public native long allocateMemory(long size);
public native long reallocateMemory(long oldSize, long newSize);
public native void freeMemory(long address);

These methods retrieve field memory offsets, array base addresses, element scaling factors, and manage off‑heap memory, requiring a solid understanding of C/C++ memory concepts.

CAS

Compare‑and‑Swap (CAS) is a fundamental technique for building concurrent algorithms; the entire java.util.concurrent package relies on it. Modern CPUs provide CAS instructions, which Unsafe exposes via three native methods:

public final native boolean compareAndSwapObject(Object obj, long offset, Object expected, Object newValue);
public final native boolean compareAndSwapInt(Object obj, long offset, int expected, int newValue);
public final native boolean compareAndSwapLong(Object obj, long offset, long expected, long newValue);

For example, a naive lock‑free integer update without CAS would be:

public int i = 1;
public boolean compareAndSwapInt(int j) {
    if (i == 1) {
        i = j;
        return true;
    }
    return false;
}

In a concurrent scenario this code can corrupt the shared variable because the check‑then‑set sequence is not atomic.

AtomicInteger Implementation

Atomic classes in java.util.concurrent.atomic are built on CAS. AtomicInteger obtains a memory offset for its value field via Unsafe:

private static final Unsafe unsafe = Unsafe.getUnsafe();
private static final long valueOffset;
static {
    try {
        valueOffset = unsafe.objectFieldOffset(AtomicInteger.class.getDeclaredField("value"));
    } catch (Exception ex) { throw new Error(ex); }
}
private volatile int value;

The core method addAndGet uses a loop with compareAndSet to achieve lock‑free thread safety:

public final int addAndGet(int delta) {
    for (;;) {
        int current = get();
        int next = current + delta;
        if (compareAndSet(current, next))
            return next;
    }
}
public final int get() { return value; }

During execution, two threads read the same initial value, one succeeds in CAS and updates the memory, while the other detects the mismatch, retries, and eventually sees the updated value thanks to the volatile visibility guarantee.

CAS Drawbacks

CAS cannot handle all concurrency scenarios. It suffers from the ABA problem: a variable may change from A to B and back to A, making a CAS check falsely succeed. Java mitigates this with AtomicStampedReference, which tracks a version stamp, though in many cases traditional locking remains more efficient.