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

What are the knowledge points of this article "Java concurrency and thread safety?" most people do not understand, so the editor summarizes the following contents, detailed contents, clear steps, and has a certain reference value. I hope you can get something after reading this article. Let's take a look at this "Java concurrency and thread safety knowledge points" article.

Main memory and working memory interaction protocol

JMM defines eight basic operations to complete, the interaction between main memory, working memory and execution engine, namely lock, unlock, read, load, use, assign, store, write. The implementation of the virtual machine ensures that each operation is atomic and inseparable, and there is no guarantee for 64 variables of double and long types. Knowing this will help us understand the memory barrier.

Despite the fact that there are eight operations, they are actually coherent operations defined in pairs. Let's look at how to remember.

Separate operations lock and unlock for main memory

Lock: acts on main memory and marks variables as thread exclusive

Unlock: acting on main memory, releasing locked state

Read swap from main memory to working memory

Read: acts on main memory, passing main memory variables to working memory

Load: acts on working memory and puts the values passed by read operation into working memory

Write swap from working memory to main memory

Store: acts on working memory, passing working memory variables to main memory

Write: acts on the main memory and writes the value from store to the main memory variable

Data exchange between working memory and execution engine

Use: acts on working memory and passes working memory variables to the execution engine

Assign: acts on working memory and assigns the value of the execution engine to the working memory variable

Generally speaking, the data exchange between working memory and main memory is completed by two sets of operations, while the data exchange between execution engine and working memory is completed by two operations. Of course, the above eight operations must meet some rules, and here are some of the ones that I think are important, such as:

Read and load, store and write must appear together

Performing a lock operation on a variable will clear the cached value in the working memory, and unlock the variable must first synchronize the value back to the main memory.

Wasting so much space on the details of data exchange that we Java programmers don't care about is to help us understand the back memory barrier and fasten our seat belts. Let's move on to a completely deranged Java microworld.

The disordered Java world

In a single-threaded world, JMM assures us of the correctness of execution, so we can logically assume that the code is executed in the order in which we write. And you can't see the result of the other party's execution. Take a look at the following code:

Suppose that there are two threads An and B to execute the write and read methods respectively, A goes in to execute first, and B then executes, first putting aside the visibility of an and b threads, assuming that an and b are immediately visible to the thread. What is the final c value? It could be 1, it could be 2, it could even be 0. Next, let's analyze in detail why.

From the point of view of B, it can't see which one executes first, but because of the reordering of instructions, it is very likely that broom1 will execute first.

From the perspective of B thread, will the code in the read method in B thread be reordered? although there is a dependency between the two sentences of this method, JMM supports instruction rearrangement that does not change the result, and JMM cannot predict in advance whether other threads are changing the value of a, so it may be reordered, and the processor will rearrange it with a guess execution.

Instruction reordering makes it impossible for threads to see the execution order of each other's threads, that is, out of order, so what level of instruction reordering will there be? There are three types: compiler reordering, instruction-level reordering, and memory-level reordering.

Memory barrier

Instruction reordering can lead to disorder in multithreaded execution, so JMM forbids certain types of instruction reordering, and JMM forbids certain instruction reordering through memory barriers, so what memory barriers are there? A total of 4 categories

LoadLoad: the front load will be loaded before the later load

StoreStore: the front store will be executed before the later store, that is, to ensure memory visibility

LoadStore: the front load executes before the later store

StoreLoad: the front store executes before the later Load

Next, let's take a look at volatile, final, and locks, respectively, what memory semantics they have and what memory barriers they add.

Volatile

For the write operation of the volatile variable, the StoreStore barrier is inserted in front of it to prevent reordering with the above writes, and the StoreLoad barrier is inserted behind it to prevent reordering with subsequent reads and writes.

For the read operation of the volatile variable, two barriers will be inserted, namely, LoadLoad and LoadStore. To put it bluntly, I am the volatile variable. Whether you read or write the variable below, I will read it before you.

Final

Final is essentially defined as a memory barrier between a finaldomain and a reference to a construction object.

The writer of the final variable and the read of the constructor object reference cannot be reordered by the constructor. In essence, the storeStore barrier is inserted to ensure that the final variable has been written before the object reference is read. Pay special attention to pointer escape here.

Read the reference of the object containing the final variable, and read the final variable can not be ordered to reorder, insert the loadload barrier to ensure that the object reference is read first, and the value of the final variable is read first, that is, as long as the object construction is completed and the finalvalue is written in the constructor, another thread can definitely read it, which is the guarantee of JMM.

Lock

There is a private volatile int state in ReentrantLock, which is essentially the memory semantics of volatile, which is omitted here.

As-if-serial 、 happens-before

Having said that, instruction reordering messes up Java programs. JMM provides volatile, final, and locks to prohibit certain instruction reordering, so it's not easy to remember these reordering rules. JMM uses another memorable theory to help programmers remember.

As-if-serial: to explain in popular terms, in a single line, the program logic is executed in the order we see. Here, we can logically assume that the program is executed sequentially, but there will also be instruction rearrangements that do not affect the result, for example:

Int Illustrated 1itint jungle 2nint a=i*j

In this case, iAccording 1 rearrangement does not affect the result, so JMM is actually allowed. With as-if-serial, programmers don't have to worry about instruction reordering and memory visibility in a single thread.

Happens-before:happens-before guarantees that if there is a happens before relationship between An and B, then the result of A must be visible to B, with the guarantee of visibility, and with the correct synchronization, thread-safe code can be written. What natural happens-before relationships does JSR133 define? Please look at the following:

Within a thread, the operations following each operation happens-before

Unlock operation happens-before 's lock operation on this lock

Volatile write operation happens-before read operation

The thread's start method happens-before all other operations of this thread

Thread all operations happens-before monitors the termination of this thread, for example, A thread calls the join method of B thread, if join returns, then all operations of B thread must be completed, and the data of all operations of B thread must be visible to A thread.

Transitivity, A happens-before B, B happens-before C, then A happens-before C

The above is the content of this article on "what are the knowledge points of Java concurrency and thread safety". I believe we all have some understanding. I hope the content shared by the editor will be helpful to you. If you want to know more about the relevant knowledge, please pay attention to the industry information channel.

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.