1. Visibility issues:
The previous article probably explained JMM. At this time, if two threads A, B, and A read the value of variable x, and thread B modifies the variable x in main memory, B needs to read it into itself. After modifying the variable x in its own working memory, write it to the main memory. If the cpu has been occupied at this time, then the modified x variable is invisible to A ( each thread has Own working memory ), at this time there is a visibility problem. Can use the volatile keyword to solve.
Volatile keyword: When multiple threads perform operations to share data, the data in the memory can be guaranteed to be visible. Compared to synchronized, it is a relatively lightweight synchronization strategy.
Principle of volatile keyword:
First: using the volatile keyword will force the modified value to be written to the main memory immediately;
Second: If you use the volatile keyword, when a thread modifies the variable, it will cause the cache line of the cache variable in the working memory of other threads to be invalid (reflected to the hardware layer, it is the corresponding in the L1 or L2 cache of the CPU The cache line is invalid);
Third: Because the cache line of the cache variable in the working memory of other threads is invalid, other threads will go to the main memory to read the value of the variable again when it reads the value of the variable again.
The difference between synchronized and volatile keywords:
Volatile only has "visibility"
synchronized has "visibility", "mutual exclusion" and "atomicity"
note:
1. Volatile does not have "mutual exclusion"
2. Volatile cannot guarantee the "atomicity" of variables
Both synchronized and lock have "visibility", "mutual exclusion" and "atomicity",
1. Before the thread is unlocked, the latest value of the shared variable must be flushed to the main memory
2. When the thread is locked, the value of the shared variable in the working memory will be cleared, so when using the shared variable, the latest value must be re-read from the main memory.
2. Atomicity
The operation of i++ is actually divided into three steps "read-modify-write". The atomicity problem is due to the execution of multiple operations (read, modify) on shared variables, while the visibility problem only performs one operation on shared variables and does not Load data from main memory again
i++; can be understood as:
（1）int temp = i;
（2）i = i + 1;
At the same time, the initial value of the variable i in the main memory of the two threads A and B is 0, and i++ is performed on it at the same time. A first reads i into its own working memory, and then creates temp=0. At this time, the CPU executes the B thread , B reads i into its own working memory, creates temp=0, then B executes i=i+1 and then writes it back to the main memory (i=1), at this time the CPU executes the A thread again, and executes i=i+ 1 (because i in the working memory is 0), so i=1 in the main memory. Since there is no separate execution of steps 1, 2 and atomicity problems occur.
solution:
Atomic variables: Some atomic variables (AtomicInteger, etc.) are provided under the java.util.concurrent.atomic package.
* 1. volatile guarantees memory visibility (variables in atomic variables are all modified by volatile)
* 2. The CAS (Compare-And-Swap) algorithm guarantees the atomicity of data variables and is implemented through the unsafe class (provides hardware-level atomic operations).
* CAS algorithm is hardware support for concurrent operations
* CAS contains three operands:
* ①Memory value V (old value)
* ②Estimated value A
* ③Update value B
* If and only if V == A, V = B; otherwise, no operation will be performed. (Similar to optimistic lock)
CAS is implemented by the processor cmpxchg instruction
CAS vulnerability: "ABA problem";
Solution:
The java concurrency package provides a tagged atomic reference class "AtomicStampedReference", which can ensure the correctness of CAS by controlling the version of the variable value (similar to optimistic locking).