Java Memory Model

 

Java Memory Model (JMM)

A Java Memory Model describes how threads will interact through memory. 

A JMM defines how multithreaded programs must behave, and when reordering can happen by placing execution-time restrictions on how threads behave between each other and the main memory, and this is meant to result in a reliable, consistent working java application. 

It determines how the java virtual memory behaves with the computers Random Access Memory (RAM).

This plays vital in designing java concurrent applications.

The JMM used within a Java virtual model (JVM) works by dividing memory between each thread stack and the heap.

Thread-Stack

Every thread that is running within the Java virtual Machine will have its own thread stack and this is the only thread stack the thread will have access to.

The thread stack holds unique thread-information about the history of the methods that were called to reach the current point in the execution of that thread, and as the thread proceeds with its instructions, the history is updated. 

No other thread stack will be aware of any local variables of another thread stack, this would apply to another thread that may be running the same code within a thread-stack. 

The information stored in each stack will be inaccessible and independent to another's information, they can however share a copy to one another, its identity will remain bound to its originating stack.

The heap

The heap stacks all objects that were created in our Java application for ALL threads which hold the unique information for each thread stack.

Let's put this into perspective and take a look at the following diagram example

Java Memory Model Illustration

There are two threads illustrated above (Thread 1 and Thread 2) and the history of the thread is represented by the stages (Start, Task and End) coded in blue and also defined as the stack-thread, where variables were created and changed  for each thread, determined by the logic (Task) as well as output variables (End).

Once the task is complete, each task would have resulted in an object being created which holds the information of each variables value, particular to each thread. You can note that in Thread 1, it was one thread that ran two tasks, and assuming those tasks were the same, it would still output two objects containing the primitive and post-processed variables.

Each object is also coded in blue. 

The JMM is represented by everything that has been coded in blue, including the flow of all the information to the Heap, which contains memory of multiple thread objects, with their variable history, that occupies RAM.

The red arrows leading from the RAM is the JMM determining how the threads should behave, where they should be stored and when the stack needs to be re-ordered

Bear in mind that this is just the use of two threads, where in concurrency (multitasking), there are far more threads being run, and in order to maintain the consistency and get the expected result, the application would need to remember all types of information from checking whether the program is compatible, to the last state the program was in at the time it was shut down, whether it was shut down correctly, or whether it may have crashed, the states of threads at the time of execution, and so much more.

... and that's what a JMM is and what it does in a nutshell!

Thank you to wikipedia.com and jenkov.com for some awesome resources on helping me understand what a JMM is.