Detailed Explanation of Java Memory Model (JMM) and the happens-before Principle in Java

Detailed Explanation of Java Memory Model (JMM) and the happens-before Principle in Java

1. What is the Java Memory Model (JMM)?

The Java Memory Model (JMM) is a set of specifications that defines the rules for accessing shared variables in a multithreaded environment, ensuring visibility, ordering, and atomicity between threads. JMM abstracts away the differences in underlying hardware memory architecture, providing developers with consistent memory visibility guarantees.

Key Issues:

  • Visibility: Whether other threads can immediately see the latest value after one thread modifies a shared variable.
  • Ordering: The order of program execution may be reordered by the compiler or processor, requiring correctness to be guaranteed in a multithreaded context.
  • Atomicity: Whether operations on shared variables are uninterruptible (JMM primarily focuses on visibility and ordering; atomicity needs to be ensured through locks or atomic classes).

2. Abstract Memory Structure of JMM

JMM divides memory into two categories:

  1. Main Memory: The area where all shared variables are stored.
  2. Working Memory: The private memory exclusive to each thread, storing copies of the shared variables used by that thread.

Interaction Flow:

  • When a thread reads a shared variable, it first copies it from main memory to working memory (load operation).
  • After a thread modifies a shared variable, it needs to flush the value back to main memory (store operation).
  • If not flushed promptly, other threads may read stale values, leading to visibility issues.

3. Reordering and Memory Barriers

Why is Reordering Needed?

To improve performance, compilers and processors may reorder instructions (e.g., changing the execution order of code). However, in a multithreaded environment, reordering may break the correctness of the program.

Example:

// Initial state: a = 0, b = 0  
Thread1: a = 1; x = b;  
Thread2: b = 2; y = a;

Without synchronization measures, reordering may lead to x = 0, y = 0 (even though a=1 and b=2 have been executed).

Memory Barrier

JMM uses memory barriers to prohibit specific types of reordering:

  • LoadLoad Barrier: Ensures that the read operation before the barrier precedes the read operation after the barrier.
  • StoreStore Barrier: Ensures that the write operation before the barrier precedes the write operation after the barrier.
  • LoadStore Barrier: Ensures that the read operation precedes the write operation.
  • StoreLoad Barrier: Ensures that the write operation precedes the subsequent read operation (most expensive, e.g., automatically inserted after a volatile write).

4. The happens-before Principle

The happens-before principle is the core rule of JMM, used to describe memory visibility between operations. If operation A happens-before operation B, then modifications to shared variables made by A are visible to B.

Specific Rules:

  1. Program Order Rule: Operations within a single thread are executed in the order of the code (but may be reordered, requiring constraints from other rules).
  2. Volatile Variable Rule: A write to a volatile variable happens-before every subsequent read of that variable.
  3. Monitor Lock Rule: An unlock operation happens-before every subsequent lock operation on the same lock.
  4. Thread Start Rule: Thread.start() happens-before any operation in the started thread.
  5. Thread Termination Rule: All operations in a thread happen-before any other thread detects that the thread has terminated (e.g., via Thread.join()).
  6. Transitivity: If A happens-before B, and B happens-before C, then A happens-before C.

Example Analysis:

// Shared variables  
int x = 0;  
boolean volatile flag = false;  

Thread1:  
x = 1;          // Operation 1  
flag = true;    // Operation 2 (volatile write)  

Thread2:  
if (flag) {     // Operation 3 (volatile read)  
    System.out.println(x);  // Operation 4  
}

According to the happens-before rules:

  • Operation 1 happens-before Operation 2 (Program Order Rule).
  • Operation 2 happens-before Operation 3 (Volatile Variable Rule).
  • Operation 3 happens-before Operation 4 (Program Order Rule).
    By transitivity, the result of Operation 1 is visible to Operation 4, so x=1 is printed.

5. How to Ensure Visibility and Ordering?

Using the volatile Keyword

  • Prohibits reordering: Inserts a StoreStore barrier before a volatile write and a StoreLoad barrier after; inserts LoadLoad and LoadStore barriers after a volatile read.
  • Forces memory flush: Write operations are immediately synchronized to main memory, and read operations reload from main memory.

Using synchronized Locks

  • When locking, working memory is cleared, and variables are reloaded from main memory; before unlocking, working memory is flushed back to main memory.

Using final Fields

  • The initialization of final fields in a properly constructed object is visible to other threads (no synchronization required).

6. Summary

  • JMM addresses visibility and ordering issues in multithreaded environments by defining interaction rules between main memory and working memory, combined with the happens-before principle and memory barriers.
  • Developers need to understand the rules and correctly use tools like volatile, synchronized, etc., to avoid program errors caused by reordering or memory visibility issues.