Java Atomics and VarHandle: Low-Level Concurrency

synchronized and Lock serialize access using blocking. But sometimes you can avoid blocking entirely. Atomic classes use Compare-And-Swap (CAS) operations provided by the CPU, which let threads cooperate without waiting in line. For even lower-level access, VarHandle gives you direct access to volatile semantics and custom atomic operations.

Introduction

synchronized and Lock solve the concurrency problem by making threads wait. When contention is low, this works fine. But when many threads hit the same synchronized block, the OS thread-suspension overhead, context switches, and kernel-mode transitions accumulate into measurable latency. Java provides an alternative: atomic operations built on Compare-And-Swap (CAS), a hardware instruction that lets threads cooperate without blocking. For simple counters, flags, and reference updates, atomic classes like AtomicInteger and AtomicReference outperform locks under low to moderate contention because threads retry rather than wait.

VarHandle, introduced in Java 9, gives you direct programmatic access to the same volatile semantics that atomic classes are built on. You can specify memory ordering modes (volatile, acquire, release, opaque), create custom atomic operations not provided by the standard library, and implement concurrent data structures with precise control over visibility guarantees. The tradeoff is complexity: atomic classes handle the retry loops and memory ordering for you, while VarHandle requires you to reason about these details explicitly.

This post covers why CAS-based lock-free programming outperforms locks under low contention but can degrade under extreme contention, how AtomicInteger, AtomicLong, AtomicReference, and LongAdder each map to hardware CAS operations, when VarHandle is appropriate versus when to stick with the simpler atomic wrappers, and the ABA problem that haunts lock-free data structures using simple reference comparisons.

Why CAS Instead of Locks?

Locks work by having threads wait when contested. This involves OS thread suspension, context switching, and kernel-mode transitions. CAS operations are implemented in hardware - a single CPU instruction that atomically compares a memory value with an expected value and swaps them if they match.

// Lock-based: threads block and wait
synchronized (lock) {
    counter++; // Only one thread here at a time
}

// Lock-free: threads retry via CAS
// Implementation roughly:
do {
    oldValue = counter.get();
    newValue = oldValue + 1;
} while (!counter.compareAndSet(oldValue, newValue)); // Retry if another thread changed it

Under low contention, atomics are faster because threads don’t block. Under high contention, locks with OS thread management can actually perform better. Know your workload.

AtomicInteger and AtomicLong

AtomicInteger counter = new AtomicInteger(0);

// Basic operations
counter.set(10);
counter.get(); // Returns 10

// Atomic increment
counter.incrementAndGet();  // ++i, returns new value
counter.getAndIncrement();  // i++, returns old value
counter.addAndGet(5);       // i += 5, returns new value
counter.getAndAdd(5);       // i += 5, returns old value

// Update with function
counter.updateAndGet(x -> x * 2); // Double the value
counter.accumulateAndGet(3, Integer::sum); // Accumulate

// Compare and set (the foundation)
boolean success = counter.compareAndSet(10, 20); // Sets to 20 only if current is 10

Why AtomicInteger Beats Volatile for Counters

Volatile can read and write individually but can’t do read-modify-write atomically:

// BROKEN - not atomic despite volatile
private volatile int counter = 0;
counter++; // Read, increment, write - three operations!

// FIXED - truly atomic
private AtomicInteger counter = new AtomicInteger(0);
counter.incrementAndGet(); // Single atomic operation

AtomicReference

AtomicReference lets you atomically update object references:

AtomicReference<Node> current = new AtomicReference<>(initialNode);

// Basic operations
current.set(newNode);
Node node = current.get();

// Atomic update
current.compareAndSet(expectedNode, newNode); // Set only if still expected

// Functional updates
current.updateAndGet(node -> node.next()); // Walk the chain
current.accumulateAndGet(node, (n1, n2) -> merge(n1, n2));

Implementing Lock-Free Singly Linked List

public class LockFreeStack<T> {
    private final AtomicReference<Node<T>> head = new AtomicReference<>(null);

    private static class Node<T> {
        final T value;
        final Node<T> next;
        Node(T value, Node<T> next) {
            this.value = value;
            this.next = next;
        }
    }

    public void push(T value) {
        Node<T> newNode = new Node<>(value, null);
        while (true) {
            Node<T> oldHead = head.get();
            newNode.next = oldHead;
            if (head.compareAndSet(oldHead, newNode)) {
                return; // Success
            }
            // head changed, retry
        }
    }

    public T pop() {
        while (true) {
            Node<T> oldHead = head.get();
            if (oldHead == null) return null;
            Node<T> newHead = oldHead.next;
            if (head.compareAndSet(oldHead, newHead)) {
                return oldHead.value;
            }
            // head changed, retry
        }
    }
}

The retry loop is the key to lock-free programming. If CAS fails, another thread modified the data, so you retry with the new value.

VarHandle

VarHandle (Java 9+) gives you direct access to volatile read/write semantics and lets you create custom atomic operations. It’s the building block behind atomic classes.

