Java memory model of dead-knock concurrency

Java memory model Jmmjava memory model definition

The previous article we talked about CPU cache consistency and memory barrier issues. So Java as a cross-platform language, its implementation to face different underlying hardware systems, design a middle-tier model to shield the underlying hardware differences, to the upper-level developers a consistent use of the interface. The Java memory model is a middle-tier model that shields programmers from the underlying hardware implementation details and supports most mainstream hardware platforms.

Java memory mode: the Java memory model is how Java Virtual machine memory works with computer memory (RAM). The Java Virtual machine is a model of the entire computer, so this model naturally contains a memory model. It can also be said that JMM is a Java Virtual machine memory usage specification.

In layman's terms, it is the access rules that describe the various variables in Java (thread-shared variables) and the underlying details of storing variables into memory and reading variables from memory in the JVM.

The Java memory model specifies how and when different threads can see the values that other threads write to shared variables, and how to synchronize access to shared variables if necessary .

Note: TheJava memory model is not real, he is just a mapping of the physical RAM model.

Introduction to the Java memory model

Two concepts of memory allocation in the JVM:

1. Stack (Stack)
   Features: Fast access speed, determination of object life cycle, data size determination.
   Store data: Base type variable, object reference (handle)
   Location: Cache, register, write buffer.

2. Heap (heaps)
   Features: Slow access speed, dynamic allocation at runtime, uncertain life cycle of objects, garbage collection.
   Store Data: Objects
   Location: main memory, Cache

In theory, all stacks and heap are stored in physical main memory, but as the CPU operation copies of its data may be cached or register held, the data that is held conforms to the consistency protocol .

Storage mode

As mentioned above, an object is stored on the heap, and the method that belongs to the object is stored on the stack with the method's member variable. the member variables of an object are stored on the heap as the object itself , whether the object type is a reference type or a base type. Static variables and object class definitions are stored on the heap.

concurrency reason

Objects stored on the heap can be accessed by the stack that holds the object reference. You can access the object, you can also access the member variables in the object. when two threads access an object at the same time, each thread has a private copy of the object member variable .

This is just a rough allocation of the Java memory model. For detailed memory allocation please see
JVM Memory Management Overview

Java memory model and system memory model

Let's take a look at a diagram:

In the system memory architecture, there is no stack, heap (stack) concept, only register (register), cache, main memory (RAM, main memories). In theory, all stacks and heaps are stored in main memory, but a copy of their data can be cached or held as the CPU operations. The data held complies with the Cpu-cache conformance protocol .

CPU memory model, consistency protocol can refer to the previous article dead-knock concurrent CPU Cache Consistency Protocol (MESI)

Java memory model Abstract structure diagram

main memory : All variables are saved.

Shared variables : If a variable is used by more than one thread, the variable will have a copy in the working memory of each thread, which is a shared variable.

such as member variables, static variables, array elements, and so on.

working memory : Each thread has its own working memory, the thread is exclusive, and the thread is saved with a copy of the variable (a copy of the main memory share variable). Working memory is responsible for interacting with threads and also for interacting with main memory. For higher efficiency the Java virtual machine, the hardware system may make the work within the priority of the register, the cache.

JMM has made the following two provisions for the operation of shared memory:

• All operations of a thread on shared memory must be done in its own working memory and cannot be read and written directly from the main memory.
• Different threads cannot directly access variables in the working memory of other threads, so the value delivery of shared variables needs to be done through main memory.

The root cause of Java concurrency problems

Assume that thread A and thread B colleagues access the member variable x of an object. When thread a needs to manipulate variable A, a copy is copied to the working memory of thread A.

Thread B also accesses the variable a when thread A is not finished executing

However, thread A and thread B operate on a copy of the variable in their own workspace. The copy in thread A matches the copy in the middle of thread B is not visible. If the A thread is the first to complete the task and write back to main memory. Then the operation of thread B is the dirty data operation after use. If B also writes back to main memory then thread A's task will be lost.

In order to ensure the accuracy of the program, we need to add additional synchronization operations when concurrency occurs.

Java memory Model-eight synchronous operation procedures between memory

We then focus on the variable reading from main memory to working memory and then synchronizing back to the details of the working memory, which is the interaction protocol between the main memory and the working memory. The Java memory model defines the following 8 actions to complete, all of which are atomic operations (except for variables of type long and double).

lock: A variable that acts on the main memory and marks him as a thread-exclusive variable.

The usual lock is that when a thread is in use, other threads must wait for the thread task to complete before they can continue to perform their tasks.

unlock (unlock): A variable that acts on the main memory, unlocks a variable, and a variable that is unlocked can be locked by another thread.

Unlock the lock after execution is complete.

read: A variable that acts on the main memory, transferring the value of a variable from main memory to the working memory of the thread for subsequent load actions to use.

Reads from main memory into working memory.

load (load): Puts the value of the variable that the read operation obtains from main memory into a copy of the variable in the working memory.

Assigns a value to a copy in working memory.

use: Passes the value of a variable in the working memory to the execution engine, which is used whenever the virtual opportunity goes to an instruction that uses a variable.

Called when the value is read during program execution.

Assign (Assignment): A variable that acts on the working memory, assigning a variable that is received from the execution engine to the working memory, and performs this operation whenever the virtual opportunity is assigned to a byte-code instruction that assigns a value to the variable.

Assigning a new value after the operation is completed to a variable in working memory is equivalent to modifying a variable in working memory.

Store: A variable acting on a working memory that transfers the value of a variable in the working memory to the main memory for subsequent write operations.

The value is removed from the variable and written to the working memory.

write: A variable that acts on the main memory, which puts the value of a store operation's variable from the working memory into a variable in the main memory.

Writes the value in the working memory back to main memory.

Read execution steps

Write execution steps

Operation rules

• One of the read and load, store, and write operations is not allowed to appear separately, that is, a variable is not allowed to read from the main memory but the working memory is not accepted, or from the working memory initiated writeback but the main memory does not accept the situation.

• A thread is not allowed to discard its most recent assign operation, that is, the variable must be synchronized back to main memory after it has changed in working memory.

• A thread is not allowed to synchronize data from the working memory of the thread back to main memory for no reason (no assign operation has occurred).

• A new variable can only be "born" in main memory, does not allow direct use of a variable that is not initialized (load or assign) in working memory, in other words, the Assign and load operations must be performed prior to implementing a use and store operation on a variable.

• A variable allows only one thread to lock it at the same time, but the lock operation can be repeated multiple times by the same thread, and the variable will be unlocked only after performing the same number of unlock operations, after performing the lock multiple times.

• If you perform a lock operation on a variable, the value of this variable in the working memory will be emptied, and the value of the variable initialized by the load or assign operation needs to be re-executed before the execution engine uses the variable.

• If a variable is not locked by the lock operation beforehand, it is not allowed to perform a unlock operation on it, nor is it allowed to unlock a variable that is locked by another thread.

Review 1. The Java memory model is a specification that specifies how and when different threads can see the values that other threads write to shared variables and how to synchronize access to shared variables when necessary. The 2.java memory model requires that the call stack and local variables be stored on the thread stack, and the objects reside on the heap. The communication between threads must go through main memory. 3. Defines the eight operations for synchronization and the rules to be followed when using these eight operations.

Java memory model of dead-knock concurrency