Java Memory Model: Happens-Before, Synchronized, Volatile, and Final Field Semantics

The Java Memory Model sounds like academic fluff until you’re debugging a bug that only appears in production at 3am. The JMM is the set of rules that govern how the JVM handles memory visibility and operation ordering across threads. Get these wrong and you’ll spend weeks chasing data races that vanish when you add logging.

If you’re new to threads, start with Threads and Lightweight Processes for foundational concepts.

Introduction

The Java Memory Model (JMM) is the set of rules that govern how the JVM handles memory visibility and operation ordering across threads. It defines the guarantees that Java programs can rely on when multiple threads access shared memory simultaneously. Without these rules, you would have no reliable way to reason about what one thread sees when another thread writes to a field—the JVM and CPU could reorder operations in ways that produce bugs invisible during testing and catastrophic in production.

The practical consequence of ignoring the JMM is data races: situations where threads disagree on the state of shared data because visibility guarantees are violated. These bugs are notoriously difficult to debug because they often disappear when you add logging (logging introduces synchronization that masks the race), they may only appear under specific CPU architectures or JVM configurations, and they typically resist attempts to reproduce them consistently. The JMM gives you the vocabulary and the tools to identify and fix these issues systematically rather than by trial and error.

This post covers the happens-before relationship that forms the foundation of JMM guarantees, explains how synchronized and volatile establish ordering constraints, and clarifies why final fields have special safety semantics. By the end, you will be able to analyze concurrent code for data races, apply the correct synchronization primitive for each situation, and understand why patterns like double-checked locking require volatile to work correctly. You will also have a clear mental model for reasoning about thread visibility in any Java program you encounter.

What Is the Java Memory Model?

The JMM defines the behavior of memory operations in concurrent Java programs. It specifies how reads and writes to memory happen across threads, ensuring that certain operations appear to happen in a specific order relative to each other.

The core problem the JMM solves is this: without proper synchronization, a thread might see stale data written by another thread, or observe operations in an order that differs from program order. The JMM provides a formal specification for when these visibility guarantees hold.

Modern processors and compilers perform optimizations that can reorder memory operations for performance. The JMM defines a set of rules called happens-before relationships that establish when these reorderings are prohibited.

Happens-Before Relationships

If one action happens-before another, the first action’s results are guaranteed to be visible to the second action. That’s the definition, but let’s look at where these guarantees come from.

Key Happens-Before Rules

Here are the rules that actually matter in practice:

1. Program Order Rule: Within each thread, each action happens-before any subsequent action in that same thread
2. Monitor Lock Rule: An unlock of a monitor happens-before each subsequent lock on that same monitor
3. Volatile Field Rule: A write to a volatile field happens-before each subsequent read of that same field
4. Thread Start Rule: A call to Thread.start() happens-before any action in the started thread
5. Thread Termination Rule: A thread termination action happens-before any action that detects the thread has terminated
6. Transitivity: If A happens-before B, and B happens-before C, then A happens-before C

Practical Example

Here’s a classic data race that trips up a lot of developers:

public class DataRaceExample {
    private int counter = 0;
    private boolean ready = false;

    public void writer() {
        counter = 42;      // Action A
        ready = true;       // Action B
    }

    public void reader() {
        if (ready) {        // Action C
            System.out.println(counter); // Action D
        }
    }
}

Without synchronization, the reader might see counter = 0 even when ready = true. The JMM doesn’t guarantee visibility across threads without happens-before relationships. Making ready volatile fixes this:

private volatile boolean ready = false;

Now the write to ready happens-before the read of ready, ensuring the write to counter is also visible (due to transitivity with the Program Order Rule).

Synchronized Blocks

The synchronized keyword gives you mutual exclusion plus happens-before guarantees. When a thread acquires a monitor and then releases it, all memory operations before the release become visible to the next thread that acquires the same monitor.

Synchronized Method vs Block

public class SynchronizedExample {
    private final Object lock = new Object();
    private int value = 0;

    // Instance method synchronization - uses 'this' as monitor
    public synchronized void increment() {
        value++;
    }

    // Equivalent block syntax
    public void incrementBlock() {
        synchronized (this) {
            value++;
        }
    }

    // Separate lock object for finer control
    public void processWithSeparateLock() {
        synchronized (lock) {
            // Critical section with dedicated lock
            performOperation();
        }
    }
}

Happens-Before Guarantees with Synchronized

When you exit a synchronized block:

1. All memory operations within the block become visible to the next thread that enters a synchronized block on the same monitor
2. The monitor unlock action happens-before any subsequent lock action on that same monitor
3. This applies even if the threads are running on different cores or processors

