What do you understand by Java Memory Model?

Upasana | May 19, 2019 | 2 min read | 698 views | Multithreading and Concurrency

Interviewer’s Intent

Interviewer’s Intent - Interviewer wants to understand if you can write concurrent code.

Java Memory Model defines the legal interaction of threads with the memory in a real computer system. In a way, it describes what behaviors are legal in multi-threaded code. It determines when a Thread can reliably see writes to variables made by other threads. It defines semantics for volatile, final & synchronized, that makes guarantee of visibility of memory operations across the Threads.

Let’s first discuss about Memory Barrier which are the base for our further discussions. There are two type of memory barrier instructions in JMM - read barriers & write barrier.

A read barrier invalidates the local memory (cache, registers, etc) and then reads the contents from the main memory, so that changes made by other threads becomes visible to the current Thread. A write barrier flushes out the contents of the processor’s local memory to the main memory, so that changes made by the current Thread becomes visible to the other threads.

JMM semantics for synchronized

When a thread acquires monitor of an object, by entering into a synchronized block of code, it performs a read barrier (invalidates the local memory and reads from the heap instead). Similarly exiting from a synchronized block as part of releasing the associated monitor, it performs a write barrier (flushes changes to the main memory) Thus modifications to a shared state using synchronized block by one Thread, is guaranteed to be visible to subsequent synchronized reads by other threads. This guarantee is provided by JMM in presence of synchronized code block.

JMM semantics for Volatile fields

Read & write to volatile variables have same memory semantics as that of acquiring and releasing a monitor using synchronized code block. So the visibility of volatile field is guaranteed by the JMM. Moreover afterwards Java 1.5, volatile reads and writes are not reorderable with any other memory operations (volatile and non-volatile both). Thus when Thread A writes to a volatile variable V, and afterwards Thread B reads from variable V, any variable values that were visible to A at the time V was written are guaranteed now to be visible to B.

Let’s try to understand the same using the following code.

Data data = null;
volatile boolean flag = false;

Thread A
-------------
data = new Data();
flag = true;  <-- writing to volatile will flush data as well as flag to main memory

Thread B
-------------
if(flag==true) { <-- reading from volatile will perform read barrier for flag as well data.
use data;  <--- data is guaranteed to visible even though it is not declared volatile because of the JMM semantics of volatile flag.
}