Together with the description of single-threaded execution of code, the memory model provides the semantics of the Java programming language.
The original Java memory model developed in 1995, was widely perceived as broken,[1] preventing many runtime optimizations and not providing strong enough guarantees for code safety.
Synchronization between threads is notoriously difficult for developers; this difficulty is compounded because Java applications can run on a wide range of processors and operating systems.
The Java Memory Model (JMM) defines the allowable behavior of multithreaded programs, and therefore describes when such reorderings are possible.
It places execution-time constraints on the relationship between threads and main memory in order to achieve consistent and reliable Java applications.
By doing this, it makes it possible to reason about code execution in a multithreaded environment, even in the face of optimizations performed by the dynamic compiler, the processor(s), and the caches.
The runtime (which, in this case, usually refers to the dynamic compiler, the processor and the memory subsystem) is free to introduce any useful execution optimizations as long as the result of the thread in isolation is guaranteed to be exactly the same as it would have been had all the statements been executed in the order the statements occurred in the program (also called program order).