public class Counter {
    private volatile int count = 0;

    // Get a VarHandle for the count field
    private static final VarHandle VH;

    static {
        try {
            VH = MethodHandles.lookup()
                .findVarHandle(Counter.class, "count", int.class);
        } catch (NoSuchFieldException | IllegalAccessException e) {
            throw new ExceptionInInitializerError(e);
        }
    }

    public int get() {
        return (int) VH.getVolatile(this);
    }

    public void set(int value) {
        VH.setVolatile(this, value);
    }

    public int incrementAndGet() {
        return (int) VH.getAndAdd(this, 1) + 1;
    }

    // Weak CAS - doesn't provide ordering guarantees
    public boolean weakCompareAndSet(int expect, int update) {
        return VH.weakCompareAndSet(this, expect, update);
    }

    // Full CAS loop
    public boolean compareAndSet(int expect, int update) {
        return VH.compareAndSet(this, expect, update);
    }
}

VarHandle Memory Order Modes

VarHandle operations can specify memory ordering:

// Full volatile semantics (acquire + release)
VH.getVolatile(this);
VH.setVolatile(this, value);

// Relaxed - no ordering guarantees, only atomicity
VH.getAcquire(this);
VH.setRelease(this, value);

// Opaque - atomic but no ordering
VH.getOpaque(this);
VH.setOpaque(this, value);

// Sequentially consistent (default for volatile)
VH.get(this);           // Same as getVolatile
VH.set(this, value);   // Same as setVolatile

// CAS with explicit ordering
VH.compareAndSet(this, expect, update); // Default: sequential
VH.weakCompareAndSetAcquire(this, expect, update); // CAS with acquire ordering

When to Use VarHandle Over Atomic Classes

VarHandle is lower-level and useful when:

• You need custom atomic operations not provided by Atomic* classes
• You need specific memory ordering semantics
• You’re implementing concurrent data structures
• You need field offset access for JNI or custom memory management

For simple counters and flags, stick with AtomicInteger, AtomicBoolean, etc.

LongAdder vs AtomicLong

LongAdder provides better throughput under high contention by spreading contention across multiple cells:

LongAdder adder = new LongAdder();

for (int i = 0; i < 1000; i++) {
    adder.increment(); // Much faster under contention than AtomicLong
}

long sum = adder.sum(); // Get accumulated value

Under low contention, AtomicLong is fine. Under high contention with many threads updating the same counter, LongAdder’s striped design scales much better.

AtomicFieldUpdater

AtomicFieldUpdater lets you add atomicity to existing fields without replacing them:

public class Person {
    volatile int age;
    volatile String name;
}

AtomicIntegerFieldUpdater<Person> ageUpdater =
    AtomicIntegerFieldUpdater.newUpdater(Person.class, "age");
AtomicReferenceFieldUpdater<Person, String> nameUpdater =
    AtomicReferenceFieldUpdater.newUpdater(Person.class, "String", "name");

// Use on existing objects
Person p = new Person();
ageUpdater.compareAndSet(p, 30, 31);
nameUpdater.compareAndSet(p, "John", "Jane");

This saves memory when you have many objects of the same type that need atomic updates.

Architecture Diagram

Hardware CAS

graph TD
    subgraph Hardware
        CAS[Compare-And-Swap Instruction]
    end

java.util.concurrent.atomic

graph TD
    subgraph java.util.concurrent.atomic
        AI[AtomicInteger] --> CAS
        AL[AtomicLong] --> CAS
        AR[AtomicReference] --> CAS
        LA[LongAdder] --> CAS
        AFU[AtomicFieldUpdater] --> CAS
    end

VarHandle

graph TD
    subgraph VarHandle
        VH[VarHandle] --> CAS
        VH --> VH1[Memory Order Modes]
        VH1 --> VH2[getVolatile / setVolatile]
        VH1 --> VH3[getAcquire / setRelease]
        VH1 --> VH4[opaque / ordered]
    end

Production Failure Scenarios

Scenario 1: ABA Problem

// BROKEN - ABA problem
// Thread A sees X, Thread B sees X, changes to Y, changes back to X
// Thread A sees X (looks unchanged) but X was modified in between
AtomicReference<Node> current = new AtomicReference<>(nodeA);
current.compareAndSet(nodeA, nodeB); // Thinks nodeA is still there!

// FIXED - use AtomicStampedReference or AtomicMarkableReference
AtomicStampedReference<Node> stamped = new AtomicStampedReference<>(nodeA, 0);
stamped.compareAndSet(nodeA, nodeB, stamp, stamp + 1); // Stamps detect modifications

The ABA problem: a value changes from A to B and back to A. CAS sees no change even though the value was modified.

Scenario 2: Retry Storm Under Contention

// BROKEN - high contention causes excessive retries
public void highlyContested() {
    while (!counter.compareAndSet(counter.get(), counter.get() + 1)) {
        // If many threads retry, throughput collapses
    }
}

