Java Memory Model (JMM) ensures visibility and ordering of memory operations across threads. 1. JMM defines how threads interact through memory, focusing on visibility and predictable ordering rather than physical layout. 2. It guarantees that changes made by one thread are visible to others using constructs like volatile, synchronized, and explicit locks. 3. The happens-before relationship establishes formal ordering, ensuring visibility between actions such as monitor unlock/lock, volatile reads/writes, thread start/join. 4. JMM provides atomicity for certain operations and prevents reordering around synchronization boundaries. 5. Understanding JMM helps avoid race conditions, visibility issues, and instruction reordering by using proper synchronization and concurrency utilities.

Java Memory Model (JMM) is a specification that defines how threads in Java interact through memory. It's not about physical memory layout, but rather about visibility and ordering of memory operations across threads.

At its core, JMM helps ensure that changes made by one thread are visible to others, and that operations happen in a predictable order. This is especially important when dealing with shared variables and concurrent access.

Visibility and Shared Variables

In a multi-threaded Java application, each thread can have its own copy of a variable stored in local memory (like CPU cache). This means that if one thread updates a variable, the change might not be immediately visible to other threads.

The JMM ensures visibility through mechanisms like volatile, synchronized, and explicit locks (ReentrantLock). For example:

• When a variable is declared as volatile, any write to that variable will immediately flush the value back to main memory, and any read will fetch it directly from main memory.
• Using synchronized blocks or methods ensures that only one thread can execute the block at a time, and also guarantees that the thread sees the most up-to-date values of variables.

Without these constructs, you could end up with stale data or inconsistent states — which is why understanding visibility is crucial for writing correct concurrent code.

Happens-Before Relationship

One of the key concepts in JMM is the happens-before relationship. It’s a formal way to describe the ordering of actions in a multithreaded program.

If action A happens-before action B, then everything done in A (and all previous actions) is visible to B. Here are some common ways this relationship is established:

• Unlocking a monitor happens-before every subsequent lock of the same monitor.
• Writing to a volatile field happens-before every subsequent read of that field.
• The completion of a thread's run() method happens-before any code that observes the thread to be dead (e.g., via join()).
• A call to Thread.start() happens-before any actions in the started thread.

This model allows the JVM to optimize code execution while ensuring correctness when synchronization primitives are used properly.

Atomicity and Ordering Guarantees

Some operations in Java are atomic by default, such as reading or writing a reference or a 32-bit primitive (like int or float). However, operations like long or double may not be atomic on 32-bit architectures unless marked volatile.

The JMM also provides ordering guarantees, meaning that the compiler and processor are not allowed to reorder certain operations around synchronization boundaries. For example:

• Instructions inside a synchronized block won’t be moved outside of it.
• Volatile reads and writes act as memory barriers that prevent reordering.

These rules help maintain consistency without forcing developers to think too much about hardware-level details.

Practical Implications and Common Pitfalls

Understanding JMM helps avoid subtle bugs in concurrent programs. Some common issues include:

• Race conditions: Occur when two threads try to update a shared variable without proper synchronization.
• Visibility problems: One thread modifies a variable, but others don’t see the update.
• Instruction reordering: Code may execute in a different order than written due to compiler optimizations or CPU behavior.

To avoid these pitfalls:

• Use volatile for state flags that control thread behavior.
• Prefer higher-level concurrency utilities like java.util.concurrent.atomic or ExecutorService.
• Always use synchronization when multiple threads modify shared mutable state.

So that’s the gist of JMM — it’s not just about memory layout, but more about how Java ensures consistent and predictable behavior in concurrent environments. It might seem abstract at first, but once you get the hang of happens-before and visibility rules, it becomes easier to reason about threaded code.

The above is the detailed content of What is the Java Memory Model (JMM) in detail?. For more information, please follow other related articles on the PHP Chinese website!