An easy explanation of Java Memory Model

First things first - Why is it being called Java Memory Model? 

The Java application runs inside a JVM (Java Virtual Machine) . This JVM is a computer in itself. Some of the processes like Garbage Collection run in it. 

What is memory and does JVM has a memory of its own?

We have studied, computers have CPU and memory (external or internal). CPU has some memory of its own - registers and CPU cache. The registers are closer to the CPU, so working with them is faster. Remember, all the processing is done in the CPU itself. The another level of memory which is called CPU cache is larger than register memory but slower than it. 

So, the rule states farther the memory from the CPU, slower is the processing. Why? Because the data is brought from any memory to the CPU cache, processed and then changes are written to it. The CPU cache is divided into blocks itself. So, any read/write to/from RAM is in blocks. So, CPU cache is concurrent.

Further, multi-core CPU can run multiple applications or threads simultaneously. In a 2-core CPU system, 2 threads can run simultaneously and so on. Until these are different applications not using a shared resource, it is fine but when the resource is being shared, proper utilization and assuring the universal change visibility to that resource becomes the key. Lets take an example -

If a thread writes to a memory in CPU cache and another thread reads from RAM. So, we can not justify that second thread got the same value for that resource from the RAM which is available after update inside CPU cache. It is highly possible that that particular cache block was not written to the RAM by the JVM before another thread had read the value of that resource from RAM.

This is why we need to deal with concurrency.

JVM uses the memory from our underlying architecture. Physically it has no separate memory but the term JVM memory means the memory being used by JVM from the underlying memory architecture.

JVM memory model means how is the memory allocated to JVM being used internally by it?

It allocates it in 2 ways - Stack space and heap space. Both are on the same underlying memory but the way they are used is different. 

Stacks contain the method copies of individual threads with local variables in it. So, if 2 threads call the same method, then they will have 2 different stacks with different copies of local variables inside that method. Sequential method calls are put in this stack on top of another.

Heap space is the area where all the objects are allocated. It does not matter whether the object is created inside a thread's local method or is a member variable of an object or is a referenced object. It is allocated on the heap space. Static member variables are also allocated on the heap space. 

We can easily say that it is necessary to allocate memory efficiently. That is why we assign some parameters like Xmx (Max heap size), Xms (Initial Heap Size) to make sure that the applications' performance in terms of memory is efficient and we do not get Out Of Memory Errors. If we get OOMs, we can be pretty sure that either our heap size needs to be increased or there is some memory leak in our application. In the latter case, analyzing a heap dump for unusually large size objects can provide clue where the memory might be leaking.

The above explanation highlights how the JVM uses memory from the underlying architecture and how it uses it, why is it needed to use it this way, what are the problems in multi-core systems? 

I hope to provide some easy explanation.