JMM Synopsis

The Java Memory Model (JMM) may be seen as an extension of the basic within-thread expression and statement evaluation rules described in the bulk of the Java Language Specification (JLS). For example, JLS expression rules state that a given thread evaluates any expression left to right. The JMM provides additional rules governing whether the "memory actions" in one or more threads of a program may be performed in parallel or out of order.

Memory actions are reads, writes, locks and unlocks, along with operations on java.util.concurrent.atomic objects. A write corresponds to the assignment of a field that modifies (only) that field, and a read obtains a value from some write that does not happen after this read. Reads and writes for all kinds of fields (array elements also behave as fields for these purposes) except non-volatile longs and doubles are atomic, so reads never return the values from partially completed writes. Lock and unlock actions are entries and exits of synchronized blocks or methods, or explicit lock() and unlock() operations on java.util.concurrent.locks objectss.

The JMM is defined in terms in terms of a happens-before relation that provides ordering rules for the effects of memory actions. Memory actions in different threads may in general be performed in any order. But if action A happens-before action B, then compilers, processors, and memory subsystems must preserve the ordering of their effects. For example, if A is a write and B is a read of the field written, and the pair fall under the happens-before relation, and there are no other writes, then the read in action B must return the value written in action A. If the pair does not fall under this relation, then the read might or might not return this value. Perhaps a better name for this relation is "must happen before". Actions that are not in this relation might or might not occur in some particular order; but those that do must occur in the given order.

The happens-before relation extends the JLS within-thread expression and statement evaluation rules, so these rules are at all times honored, consistently across all threads. Rigorously specifying what is meant by "consistently" in cases that entail apparent circularities and the like turns out to be challenging. See JLS chapter 17 for these and other details, many of which describe minimal properties of code that is not correctly synchronized, as well as other corner cases that are best avoided. More relevantly, the following rules derived from the specification may be of use when ensuring that code is correctly synchronized.

Initialization

• The initial action for any field is a write of its default (zero or null) value that happens-before any reads of this field by any thread.
• The write to a static final field happens-before any read of this field by any thread. (There are special exceptions for System.in, out, and err.)
• The write to a non-static final field by a thread happens-before any subsequent write of a reference to the new object with this field by that thread.

• An unlock or volatile write to a field happens-before any subsequent lock of that lock or volatile read of that field.
• A volatile read or lock by a thread happens-before any subsequent memory action by that thread.
• Any memory action by one thread happens-before any subsequent volatile write or unlock by that thread, with respect to any other thread that reads the same volatile field or locks the same lock.
• The first read of a reference to an object by a thread happens-before any subsequent read by that thread of any of the object's final fields.

• The effects of a java.util.concurrent.atomic get() operation are the same as a volatile read, and those of a set() are the same as a volatile write.
• A weakCompareAndSet by a thread happens-before any subsequent access to that atomic field by that thread.
• The effects of a compareAndSet, along with other atomic read-and-update methods, fall under the memory rules for a volatile read followed by a write.

• Any write by a thread performed prior to invoking Thread.start() for a new Thread happens-before those of any reads of these written fields by that new Thread.
• Any write by a thread happens-before termination of that thread. (Another thread can only reliably detect termination by using Thread.isAlive() or Thread.join().)