JMM basics-computer principles

Calculate a+b
The CPU reads the memory 100ns once, and it takes 200ns to read a and b
CPU calculation only takes 0.6ns
Most of the time executing a+b is waiting to read memory
So the introduction of high-speed cache (first, second, third)
Multi-core CPU sharing L3

L1 is the fastest and the smallest capacity

In order to improve the running speed, cache is introduced
In order to make full use of cache, JMM was proposed

Java Memory Model (JMM)

Working memory, main memory, two abstract concepts
Working memory: Including CPU internal registers, cache, and part of main memory (RAM), a small part of which is in main memory
Main memory: a small part may be in registers and cache

If the variable count is accumulated
count is in main memory
When any thread wants to accumulate, it will put count in the thread's unique working memory, and each thread that operates count has a copy of count
The thread is only allowed to operate on the count in the thread's working memory, and is not allowed to directly manipulate the variables in the main memory
The working memory of each thread is exclusive
Heap memory is understood as main memory, and stack memory is understood as working memory

Concurrency security issues caused by JMM

VariableVisibility, atomicity
The initial value of count is 0
Two threads calculate count = count + 1
The result should be 2, but the result may be 1

The two threads do not know that the other side has modified the thread, and cannot see the other side’s modification of count, there is a visibility problem

How to solve the visibility problem?

volatile

1. Force a variable to be read from main memory
2. Whenever the variable is modified, it is forced to refresh to the main memory immediately

Volatile can only guarantee visibility

Volatile cannot solve our security problems. Volatile is only for forced reading and writing. The problem is that the calculation process is not an atomic operation.

Synchronized guarantees visibility and atomicity at the same time, and the strength of synchronized is greater than that of volatile
Volatile is the most lightweight synchronization mechanism provided by the JDK

A single read/write of a volatile variable can be regarded as using the same lock to synchronize these single read/write operations

The volatile variable itself has the following characteristics:
Visibility: Reading a volatile variable can always see (any thread) the last write to this volatile variable.
Atomicity: For anysingleThe read/write of volatile variables is atomic, but similar to volatile++complexThe operation is not atomic.

Pipeline and reordering:
cpu can execute multiple instructions at once

do(){
    int a = 5 ;
    int b = 6 ;
    int c = 7 ;
    int d = a ;
    if( b == 6){
      d = b;
    }
}

In our impression, the cpu is executed sequentially. After the introduction of pipeline and reordering, the cpu may execute all four at once, and may do the d = b before if (b == 6), and calculate the first Things are opened in memoryReorder cacheIf there is an if (b == 6), put the result of the reordering cache directly in it, not necessarily after the if

Intel cpu can support up to ten stages of pipelines, and can execute 10 instructions at the same time
Android ARM architecture three-stage pipeline, 3 instructions can be executed at the same time

Reordering changes the meaning of the order in which we write code. Single thread must meet our requirements, and multithreading may cause confusion.
Volatile suppresses reordering

Application scenarios of volatile:
When only one thread writes and multiple threads read, volatile is no problem to use. You can force the writing thread to flush to the main memory, otherwise you don’t know when to flush to the main memory. Forced reading can see the latest variables (visibility)
Multiple threads cannot guarantee atomicity when writing to a variable
There is no correlation between write operations, volatile can be used without problems

Many uses in JDK concurrency tools: volatile + CAS to replace synchronized
Volatile can be understood as lock-free programming

The realization principle of volatile

Shared variables modified with volatile variables will use the Lock prefix instruction provided by the CPU when writing operations
1. Write the data of the current processor cache line back to the system memory
2. This operation of writing back to the memory will invalidate the data cached at the memory address in other CPUs