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. What will happen if we don't synchronize getters/accessors of a shared mutable object in multi-threaded applications
  2. ThreadLocal with examples in Java
  3. What is AtomicInteger class and how it works internally
  4. Discuss internals of a ConcurrentHashmap (CHM) in Java
  5. Can the keys in HashMap be mutable
  6. What is Immutable Class in Java
  7. Difference between Callable and Runnable Interface
See all articles in Multithreading and Concurrency
Top articles in this category:
  1. What is volatile keyword in Java
  2. What is does Collections.unmodifiableCollection do
  3. What is Double Checked Locking Problem in Multi-Threading?
  4. How will you implement your custom threadsafe Semaphore in Java
  5. How will you handle ConcurrentModificationException in Java
  6. Troubleshooting Deadlock in Java
  7. What is Immutable Class in Java

Find more on this topic:
Core Java image
Core Java

Core Java - OOP Concepts, Garbage Collection, Multi-threading, Collections Framework, Java 8 Features, Lambda Functions, Streams.

Last updated 1 week ago

Recommended books for interview preparation:

This website uses cookies to ensure you get the best experience on our website. more info