For more on lock-related issues, see Deadlock and Starvation and Locking and Concurrency.

Common Pitfalls

Over-synchronization is the mistake I run into most. Developers hold a lock across a large collection iteration, a remote call, I/O — anything slow — and suddenly an application that should handle thousands of concurrent requests is bottle-necked to a single thread. The fix sounds simple because it is: keep locks down to the actual mutation, nothing derived and nothing that could block.

Lock ordering deadlocks are worse. Thread A holds Lock 1 and waits for Lock 2 while Thread B holds Lock 2 and waits for Lock 1. Neither makes progress. They surface under load when timing tips the race in the wrong direction. Fixing them requires acquiring multiple locks in a consistent global order — easy to state, harder when those locks span different subsystems or live in libraries you did not write.

Holding locks during blocking operations is the third trap. Calling wait(), sleep(), or performing I/O while holding a monitor lock stalls every other thread that needs that lock for the duration of the blocking call. If enough requests back up behind a thread waiting on a network response while holding the lock, you get thread exhaustion. Keep synchronized blocks short and never do potentially blocking things inside them.

• Over-synchronization: Holding locks for too long degrades performance and can cause deadlocks
• Inconsistent lock ordering: Acquiring multiple locks in different orders across threads causes deadlock
• Holding locks during blocking operations: Never do I/O or wait() while holding a lock

Volatile Fields

Volatile gives you weaker guarantees than synchronized but with less overhead. A write to a volatile field is visible to all subsequent reads of that same field.

When to Use Volatile

Volatile works when:

• You need visibility guarantees for a single variable across threads
• The variable is accessed by multiple threads without compound operations
• You want to signal state changes between threads

public class VolatileExample {
    // Use volatile for flags and state variables
    private volatile boolean shutdownRequested = false;
    private volatile long lastUpdateTime = 0;

    public void requestShutdown() {
        shutdownRequested = true;
    }

    public void doWork() {
        while (!shutdownRequested) {
            // Work loop
            lastUpdateTime = System.nanoTime();
        }
    }
}

When NOT to Use Volatile

Volatile is insufficient when:

• You need atomic operations on multiple variables
• You need mutual exclusion
• Compound operations are required (e.g., counter++)

// BROKEN - counter++ is not atomic even with volatile
private volatile int counter = 0;

// This still has a data race!
public void increment() {
    counter++; // Read-modify-write is not atomic
}

// CORRECT - use AtomicInteger for compound operations
// See also: Lock-Free Data Structures
private AtomicInteger counter = new AtomicInteger(0);

public void increment() {
    counter.incrementAndGet();
}

Volatile and Happens-Before

The volatile field rule is what makes volatile actually useful for cross-thread signaling. When a thread writes to a volatile field, the JVM issues a write memory barrier that drains all pending writes to main memory before the volatile write itself commits. On the read side, a volatile field access triggers a read barrier that invalidates CPU caches, forcing subsequent reads to pull from main memory instead. This barrier pair establishes the happens-before guarantee: any write that precedes a volatile write in program order shows up correctly for any thread that later reads that volatile field.

Transitivity turns this into a chain. Imagine a thread writes to a regular field, then writes to a volatile flag. A second thread reads the volatile flag and sees the new value. That second thread also sees the regular write, even though it never touched the volatile field directly. Program order links the regular write to the volatile write, the volatile field rule links the volatile write to the volatile read, and transitivity stitches the whole chain together. This is exactly how double-checked locking works and why the producer-consumer pattern leans on volatile flags.

The cost difference matters on weakly ordered architectures. x86 and x86-64 have a strong memory model where stores are already ordered, so the JVM mostly skips barriers for volatile. ARM64 is the opposite — the JVM has to emit full fence instructions to guarantee ordering, which is noticeably more expensive. The JMM hides these differences from you, so your code runs the same everywhere, but the hardware underneath does matter.

Final Field Semantics

Final fields get special treatment in the JMM. The JVM guarantees that once a constructor finishes, all threads see the correctly initialized values of final fields.

Why Final Fields Are Special

Without special handling, a partially constructed object could be visible to another thread if a reference to the object escapes before the constructor completes.

public class FinalFieldExample {
    private final int value;
    private final String name;
    private final List<String> items;

    public FinalFieldExample(int value, String name) {
        this.value = value;
        this.name = name;
        this.items = new ArrayList<>();
        items.add("initialized");
    }

    // The reference 'this' should NEVER escape during construction
    // Bad example - DON'T do this:
    // public static FinalFieldExample instance;
    // public FinalFieldExample(int v) {
    //     instance = this; // ESCAPE - 'this' escapes!
    // }
}

Safe Publication Patterns

For safe publication of objects with final fields:

