What do you understand by Java Memory Model?

Carvia Tech | 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.
}

Multithreading and Concurrency:
  1. Java 8 Parallel Stream custom ThreadPool
  2. Java Concurrency Interview Questions
  3. ConcurrentModificationException in Java
  4. What is purpose of Collections.unmodifiableCollection
  5. Removing elements while iterating over a Java Collection
  6. ThreadLocal with examples in Java
  7. Design an Immutable class that has an java.util.Date member
See all articles in Multithreading and Concurrency
Top articles in this category:
  1. What is volatile keyword in Java
  2. What is purpose of Collections.unmodifiableCollection
  3. What is Double Checked Locking Problem in Multi-Threading?
  4. can we write a java method that swaps two integers
  5. How will you implement your custom threadsafe Semaphore in Java
  6. What is polymorphism in Java OOP
  7. Design an Immutable class that has an java.util.Date member

Find more on this topic:

Recommended books for interview preparation:
Buy interview books

Java & Microservices interview refresher for experienced developers.