Shulou(Shulou.com)06/02 Report--

Today, I will talk to you about the role of the volatile keyword, which may not be well understood by many people. in order to make you understand better, the editor has summarized the following content for you. I hope you can get something according to this article.

1. Characteristics

1. Visibility: when reading a volatile variable, you can always see (any thread) the last write to the volatile variable.

two。 Atomicity: reading / writing to any single volatile variable is atomic, but composite operations like volatile++ are not atomic.

2. Memory semantics

Memory semantics: it can be simply understood as the memory implementation principles in JVM such as volatile,sychronize,Atomic,Lock.

1. The memory semantics of volatile are as follows:

When writing a volatile variable, JMM (Java memory Model) flushes the values of shared variables in the local memory corresponding to the thread to the main memory.

2. The memory semantics of volatile reads are as follows:

When reading a volatile variable, JMM invalidates the local memory position corresponding to the thread. The thread will then read the shared variable from memory only

If we modify the flag variable with the volatile keyword, then in fact: after thread A writes the flag variable, the values of the two shared variables updated by thread An in local memory are flushed to main memory.

After reading the flag variable, the value contained in local memory B has been set to invalid. At this point, thread B must read the shared variable from main memory. The read operation of thread B will cause the local memory B to be consistent with the value of the shared variable in the main memory.

If we combine the volatile write and volatile read steps, after thread B reads a volatile variable, the values of all shared variables visible to thread A before writing to the volatile variable will immediately become visible to thread B.

3. Why volatile is not thread-safe

4. The implementation of volatile memory semantics.

4.1Table of volatile reordering rules

To sum up, it is:

When the second operation is volatile write, no matter what the first operation is, it cannot be reordered. This rule ensures that operations before volatile writing are not reordered by the compiler after volatile writing.

When the first operation is a volatile read, no matter what the second operation is, it cannot be reordered. This rule ensures that operations after volatile read are not reordered by the compiler before volatile read.

When the first operation is volatile write and the second operation is volatile read, it cannot be reordered.

4.2.memory barrier of volatile

For volatile-decorated variables in Java, when generating bytecode, the compiler inserts a memory barrier in the instruction sequence to prevent certain types of processor reordering problems.

What is the memory barrier {

The Java compiler inserts memory barrier instructions where the instruction sequence is generated to prohibit the reordering of certain types of processors, allowing the program to execute as expected.

1. Ensure the execution order of specific operations.

2. Memory visibility that affects some data (or the result of the execution of an instruction). }

Volatile write

Storestore barrier: for such a statement store1; storestore; store2, ensure that the write operation of the store1 is visible to other processors before the store2 and subsequent write operations are executed. (that is, if there is a storestore barrier, the store1 instruction must be executed before store2, and CPU will not reorder store1 and store2)

Storeload barrier: for such a statement store1; storeload; load2, make sure that store1 writes are visible to all processors before load2 and all subsequent reads are performed. (that is, if there is a storeload barrier, the store1 instruction must be executed before load2, and CPU will not reorder store1 and load2.)

Volatile read

Insert a LoadLoad barrier after each volatile read operation. Insert a loadstore barrier after each volatile read operation.

Loadload barrier: for such a statement load1; loadload; load2, make sure that the data to be read by load1 is read before the data to be read by load2 and subsequent read operations is accessed. (that is, if there is a loadload barrier, the load1 instruction must be executed before load2, and CPU will not reorder load1 and load2.)

Loadstore barrier: for such a statement load1; loadstore; store2, make sure that the data to be read by load1 is read before the store2 and subsequent writes are brushed out. (that is, if there is a loadstore barrier, the load1 instruction must be executed before store2, and CPU will not reorder load1 and store2.)

5. The realization principle of volatile.

Through the analysis of the unsafe.cpp source code in OPEN JDK, it is found that variables modified by the volatile keyword will have a prefix of "lock:".

The Lock prefix, Lock, is not a memory barrier, but it can perform functions similar to memory barriers. Lock locks the CPU bus and cache, which can be understood as a lock on the CPU instruction set.

At the same time, the instruction will write the data of the current processor cache line directly to the system memory, and the write-back operation will invalidate the data cached at that address in other CPU.

In the specific execution, he first locks the bus and cache, then executes the following instructions, and finally releases the lock to flush all the dirty data in the cache back to the main memory. When Lock locks the bus, other CPU read and write requests will be blocked until the lock is released

After reading the above, do you have any further understanding of the function of the volatile keyword? If you want to know more knowledge or related content, please follow the industry information channel, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.