1. Use final fields: The JVM provides special guarantees
2. Use static initializer: Static fields are initialized during class loading
3. Use final reference + final fields: Combining both provides strongest guarantees
4. Use synchronized or volatile: These establish happens-before guarantees

// Safe publication using static holder pattern
public class SafePublication {
    private final int value;
    private final String description;

    public SafePublication(int value, String description) {
        this.value = value;
        this.description = description;
    }

    // Safe publication via static initializer
    private static final SafePublication INSTANCE = new SafePublication(42, "Meaning of life");

    public static SafePublication getInstance() {
        return INSTANCE;
    }
}

Architecture Diagram

Here’s how the happens-before relationships fit together:

Synchronized Block Happens-Before

When a thread exits a synchronized block, it unlocks the monitor. The monitor lock rule says this unlock happens-before any subsequent lock on the same monitor by another thread. The diagram above shows Thread 1 writing a variable and then unlocking, while Thread 2 locks and reads. Because of the happens-before link between unlock and lock, Thread 2 sees the value Thread 1 wrote, even though the threads never run at the same time.

The guarantee covers every memory operation before the unlock, not just ones touching the locked object. Write to three fields inside the block and all three are visible to the next thread after it acquires the lock. That is why synchronized fixes data races. It also creates a visibility barrier that pushes the whole memory state across to the next thread, not just the fields that happen to be named in the synchronized statement.

graph TB
    subgraph Thread1
        A1[Write to Variable] --> A2[Unlock Monitor]
    end

    subgraph Thread2
        B1[Lock Monitor] --> B2[Read Variable]
    end

    A2 -.->|happens-before| B1

Volatile Field Happens-Before

The volatile field rule is narrower than the monitor lock rule but still useful. A write to a volatile field happens-before every subsequent read of that same field by any thread. The diagram above shows this: Thread 1 writes to a volatile flag, and Thread 2 reads it later. The arrow is the happens-before guarantee carrying write side effects across.

Transitivity is the interesting part. Thread1 writes a regular variable first, then writes to a volatile field. Thread 2 reads the volatile field and sees the regular write too. Program order links the regular write to the volatile write, the volatile field rule links the volatile write to the volatile read, and transitivity closes the chain. This is exactly how double-checked locking works with volatile: the reference write is ordered before the volatile write that publishes it, so any thread reading the reference through a volatile read also sees the fully constructed object.

graph TB
    subgraph VolatileExample
        C1[Write to Volatile] --> C2[Read Volatile]
    end

    C1 -.->|happens-before| C2

Final Fields Safe Publication

Final fields play by different rules. The JMM guarantees that once a constructor finishes and the reference to the object escapes through a safe mechanism, all final fields are visible in their correctly initialized states to every thread. The diagram above shows this: the constructor completes, then the reference is published, and those two steps together constitute safe publication.

Safe publication means the reference escapes in one of a few specific ways: a static field initializer, a final field, a synchronized block, or a volatile field. When the reference goes out through any of these, the JVM plants a memory barrier that makes all final field writes visible. Without safe publication, even final fields can show up as their default zero values if the reference escapes early through a this-escape bug during construction.

graph TB
    subgraph FinalFields
        D1[Constructor Completes] --> D2[Reference Published]
    end

    D1 -.->|safe publication| D2

Production Failure Scenarios

Scenario 1: Double-Checked Locking with Non-Volatile Reference

// BROKEN - classic double-checked locking failure
public class BrokenSingleton {
    private static Singleton instance;

    public static Singleton getInstance() {
        if (instance == null) {                 // First check
            synchronized (BrokenSingleton.class) {
                if (instance == null) {         // Second check
                    instance = new Singleton(); // Problem here!
                }
            }
        }
        return instance;
    }
}

Failure: The instance = new Singleton() operation involves multiple steps (allocate memory, call constructor, assign reference). Without volatile, another thread might see a non-null instance but with uninitialized fields.

Fix: Make instance volatile:

private static volatile Singleton instance;

Scenario 2: Publication via Constructor Argument

// BROKEN - unsafe publication
public class UnsafePublisher {
    private final int value;

    public UnsafePublisher(Consumer<Integer> consumer) {
        this.value = computeValue();
        consumer.accept(this.value); // 'this' escapes!
    }
}

Failure: The this reference escapes during construction, allowing another thread to observe the object in a partially constructed state.

Fix: Never pass this to another object during construction.

Scenario 3: Volatile for State Machine Without Atomic Transitions

// BROKEN - state transitions are not atomic
private volatile int state = 0;

public void transition() {
    if (state == 0) {
        // Another thread might also enter this block
        state = 1; // Race condition
        performTransition();
    }
}

