Java memory model

1. Introduction

The Java Memory Model is translated from the English Java Memory Model (JMM). The JMM is not as real as the JVM memory structure. It is only an abstract concept. Used to mask differences in memory access across hardware and operating systems to achieve consistent concurrency across Java programs.

The Java Memory model is often asked in a Java interview. This article will debunk the mystery of the Java memory model.

2. Abstract structure of Java memory model

Key problems to solve in concurrent programming:

  1. How do threads communicate with each other
  2. How do threads synchronize

Communication refers to the mechanism by which information is exchanged between threads. In command line programming, there are two communication mechanisms between threads: shared memory and messaging. In the shared memory model, threads share the common state of a program and communicate implicitly through the common state in write-read memory. In the concurrent model of messaging, there is no common state between threads, and threads must communicate explicitly by sending messages.

Synchronization is the mechanism in a program that controls the relative order in which operations occur between different threads. In the shared memory concurrency model, synchronization occurs explicitly.

Concurrency in Java is a shared memory model. Communication between Java threads is always implicit and completely transparent.

Java divides memory into two parts:

  • Main memory: stores instance fields, static fields, and array elements
  • Working memory: stores local variables, method definition parameters, exception handler parameters

The Java memory model stipulates that all variables are stored in the main memory, and each thread has its own working memory. The working memory of the thread stores a copy of the main memory of the variables used in the thread. All operations on variables must be carried out in the working memory of the thread, instead of reading and writing the main memory directly. Different threads cannot directly access variables in each other’s working memory, and the transfer of variables between threads requires data synchronization between their own working memory and main memory.

The JMM is used to synchronize data between working memory and main memory. It specifies how and when to synchronize data.

3. Implementation of Java memory model

Java provides a number of keywords related to concurrency, such as volatile, synchronized, final, concurren packages, and so on. These are the keywords that the Java memory model provides to programmers by encapsulating the underlying implementation.

When developing multithreaded code, we can directly use keywords like synchronized to control concurrency and never need to worry about underlying compiler optimizations, cache consistency, and so on. Therefore, the Java memory model, in addition to defining a set of specifications, provides a set of primitives that encapsulate the underlying implementation for developers to use directly.

4. JVM memory structure

In the interview, the interviewer asked me about the Java memory model, and I said JVM memory structure. A lot of people get confused about that, but it’s totally different, so here’s the JVM memory structure.

The JVM runtime memory region structure is described in the Java Virtual Machine Specification (Java SE 8) as follows:

  1. The above is the Java virtual machine specification. Different virtual machine implementations will vary, but generally adhere to the specification

  2. The method area defined in the specification is just a conceptual area that states what it should do. But it doesn’t say exactly where that zone should be. Therefore, there is a certain degree of freedom for different virtual machine implementations.

  3. Different versions of the method area are located in different locations. The above is a logical area, not a physical area in an absolute sense. In some versions of the JDK, method areas are actually implemented in the heap

  4. The runtime constant pool is used to store the various literal and symbolic applications generated at compile time. However, the Java language does not require constants to be generated only at compile time. For example, at run time, String. Intern also puts new constants into the pool.

  5. In addition to the JVM runtime memory described above, there is another area of memory available, which is direct memory. The Java Virtual Machine specification does not define this area of memory, so it is not managed by the JVM, but is allocated directly out of the heap using local method libraries.

  6. Heap and stack partitioning is also not absolute, as HotSpot’s JIT optimizes object allocation accordingly.

For a detailed comparison, see: JVM memory structure VS Java Memory Model VS Java object Model

5. Summary & References

summary

The JMM is a specification designed to address issues such as inconsistencies in local memory data, compiler reordering of code instructions, and out-of-order code execution by processors when multiple threads communicate through shared memory. The JMM designed keywords will be partially explained in a future article.

The resources

  • The Art of Concurrent Programming in Java
  • JVM memory structure VS Java memory model VS Java object model