The Java Memory Model (JMM) defines visibility and ordering guarantees in multithreaded programs; 1. The happens-before relationship ensures that writes are visible to other threads when established through rules like program order, monitor locks, volatile variables, thread start/join, and transitivity; 2. Without synchronization, threads may not see updated values due to caching or reordering; 3. synchronized blocks provide mutual exclusion and visibility; 4. volatile variables ensure direct memory access and prevent reordering; 5. final fields enable safe publication of immutable objects; 6. Common misconceptions include underestimating the role of synchronization for visibility and assuming atomicity for long/double without volatile; always establish a happens-before link between writes and reads in concurrent code to ensure correctness.

The Java Memory Model (JMM) is a critical but often misunderstood part of the Java platform. It defines how threads interact through memory and what guarantees are provided for shared data access in a multithreaded environment. Understanding the JMM is essential for writing correct, high-performance concurrent code — especially when dealing with low-level concurrency constructs or trying to reason about visibility and ordering of operations across threads.

Let’s break down the JMM and its key guarantees in practical terms.

What Is the Java Memory Model?

The Java Memory Model is not about heap or stack layout — it’s a specification that describes how Java threads interact with memory, particularly with respect to shared variables. It defines the conditions under which a thread is guaranteed to see a value written by another thread.

Without the JMM, modern hardware optimizations like CPU caches, out-of-order execution, and compiler reordering could make multithreaded programs unpredictable and non-portable. The JMM provides a consistent abstraction over these underlying complexities.

At its core, the JMM answers two key questions:

• When does a write to a variable by one thread become visible to another thread?
• In what order do memory operations appear to execute across threads?

Key Concepts: Happens-Before, Visibility, and Ordering

The central mechanism the JMM uses to provide guarantees is the happens-before relationship. This is not a timing guarantee — it’s a partial ordering of operations that ensures visibility and prevents certain reorderings.

If one action happens-before another, then the first is guaranteed to be visible to and ordered before the second.

Here are the primary rules that establish happens-before relationships:

• Program order rule: Each thread has a happens-before relationship between actions in the order they appear in the code.

  int a = 1;     // happens-before
  int b = 2;     // this

• Monitor lock rule: An unlock on a monitor (e.g., exiting a synchronized block) happens-before every subsequent lock on the same monitor.

  synchronized(lock) {
      data = 42;  // written under lock
  } // unlock → happens-before next lock

• Volatile variable rule: A write to a volatile variable happens-before every subsequent read of that same volatile variable.

  volatile boolean ready = false;
  
  // Thread 1
  data = 100;
  ready = true;  // volatile write
  
  // Thread 2
  if (ready) {   // volatile read
      System.out.println(data); // guaranteed to see 100
  }

• Thread start rule: A call to Thread.start() happens-before any actions in the started thread.

• Thread join rule: All actions in a thread happen-before the return from that thread’s join() method.

• Transitivity: If A happens-before B, and B happens-before C, then A happens-before C.

These rules allow you to build chains of visibility across threads without explicit synchronization every step of the way.

The Problem: Visibility Without Synchronization

Consider this example:

// Shared variables
int data = 0;
boolean ready = false;

// Thread 1
data = 1;
ready = true;

// Thread 2
while (!ready) { }
System.out.println(data);

You might expect this to print 1. But without synchronization, there is no guarantee that Thread 2 will ever see the updated value of ready, or that when it does, it will see the updated data.

Why?

• The compiler or CPU might reorder the writes in Thread 1 (ready = true before data = 1).
• Thread 2 might cache ready in a register and never re-read it.
• Even if ready becomes true, data might still be 0 due to lack of visibility.

This is where the JMM steps in — it says: unless you use synchronization mechanisms defined by the model, you get no visibility guarantees.

How Synchronization Provides Guarantees

The JMM gives you tools to establish happens-before relationships. Here’s how different constructs help:

1. synchronized Blocks

Using synchronized ensures:

• Mutual exclusion.
• Visibility: All writes before releasing a lock are visible to any thread acquiring the same lock.

synchronized(this) {
    data = 1;
    ready = true;
}
// unlock → all prior writes visible to next synchronized block

2. volatile Variables

Declaring a variable volatile ensures:

• Reads and writes are directly to/from main memory (no local caching).
• No reordering of operations around the volatile access (via memory barriers).
• Write happens-before subsequent read.

Use volatile when you need visibility but not atomicity (e.g., flags).

3. final Fields and Safe Publication

The JMM gives special treatment to final fields. If an object is properly constructed (i.e., this doesn’t escape during construction), then:

• Once a thread sees a reference to the object, it also sees the correctly initialized values of its final fields.
• This enables safe publication without additional synchronization.

public class ImmutableObject {
    final int value;
    public ImmutableObject(int value) {
        this.value = value; // guaranteed visible
    }
}

This is why immutable objects are thread-safe by default when safely published.

Common Misconceptions

• "Synchronization is only for atomicity" → No. It’s also for visibility and ordering.
• "64-bit writes (long/double) are always atomic" → Only if not volatile. The JMM allows them to be split without volatile.
• "Local variables don’t need synchronization" → True for locals, but if they reference shared mutable state, the data still needs protection.

Practical Takeaways

To write correct concurrent Java code:

• Always use proper synchronization when sharing data between threads.
• Prefer higher-level concurrency utilities (java.util.concurrent) over raw synchronized or volatile when possible.
• Use volatile for simple state flags.
• Use final fields to simplify thread safety in immutable objects.
• Understand that no synchronization = no visibility guarantees, even if code “seems to work” in testing.

The Java Memory Model isn’t just academic — it’s the foundation of reliable concurrency in Java. While you don’t need to memorize every rule, knowing how happens-before works lets you reason about correctness and avoid subtle bugs that only appear under heavy load or on certain hardware.

Basically: if you're sharing data across threads, make sure there's a happens-before link between the write and the read — otherwise, you're coding by luck.

The above is the detailed content of A Deep Dive into Java Memory Model and its Guarantees. For more information, please follow other related articles on the PHP Chinese website!