Fix: Use synchronized or AtomicInteger for compound operations.

Trade-off Table

Approach	Visibility	Atomicity	Performance	Use When
No synchronization	None guaranteed	N/A	Best	Single-threaded only
synchronized	All memory ops	Mutual exclusion	Moderate overhead	Mutual exclusion needed
volatile	All memory ops	Single variable	Low overhead	Flag/state signals
Atomic* classes	All memory ops	Single operation	Low overhead	Counter, flags, references
final fields	Safe construction	Immutability	No overhead	Constants, immutable data

Implementation Snippets

Safe Counter with Multiple Fields

public class SafeCounter {
    private final Object lock = new Object();
    private long count = 0;
    private long lastUpdate = 0;

    public void increment() {
        synchronized (lock) {
            count++;
            lastUpdate = System.nanoTime();
        }
    }

    public long getCount() {
        synchronized (lock) {
            return count;
        }
    }
}

Flag-Based Shutdown with Volatile

public class VolatileShutdownFlag {
    private volatile boolean shuttingDown = false;

    public void initiateShutdown() {
        shuttingDown = true;
    }

    public boolean isShuttingDown() {
        return shuttingDown;
    }

    // Use in work loop
    public void runLoop() {
        while (!shuttingDown) {
            processNextTask();
        }
        cleanup();
    }
}

Safe Listener Registration

public class SafeListenerRegistration {
    private final List<Listener> listeners = new ArrayList<>();

    // Safe - no 'this' escape
    public void registerListener(Listener listener) {
        synchronized (listeners) {
            listeners.add(listener);
        }
    }

    // Safe publication via final field + synchronized access
    private final List<Listener> listenersCopy;

    public SafeListenerRegistration() {
        List<Listener> temp = new ArrayList<>();
        // populate temp
        this.listenersCopy = Collections.unmodifiableList(temp);
    }

    public List<Listener> getListeners() {
        return listenersCopy;
    }
}

Observability Checklist

When debugging concurrency issues related to the JMM:

• Is the field volatile if it accessed across threads without synchronization?
• Are all shared mutable fields properly synchronized or volatile?
• Does any code hold locks for longer than necessary?
• Is there a potential for lock ordering deadlocks?
• Are final fields being properly initialized before publication?
• Is ‘this’ reference escaping during construction?
• Are atomic operations truly independent (no read-modify-write races)?
• Can you verify happens-before relationships in your code paths?

Security Notes

Concurrency bugs can become security vulnerabilities:

• Time-of-check to time-of-use (TOCTOU): Checking a condition and acting on it is not atomic
• Uninitialized data exposure: Final field semantics prevent this if used correctly
• Order confusion attacks: Without happens-before guarantees, an attacker might observe incorrect operation ordering
• Side-channel timing attacks: Lock contention timing can leak information about sensitive operations

Always use secure coding practices combined with proper synchronization.

Common Pitfalls / Anti-Patterns

1. Assuming visibility without synchronization: A write in one thread may never be visible to another without happens-before guarantees
2. Using volatile for compound operations: volatile does not make i++ atomic
3. Nested locks on different objects: Can cause deadlocks if lock ordering differs across threads
4. Returning mutable objects from getters: Always return copies or immutable views
5. Starting threads in constructors: This escapes this before the object is fully constructed
6. Ignoring exception handling in concurrent code: Exceptions can leave locks in unexpected states

Quick Recap Checklist

• Happens-before guarantees ensure memory visibility across threads
• Synchronized provides mutual exclusion and happens-before for all memory operations
• Volatile ensures writes are visible to subsequent reads of the same field
• Final fields provide safety guarantees when properly constructed
• Never let this escape during construction
• Use atomic classes for compound operations on counters and flags
• Double-checked locking requires volatile on the reference
• Transitivity extends happens-before across thread boundaries

Interview Questions

Further Reading

• Thread Lifecycle: States, start, yield, sleep, interrupt, join — JMM thread state interactions and happens-before guarantees
• Java Synchronization Primitives — Lock-based coordination and monitor semantics
• JSR 133: Java Memory Model Specification — The official JMM specification
• Oracle Java Language Specification, Chapter 17 — Formal happens-before rules
• Advanced Java & JVM Internals Roadmap — Parent roadmap for this topic

Conclusion

You now understand happens-before guarantees. Apply this knowledge to ensure your concurrent code is correct: use volatile for simple flags, synchronized for compound operations, and never let this escape during construction. When designing concurrent classes, sketch out the happens-before chain to verify that writes in one thread are visible to reads in another. Continue with Thread Lifecycle: States, start, yield, sleep, interrupt, join to understand how thread state transitions interact with the JMM.