1. The CPU Hardware Reality: Caches and Buffers

Before diving into Java specifications, we must understand the physical hardware on which our code executes.

CPUs run orders of magnitude faster than system RAM. If a CPU core had to wait for RAM reads and writes on every instruction, it would sit idle most of the time. To bridge this latency gap, cores feature L1, L2, and L3 cache hierarchies, along with **Write Buffers**:

*Mermaid Diagram: Hardware cache layouts and write buffer boundaries.

When Core 1 writes a value to variable x, the write does not go directly to Main Memory. It is written to Core 1's Write Buffer and then cached in Core 1's L1 cache. Unless forced, this updated value is not flushed to Main Memory, nor is Core 2's L1 cache informed of the update. Thus, Core 2 reads a stale value of x from its own L1 cache. This is the **Visibility Problem**.

2. Instruction Reordering: The Compiler and CPU Tricks

In addition to caching, CPUs and compilers perform **Instruction Reordering** to improve throughput.

Suppose you write the following code:

Since there is no data dependency between a and b, the compiler or the CPU's out-of-order execution engine may reorder these instructions:

While this has no effect on single-threaded execution, consider this concurrent example:

If the compiler reorders Thread 1's instructions (setting ready = true before x = 42), Thread 2 might see `ready == true` but read x = 0. This is the **Reordering Problem**.

3. The Happens-Before Relationship

To prevent reordering and visibility bugs, the JMM defines the **Happens-Before** partial ordering relation.

If action $A$ happens-before action $B$ ($A \xrightarrow{hb} B$), the JMM guarantees that the memory updates made by $A$ are visible to $B$, and that the compiler/CPU will not reorder them.

The JMM establishes happens-before relations through several rules:

• Program Order Rule: Each action in a single thread happens-before any subsequent action in that same thread.
• Volatile Variable Rule: A write to a volatile field happens-before any subsequent read of that same field.
• Monitor Lock Rule: An unlock on a monitor (synchronized block) happens-before any subsequent lock on that same monitor.
• Transitivity Rule: If $A \xrightarrow{hb} B$ and $B \xrightarrow{hb} C$, then $A \xrightarrow{hb} C$.

4. Under the Hood: Volatile and Memory Barriers

When you declare a variable as volatile, the JVM enforces two guarantees:

1. Visibility: Every write to a volatile variable is flushed directly to Main Memory, and every read fetches directly from Main Memory.
2. Instruction Reordering Prevention: The compiler and CPU are blocked from reordering volatile reads and writes around other memory operations.

To achieve this reordering prevention, the JVM injects **Memory Barriers** (also known as Memory Fences) into the compiled assembly code:

• StoreStore: Ensures all previous writes are flushed before the active write.
• LoadLoad: Ensures all previous reads are complete before the active read.
• StoreLoad: A heavy, full barrier that flushes the write buffer and forces subsequent reads to wait.

5. Practical Code Walkthroughs

Let us inspect two classic concurrent design patterns where JMM visibility and reordering guarantees are mandatory.

5.1 Double-Checked Locking (DCL) Singleton

The Double-Checked Locking pattern aims to reduce synchronization overhead when instantiating a singleton object. However, without volatile, this pattern is completely broken:

Why does DCL break without volatile?

The instruction instance = new DclSingleton() is not atomic. The JVM translates it into three logical steps at the bytecode level:

1. Allocate memory block for the object: memory = allocate();
2. Run constructor to initialize fields: ctorSingleton(memory);
3. Assign reference to instance: instance = memory;

Since step 2 and step 3 have no data dependencies, the compiler or CPU can reorder them:

If this reordering occurs, Thread A allocates memory and assigns it to instance (Step 3). At this exact moment, Thread B calls getInstance(). Since instance is not null, Thread B returns it immediately. However, since the constructor has not run yet (Step 2), Thread B attempts to use an uninitialized object, leading to crashes or corrupt data states!

5.2 Loop Hoisting Optimization

Consider a background worker thread waiting for a termination flag:

Without volatile, the JIT (Just-In-Time) compiler assumes that the active variable cannot be modified from outside the thread because there are no synchronizing boundaries inside the loop.

