Understanding the Differences and Relationship Between JVM and JMM

1. JVM

The Java Virtual Machine (JVM) is a software‑based computer system that provides a complete hardware environment in an isolated runtime. The most common implementation is HotSpot, which is the default JVM for both JDK 6 and the widely used JDK 8.

JVM is the foundation for Java execution and enables the "write once, run anywhere" promise. The execution flow is: Java source code → bytecode → class loader loads the bytecode into the runtime data area → the execution engine translates bytecode into CPU instructions.

The runtime data area consists of thread‑shared and thread‑private regions:

Heap (shared) : the largest and most central memory area, storing object instances and arrays. All objects created with new are allocated here, and it is the primary target of garbage collection.

Method Area (shared) : a logical region defined by the JVM specification that holds class‑level data such as fully qualified class names, modifiers, constant pool, field and method information, and JIT‑compiled code caches.

Java Stack (thread‑private) : the core private area that models the memory layout of Java method execution. Each method call creates a stack frame that is pushed onto and popped from the stack.

Native Method Stack (thread‑private) : provides memory support for native methods (typically written in C/C++). Typical native methods include Thread.sleep() and Thread.start0().

Program Counter (thread‑private) : the smallest memory area, holding the address of the next instruction to execute; it is the basis of program flow control.

Thus the JVM is a concrete execution engine and memory manager that runs Java code and manages the physical partitioning of memory.

2. JMM

The heap is a shared region accessible by all threads. Modern CPUs add caches and compilers reorder instructions for speed, which introduces three classic concurrency problems: visibility, ordering, and atomicity. The Java Memory Model (JMM) defines a set of rules to solve these problems.

JMM stipulates that all variables reside in main memory, while each thread has its own working memory (caches, registers, etc.). Threads cannot read main memory directly; they operate on a local copy and synchronize changes back to main memory.

The core of JMM is the happens‑before relationship, which guarantees memory visibility rather than a simple temporal order. The eight happens‑before rules are:

Program order rule: within a single thread, earlier actions happen‑before later actions.

Monitor lock rule: unlocking a monitor happens‑before subsequent locking of the same monitor.

Volatile variable rule: a write to a volatile variable happens‑before any subsequent read of that variable.

Thread start rule: Thread.start() happens‑before any action in the started thread.

Thread termination rule: all actions in a thread happen‑before another thread detects its termination.

Thread interruption rule: an interrupt() call happens‑before the interrupted thread detects the interrupt.

Finalizer rule: the end of a constructor happens‑before the object's finalize() method.

Transitivity: if A happens‑before B and B happens‑before C, then A happens‑before C.

Volatile is the lightest‑weight synchronization mechanism in JMM; it uses memory barriers and cache‑coherence protocols to ensure visibility and ordering but does not guarantee atomicity. synchronized is the fundamental mutual‑exclusion mechanism; it employs monitor locks to provide atomicity, visibility, and ordering, serving as a general‑purpose tool for concurrent programming.

Summary

(1) The JVM is a concrete execution engine and memory manager that partitions memory and performs garbage collection; it is an actual running instance.

(2) The JMM is a specification—a set of rules and contracts—that defines how data is accessed and synchronized across threads to guarantee correctness.

(3) JVM implementations such as HotSpot must obey the JMM when designing their memory subsystems.