The Java memory model

When you execute a concurrent application in a computer with several cores or processors, you can have a problem with memory caches. They are very useful to increment the performance of the application, but they can cause data inconsistency. When a task modifies the value of a variable, it's modified in the cache, but it's not modified in the main memory immediately. If another task reads the value of that variable before it's updated in the main memory, it will read the old value of the variable.

Other problems that may exist with concurrent applications are the optimizations introduced by the compilers and code optimizer. Sometimes, they reorder the instructions to get a better performance. In sequential applications, this doesn't cause any problems, but in concurrent applications it can provoke unexpected results.

To solve problems such as this, programming languages introduced memory models. A memory model describes how individual tasks interact with each other through memory and when changes made by one task will be visible to another. It also defines what optimizations of code are allowed and under what circumstances.

There are different memory models. Some of them are very strict (all of the tasks always have access to the same values) and others are less stringent (only some instructions update the values in the main memory). The memory model must be known by the compiler and optimizer developers, and it's transparent to the rest of the programmers.

Java was the first programming language that defined its memory model. The original memory model defined in the JVM had some issues, and it was redefined in Java 5. That memory model is the same in Java 8. It's defined in JSR 133. Basically, the Java Memory Model defines the following:

• It defines the behavior of the volatile, synchronized, and final keywords.
• It ensures that a properly synchronized concurrent program runs correctly on all architectures.
• It creates a partial ordering of the volatile read, volatile write, lock, and unlock instructions denominated as happens-before. Task synchronization helps us establish the happens-before relations too. If one action happens-before another, then the first is visible to and ordered before the second.
• When a task acquires a monitor, the memory cache is invalidated.
• When a task releases a monitor, the cache data is flushed into the main memory.
• It's transparent for Java programmers.

The main objective of the Java memory model is that the properly written concurrent application will behave correctly on every Java Virtual Machine (JVM) regardless of operating system, CPU architecture, and the number of CPUs and cores.