The principle of the first occurrence of security concurrency

The principle of first occurrence, can help you decide whether the concurrency is safe, so do not have to guess whether it is thread-safe!

Writing code can be tedious if all the ordering in the Java memory model is done by volatile and synchronized, but this is not felt in everyday Java development, because of the Java language's "antecedent" principle. This principle is very important and it is the main basis for judging whether the data is competitive and whether the thread is safe or not.

The first occurrence is the partial order relationship between the two operands defined in the Java memory model, and if operation a precedes action B, that is, the effect of operation A can be observed by Operation B before action B occurs, "Impact" includes modifying the values of shared variables in memory, sending messages, calling methods, and so on.

Here are some of the "natural" pre-existing relationships in the Java memory model that can exist without any synchronization assistance, and are used directly in the encoding. If the two relationships are not listed, and cannot be inferred from these relationships, their order cannot be guaranteed and the virtual machine can reorder them arbitrarily.

　　program Order rule: every action A in a thread is happens-before to every action B in that thread, where all action B appears after action A.

　　pipe Lock rule: The unlock operation for a monitor lock is happens-before for each subsequent lock operation on the same monitor lock

　　volatile variable rule: Write operations on volatile fields are happens-before to each subsequent read operation to the same Yu domain.

　　thread Start rule: in the same thread, the call to Thread.Start will be happens-before in every boot thread.

　　thread Termination rule: all actions in the thread are happens-before to other threads that the thread has been terminated, or the Thread.jonin call returned successfully, or Thread.isalive returns FALSE.

　　Break rule: One thread calls another thread's interrupt Happens-before interrupts are found by the interrupted thread (by throwing the interruptedexception or call isinterrupted and interrupted)

　　Finalization rule: the end of an object's constructor Happens-before at the beginning of this object finalizer

　　transitivity: If a happens-before to B and B Happens-before to C, then a happens-before to C.

Java does not need any means to ensure that the above-mentioned rule is set up, the following example to see:

Private int value = 0;  Public void setValue (int  value) {    this. Value = value;}   Public int GetValue () {    return  value;}

Assuming that a, b two threads, thread a first (the time successively) executes SetValue (1), then thread B calls the same object's GetValue (), then thread B receives the return value?

Analyze each principle in the first occurrence principle in turn:

Since two methods are called in different threads, the procedure order principle is not applicable;

There is no synchronization block, lock and unlock operation will not occur naturally, the principle of tube lock is not applicable;

The value variable is not modified by volatile, and the volatile variable principle does not apply;

The following thread start, break, terminate principle also has no relation;

Without an applicable principle, transitivity does not apply.

So the result of thread B is not sure whether it is 0 or 1, in other words, the operation inside is not thread-safe.

How to fix it? Getter/setter defines the synchronized method, or the value variable is defined as a volatile variable, returning to the first occurrence in principle.

Private volatile int value = 0;

In addition, the first occurrence does not mean that it must happen!

There is basically not much relationship between the time sequence and the principle of the first occurrence.

For example, the following code, I, J of the value problem:

int i = 1int j = 2;   // dosth ...　　Volt = 10; Suppose the Volt is a volatile modified

According to the rules of program order, the operation of "int i = 1" occurs in "Int j = 2", but the code of "Int j = 2" may be executed by the processor first, which does not affect the correctness of the antecedent principle, because we have no way to perceive this in this thread.

The principle of first occurrence, can help you decide whether the concurrency is safe, so do not have to guess whether it is thread-safe!

----from the in-depth understanding of Java virtual machines

The principle of the first occurrence of security concurrency