Java Memory Model
- It’s not physically real
- Defines: access rules for various variables
- Can be understood as “process abstraction” of read and write access to a particular memory or cache under a particular protocol
- The goal: to mask the differences in memory access between hardware and OS, so that all Java programs can achieve “consistent memory access” on different platforms.
Understand the variables
Variables in the access rules refer to “instance fields”, “static fields”, “array objects”.
Does not include “method parameters” and “local variables” (thread private, no need to share)
Hardware efficiency and consistency
We know that instruction reorders occur at many levels, such as CPU instruction rebeats, in-time compiler instruction reorders, and so on
Note that bytecode files generated by.class file compilation do not instruct reordering
Java memory model
The memory model
An abstraction of the memory or cache read/write access process under a particular protocol
Java memory model
Working memory holds local copies of variables in main memory in threads
Threads do not directly access shared memory; all reads and writes to variables need to go through working memory
purpose
Shielding the differences of different hardware and OS, providing a unified memory model, so that Java programs can achieve consistent memory access effect on different platforms
methods
Define access rules for various variables in a program
understand
There is no relationship between the JMM and the JVM runtime data area
From a hardware and OS perspective, main Memory corresponds to Memory, while working Memory corresponds to Cache and Register
Interaction between working memory and main memory
operation
There are eight atoms of nondivisible operations, respectively
-
Lock marks a variable as thread-exclusive
-
Unlock releases a variable from its thread-exclusive state
-
Read main memory is transferred to the thread’s working memory
-
Load accepts variables transferred from main memory and places them in a copy of the variables
-
Use copies of variables in working memory are passed to the execution engine
-
Assing assigns values accepted from the execution engine to a copy of the variables in working memory
-
A copy of the variables in write working memory is transferred to main memory
-
Store Main memory accepts values transferred and places them in variables in main memory
The rules
-
Read/Load and store/write must occur at the same time
-
Can’t drop assign (can’t assign but not store)
-
Can’t assign a store without a reason
-
New variables can only be created in main memory (can’t use/store without assign/load)
-
A variable can only be locked more than once by the same thread
-
You need to execute the same number of unlock commands to unlock it
-
Shared memory must be synchronized before unlock
-
You cannot unlock a variable that is locked by another thread
Long and double
We said earlier that operations on variables must be atomic, but for 64-bit variables like long and double, two instructions are allowed
happens-before
The equivalent of the Java memory model is the happens-before rule,
The volatile keyword
The volatile keyword is the lightest synchronization mechanism. It does two things: disallow instruction rebeats and ensure visibility of variables between threads. It should be noted that it does not guarantee atomicity of operations on variables
Each 'use' is preceded by 'read' and 'load' and 'assign' is followed by 'store' and 'write' to disallow instruction reorderingCopy the code-
Disable command rebeats
This is expressed As within-thread as-if-serial Semantics
Memory barriers are added to the bytecode file so that those behind the barrier are not reordered to the front
-
visibility
This is achieved by constraints on the order and continuity of operations in the above instructions, which only guarantees visibility, not atomicity
Atomicity, visibility, order
atomic
Access to basic data types is atomic
Synchronized guarantees atomicity
visibility
Another thread can immediately see the result of the current thread’s changes to the variable
Volatile, synchronized, and final all guarantee visibility
order
It represents an order within a thread and an unordered order between threads
Volatile and synchronized ensure order
Happens-Before
The happens-before principle is used to determine whether a thread is safe
- Procedural order rule
In a program execution flow, an action written earlier takes place before an action written later
- Pipe lock rules
An UNLOCK operation precedes a subsequent lock operation
- Volatile variable rule
Writes to volatile variables occur first after reads to volatile variables
- Thread start rule
The start() method of the Thread object precedes every action of the Thread
- Thread termination rule
All operations in a thread precede the termination operation on that thread
- Thread interrupt rule
A call to the interrupt() method on a thread occurs first when the interrupted thread’s code detects that an interrupt has occurred
- Object finalization rule
The completion of an object’s initialization occurs first at the start of its Finalize () method
- transitivity
A -> B, B -> C => A -> C
There is no causal relationship between time order and antecedent principle
thread
Implementation of threads
-
Implemented using kernel threads
-
1:1.
-
One user thread corresponds to one kernel process
-
Thread switching is expensive
-
-
Implemented using user threads
-
1 ：N
-
Multiple user threads correspond to one user process
-
The kernel does not feel the presence of the user thread
-
The switch is completed in user mode with low switching cost
-
The application implements thread switching itself
-
-
User process and lightweight process hybrid implementation
- M: N
Java thread
The HotSpot VIRTUAL machine maps a virtual machine thread to an operating system thread, and scheduling is done by the operating system (the virtual machine stack and the local method stack are also done together)
The Java Virtual Machine Specification does not specify how Java threads are implemented