To optimize performance, the JIT performs **Loop Hoisting**:

Even if a parent thread calls stop(), the worker thread will remain stuck in the loop forever because it never re-reads the flag from memory. Adding volatile blocks the JIT from hoisting the check, forcing it to re-evaluate the flag from main memory on every iteration.

6. Formal happens-before Relations

The happens-before relationship is defined as a mathematical **strict partial ordering** relation over all actions in a program.

A partial ordering relation $\xrightarrow{hb}$ is defined as:

• Irreflexive: For any action $A$, it is not true that $A \xrightarrow{hb} A$.
• Antisymmetric: If $A \xrightarrow{hb} B$, then it is not true that $B \xrightarrow{hb} A$.
• Transitive: If $A \xrightarrow{hb} B$ and $B \xrightarrow{hb} C$, then $A \xrightarrow{hb} C$.

This ordering guarantees that if $A \xrightarrow{hb} B$, then the execution results of $A$ are fully visible to $B$. If two concurrent memory access actions are not ordered by a happens-before relationship, they form a **Data Race**, and the JMM does not guarantee safety.

7. Hardware Cache Coherence: The MESI Protocol

To coordinate cache states between multiple CPU cores, hardware designers use cache coherence protocols. The most common is the **MESI Protocol**.

Under MESI, every cache line resides in one of four states:

• M (Modified): The cache line is valid but dirty (only this core has the updated value, and main memory is stale).
• E (Exclusive): The cache line is clean and present only in this core's cache.
• S (Shared): The cache line is clean and present in other cores' caches.
• I (Invalid): The cache line contains invalid data.

When Core 1 writes a volatile variable, it broadcasts a cache invalidation request. Core 2 intercepts this, updates its cache line status to **I (Invalid)**, and is forced to fetch the updated block from Main Memory on its next read.

8. Performance Comparison

While volatile guarantees synchronization, it adds memory barrier overhead. The chart below displays the throughput comparison:

9. Interactive JMM Cache Simulator

Configure the variable sync mode, execute a thread write, and trace how caches flush and invalidate:

10. Frequently Asked Questions (FAQ)

11. Safe Publication and final Fields

Under the JMM, final fields have a unique status. In standard multithreading, you must use synchronization (like volatile or locking) to ensure that a newly constructed object is visible to other threads. However, **final fields** provide built-in safe publication guarantees without any locks.

The JMM guarantees that once an object constructor completes, any fields declared final are guaranteed to be initialized and fully visible to other threads.

Under the hood, the compiler enforces this by injecting a **StoreStore barrier** at the end of the constructor:

If Thread A creates an instance and exposes it to Thread B, Thread B is guaranteed to see the correct value of id ($42$), even if the object reference is exposed without synchronization. However, the non-final field value has no such guarantees, and Thread B might read it as $0$ (stale value).

Key Constraint: Safe publication only works if the object reference does not escape the constructor during creation (e.g. passing `this` to a list or registry inside the constructor body). If reference escape occurs, other threads can see the object reference before the StoreStore barrier executes, breaking all guarantees.

12. Happens-Before in JDK Concurrent Collections

Java's concurrent libraries in java.util.concurrent build on top of JMM rules to guarantee lock-free visibility.

12.1 ReentrantLock and Semaphore

Standard locks use the Volatile Variable Rule to ensure visibility. Classes like ReentrantLock store their lock state in a volatile state variable inherited from **AbstractQueuedSynchronizer (AQS)**.

When Thread A releases a lock, it writes to this volatile variable. When Thread B acquires the lock, it reads that same variable. Under the Volatile Variable Rule and Transitivity, all actions performed by Thread A before releasing the lock happen-before Thread B acquires it, guaranteeing full visibility.

12.2 ConcurrentHashMap

`ConcurrentHashMap` achieves lock-free read operations because its internal node bucket array contains nodes where the value field is declared `volatile`:

Any write to a bucket node value flushes immediately, and subsequent reads fetch the updated value directly from main memory, completely bypassing lock overhead for read operations.

13. Frequently Asked Questions (FAQ)