// FIXED - use LongAdder for high-contention counters
LongAdder adder = new LongAdder(); // Much better under contention

Scenario 3: Wrong Memory Ordering

// BROKEN - relaxed writes might not be visible to other threads
VH.setRelease(this, value); // Release semantics only
// If another thread does getAcquire, it might see stale data!

// FIXED - use volatile semantics when ordering matters
VH.setVolatile(this, value); // Full happens-before guarantees

Trade-off Table

Approach	Contention Handling	Performance	Complexity	Use When
synchronized	Blocking	Good under high contention	Low	Simple cases
AtomicInteger	Retry loop	Good under low contention	Medium	Simple counters
LongAdder	Striped cells	Best under high contention	Medium	High-contention counters
VarHandle	Custom	Tunable	High	Custom atomics
Lock	Blocking	Tunable fairness	Medium	Need conditions

Implementation Snippets

Lock-Free Bounded Ring Buffer

public class RingBuffer<T> {
    private final Object[] buffer;
    private final int capacity;
    private final AtomicInteger tail = new AtomicInteger(0);
    private final AtomicInteger head = new AtomicInteger(0);

    public RingBuffer(int capacity) {
        this.capacity = capacity;
        this.buffer = new Object[capacity];
    }

    public boolean offer(T item) {
        int tailNow = tail.get();
        int headNow = head.get();
        if ((tailNow - headNow) >= capacity) {
            return false; // Full
        }
        buffer[tailNow % capacity] = item;
        tail.incrementAndGet();
        return true;
    }

    @SuppressWarnings("unchecked")
    public T poll() {
        int headNow = head.get();
        if (headNow >= tail.get()) {
            return null; // Empty
        }
        T item = (T) buffer[headNow % capacity];
        head.incrementAndGet();
        return item;
    }
}

Custom Atomic Boolean with VarHandle

public class AtomicBoolean {
    private volatile int value = 0;
    private static final VarHandle VH;

    static {
        try {
            VH = MethodHandles.lookup()
                .findVarHandle(AtomicBoolean.class, "value", int.class);
        } catch (Exception e) {
            throw new Error(e);
        }
    }

    public AtomicBoolean(boolean initial) {
        VH.setVolatile(this, initial ? 1 : 0);
    }

    public final boolean get() {
        return (int) VH.getVolatile(this) != 0;
    }

    public final boolean compareAndSet(boolean expected, boolean update) {
        return VH.compareAndSet(this,
            expected ? 1 : 0,
            update ? 1 : 0);
    }

    public final void set(boolean newValue) {
        VH.setVolatile(this, newValue ? 1 : 0);
    }
}

Observability Checklist

• Are you using atomics for simple counters or flags only?
• Can you detect retry storms under high contention?
• Do you understand the memory ordering semantics you’re using?
• Are you handling the ABA problem where relevant?
• Can you measure atomic vs lock performance for your workload?
• Are you using LongAdder for high-contention counters?

Security Notes

Lock-free algorithms can expose timing side channels:

• Retry counts can leak information about contention
• Cache line bouncing in LongAdder can create observable timing patterns
• Compare-and-set failures can leak information about operation timing

Use constant-time operations where security-sensitive decisions depend on timing.

Common Pitfalls / Anti-Patterns

1. Using atomics where locks are clearer: If in doubt, prefer readability
2. Ignoring the ABA problem: Use stamped references for reference-based structures
3. Wrong memory ordering: Use volatile semantics unless you understand the tradeoffs
4. Retrying forever under contention: Consider LongAdder or locks instead
5. Assuming atomicity means visibility: Still need volatile/CAS semantics
6. Forgetting about long vs int: AtomicLong for values > 2^31

Quick Recap Checklist

• CAS (Compare-And-Swap) enables lock-free coordination
• AtomicInteger provides atomic read-modify-write for ints
• AtomicReference enables lock-free pointer updates
• VarHandle gives low-level access to volatile semantics
• LongAdder scales better than AtomicLong under high contention
• ABA problem requires stamped/marked references to solve
• Memory ordering matters - use volatile semantics unless certain
• Retry loops are normal in lock-free programming

Interview Questions

Further Reading

• VarHandle official documentation — Memory order modes and operations
• Atomic stamps and marked references — Solving the ABA problem in lock-free structures
• LongAdder vs AtomicLong performance — Striped contention under high load
• JEP 425: Virtual Threads (preview) — How virtual threads affect lock-free programming in Java 18+
• HardwareCASimplementation — How Compare-And-Swap maps to CPU instructions

Conclusion

You now understand CAS-based lock-free programming with atomic classes and VarHandle. Apply atomics for simple counters and flags where you need atomic read-modify-write without locks. Use LongAdder for high-contention counters, stamped references to avoid the ABA problem, and VarHandle when you need custom memory ordering beyond what Atomic* classes offer. Remember that lock-free does not mean contention-free — under high contention, consider whether locks with OS thread management might actually perform better. Continue with Java Memory Model to understand the memory visibility guarantees that underpin all these concurrency constructs.