Java 17 Memory Barriers: Why They're Needed and How to Use Them

The article opens with a classic two-thread scenario: thread A writes data = 100 then ready = true, while thread B reads data only if ready is true. Intuitively, thread B should print 100, but it may print 0 because the CPU and compiler can reorder the writes.

Why CPU and Compiler Reorder Instructions

An analogy compares instruction reordering to cooking: instead of chopping then cooking each ingredient sequentially, a chef chops everything first then cooks, improving efficiency. Similarly, compilers reorder instructions to better utilize registers (compiler reordering), and CPUs execute instructions out of order to keep pipelines full (CPU out-of-order execution). Multi-level caches add a delay between a write to L1 cache and its visibility to other cores. In single-threaded code these optimizations are invisible, but in multi-threaded code they break expectations: thread A's ready = true can become visible before data = 100, so thread B sees ready == true but reads stale data == 0.

Memory Barriers: The Traffic Lights

A memory barrier is a special CPU instruction (or synchronization primitive) that forces all operations before the barrier to complete before any operation after the barrier begins. The Java Memory Model (JMM) dictates where barriers must be inserted; developers don't place them manually — using Java's synchronization mechanisms automatically inserts the correct barriers.

Four Barrier Types and Acquire/Release Semantics

The four barrier types combine Load and Store operations:

LoadLoad – a read must finish before the next read.

StoreStore – a write must be visible to other processors before the next write.

LoadStore – a read must finish before the next write.

StoreLoad – a write must be globally visible before the next read; the most expensive barrier.

Instead of memorizing all four, the article introduces Acquire (for reads) and Release (for writes) semantics:

Release: all prior reads/writes complete before the current write takes effect.

Acquire: all subsequent reads/writes wait until the current read finishes.

Pairing a write-side Release with a read-side Acquire ensures visibility and ordering. Most concurrency primitives follow this pattern.

Using Memory Barriers in Java 17

Implicit: volatile

Declaring a variable volatile makes the JIT compiler insert Release semantics on write (StoreStore + StoreLoad) and Acquire semantics on read (LoadLoad + LoadStore). The example fixes the race by marking ready volatile:

volatile boolean ready = false;
// write: Release ensures data=100 visible before ready=true
// read: Acquire ensures subsequent data read not moved before ready read

Explicit: VarHandle

Java 9 introduced VarHandle for fine-grained control over individual accesses without making the whole field volatile. Example:

static final VarHandle VH = MethodHandles.lookup()
    .findVarHandle(Fence.class, "ready", boolean.class);
// Write with Release
VH.setRelease(this, true);
// Read with Acquire
boolean r = (boolean) VH.getAcquire(this);

setRelease

guarantees data = 100 is visible before ready write; getAcquire guarantees the data read isn't reordered before the ready read. Unlike volatile, VarHandle applies semantics per access.

VarHandle also provides static fence methods: releaseFence(), acquireFence(), fullFence() for standalone barriers, mainly used inside concurrency frameworks.

Summary

Understanding memory barriers clarifies why volatile, ReentrantLock, CompletableFuture, and concurrent containers work. For 99% of business code, high-level abstractions suffice; direct barrier manipulation is only needed when building high-performance frameworks (e.g., Disruptor, Netty), reading concurrency library source, or debugging subtle multi-threaded bugs.

Clarifications

Memory barriers are not always single CPU instructions; more accurately they are synchronization primitives provided by the CPU.

On some architectures, the JIT emits only a lock -prefixed instruction (effectively StoreLoad) for volatile writes, omitting explicit StoreStore because hardware already guarantees it.