Location>code7788 >text

An article to solidify the theoretical foundations of concurrent programming

Popularity：132 ℃/2024-09-24 08:35:32

JMM Memory Model

define

The java Memory Model (or JMM), something that doesn't exist, is a concept, a convention

There are two main parts to look at, one is called main memory and the other is called working memory.

  • Shared variables in java; are stored in main memory, such as class member variables (instance variables), and static member variables (class variables), are stored in main memory. Every thread has access to main memory;

  • Each thread has its own working memory, when the thread wants to execute the code, it must be done in the working memory. For example, if a thread operates on a shared variable, it cannot operate on the shared variable directly in main memory, it can only make a copy of the shared variable and put it into the thread's own working memory, and then synchronize the result back to main memory after the thread finishes processing the copied shared variable in its working memory.

Main memory is shared by all threads and is accessible to all. All shared variables are stored in main memory; shared variables mainly include member variables of classes and some static variables. Local variables do not appear in main memory because they can only be used by the threads themselves; working memory Each thread has its own working memory, which only stores the thread's copy of a shared variable. All read and write operations of a thread on a variable must be done in working memory, not directly read or write to the variable in main memory, and different threads cannot directly access the variable in each other's working memory; the operations of a thread on a shared variable are performed on its copy, and then synchronized back to main memory after the operation is completed;

JMM Synchronization Conventions.

  • Shared variables must be flushed back to main memory immediately before the thread is unlocked

  • Before a thread can add a lock, it must read the latest value from main memory into working memory

  • Locking and unlocking are the same lock

That is, the JMM is an abstract structure that provides sensible disabling of caching and disabling of reordering solutions to the problems of visibility, orderliness

Role: The main purpose is to ensure the visibility, order, and atomicity of shared variables when they are read or written by multiple threads; the three characteristics of shared variables are guaranteed by the two keywords synchronized and volatile in programming.

Main memory interacts with working memory

How is a variable copied from main memory to working memory and synchronized from working memory back to main memory?

The Java memory model defines eight operations (orange arrows) to accomplish the above diagram, and the virtual machine implementation must ensure that each operation is atomic and indivisible.

For example, suppose that thread 1 wants to access the shared variable x in main memory, which currently takes the value boolean x = true;

  1. Thread 1 first does an atomic operation called Read, which reads the value of the shared variable x in main memory, boolean x = true;
  2. Next is the Load operation, which loads the shared variable read in main memory into working memory (the copy);
  3. Then the Use operation is performed, and if thread 1 needs to perform an operation on the shared variable x, it takes the value of the shared variable x loaded from main memory to perform some operation;
  4. After the operation, a new result is returned, assuming that the value of the shared variable is changed to false, completing the Assign operation, which assigns a new value to the shared variable x;
  5. Once the operation is complete; it needs to be synchronized back to main memory, first completing a Store atomic operation to save the result;
  6. Then the Write operation is performed, i.e., the value assigned to the shared variable by Assign in working memory is synchronized to main memory, and the value x of the shared variable in main memory is changed from true to false.
  7. There are also two lock-related operations, lock and unlock, which are generated by adding synchronized, for example; if operations on shared variables are not locked, then there are no lock and unlock operations.

Note: If you perform a lock operation on a shared variable, the thread will go to main memory to get the newest value of the shared variable, and refresh the old value in working memory to ensure visibility; (locking means that you have to write to the shared variable, and refresh the old value before manipulating the new value) if you perform an unlock operation on a shared variable, you have to synchronize the variable back to main memory before performing the unlock operation; (because releasing the lock on the shared variable will allow other threads to access the shared variable next, you have to make the shared variable present the newest value) these two points are why synchronized can guarantee "visibility". (Because releasing the lock on a shared variable makes the shared variable accessible to other threads, you must keep the shared variable up-to-date) These two points are why synchronized guarantees visibility.

Rules:

  1. Do not allow one of the read, load, store, or write operations to occur alone, i.e., a read operation must be followed by a load, and a store operation must be followed by a write.
  2. A thread is not allowed to discard his most recent ASSIGN operation, i.e., it must inform the main memory when the variable data in the working memory has changed.
  3. Do not allow threads to synchronize unassigned data from working memory to main memory.
  4. A new variable must be born in main memory; working memory is not allowed to use an uninitialized variable directly. That is, before implementing use and store operations on a variable, it must go through load and assign operations.
  5. A variable can only be locked by one thread at a time. After multiple locks, the same number of unlocks must be performed before the variable can be unlocked.
  6. If a lock operation is performed on a variable, the value of this variable is cleared from all working memory. The value of the variable must be initialized with a new load or assign operation before the execution engine can use the variable.
  7. You cannot unlock a variable if it is not locked. Nor can you unlock a variable that is locked by another thread.
  8. Before a thread can perform an unlock operation on a variable, it must first synchronize this variable back to main memory.

summarize

The process of data interaction between main memory and working memory (i.e., the interaction between main memory and working memory is ensured by these eight atomic operations): lock → read → load → use → assign → store → write → unlock

Three problems in concurrent programming

Example of Thread Insecurity

// Case demo: 5 threads each performing 1000 i++ operations:
public class Test01Atomicity {
    private static int number = 0;

    public static void main(String[] args) throws InterruptedException {
        // All 5 threads perform 1000 times i++.
        Runnable increment = () -> {
            for (int i = 0; i < 1000; i++) {
                number++; }
            }
        }; // 5 threads
        ArrayList<Thread> ts = new ArrayList<>();
        for (int i = 0; i < 5; i++) {
            Thread t = new Thread(increment);
            ();
            (t);
        }
        for (Thread t : ts) {
            (); }
        }
        /* The net effect is that the result is not 5000, but probably less than that.
        The reason for this is that i++ is not an atomic operation.
        As demonstrated and analyzed in the following java disassembly, this i++ actually has 4 instructions */
        ("number = " + number); }
    }
}

Visibility: caused by CPU cache

Visibility: is when a thread makes a change to a shared variable, then another thread can immediately see the latest value after the change.

// Code executed by thread 1
int i = 0;
i = 10.

//The code executed by thread 2
j = i.

Assuming that CPU1 executes thread 1 and CPU2 executes thread 2, the above analysis shows that when thread 1 executes the sentence i = 10, it will first load the initial value of i into CPU1's cache, and then assign the value of i to 10, then the value of i in CPU1's cache is changed to 10, but it is not immediately written to the main memory.

At this time, thread 2 executes j = i, it will first go to the main memory to read the value of i and loaded into the cache of CPU2, note that at this time the value of i in memory is still 0, then it will make the value of j is 0, not 10.

Addressing visibility:

  1. The volatile keyword is prepended to shared variables; the underlying implementation of volatile is the Memory Barrier, which ensures that a write instruction to a volatile variable is followed by a write barrier, and a read instruction to a volatile variable is preceded by a read barrier.

    • The write barrier (sfence) ensures that changes to shared variables made before the write barrier are synchronized to the main memory;

    • The read barrier (lfence) ensures that reads to shared variables after the read barrier are loaded with the latest data in the main memory;

  2. Visibility is also guaranteed by synchronized and lock, which ensure that only one thread acquires the lock and executes the synchronized code at the same time, and that changes to the variable are flushed to main memory before the lock is released. This is because synchronized synchronization corresponds to the lock atomic operation in the JMM. The lock operation flushes the value of the variable in working memory to get the latest value in shared memory (main memory), thus ensuring visibility.

    • Synchronized synchronization corresponds to two of the eight atomic operations, lock and unlock. When the lock operation is executed, the thread goes to main memory to get the newest value of the shared variable and flushes the old value in working memory to ensure visibility.

Atomicity due to time-sharing multiplexing

Atomicity: In one or more operations, either all operations are performed and are not interrupted by other factors, or none of the operations are performed;

int i = 1;

// Thread 1 executes
i += 1; // Thread 1 executes.

// Thread 2 executes
i += 1; // Thread 2 executes

Note that i += 1 requires three CPU instructions.

  1. Reads variable i from memory into a CPU register;
  2. Performs an i + 1 operation in the CPU register;
  3. Writes the final result i to memory (the caching mechanism results in the possibility that the CPU cache is written instead of memory).

Due to the existence of CPU time-sharing multiplexing (thread switching), thread 1 executes the first instruction and then switches to thread 2. If thread 2 executes these three instructions and then switches to thread 1 to execute the next two instructions, it will result in the last i value written to memory being 2 instead of 3.

x = 10; //Statement 1: directly assigns the value 10 to x, i.e., the thread executing this statement writes the value 10 directly to working memory.
y = x; //Statement 2: contains two operations, it first reads the value of x and then writes the value of x to working memory. Although reading the value of x and writing the value of x to working memory are both atomic operations, they are not atomic operations.
x++; //Statement 3: x++ consists of three operations: reading the value of x, adding 1, and writing the new value. x = x + 1; //Statement 3: x++ consists of three operations: reading the value of x, adding 1, and writing the new value.
x = x + 1; //Statement 4: same as statement 3

Only the operation in statement 1 of the above four statements is atomic. In other words, only simple reads and assignments (and they must be assignments of numbers to a variable; assignments between variables are not atomic) are atomic.

Solving Atomicity:

The Java memory model only guarantees that basic reads and assignments are atomic operations. If you want to achieve atomicity for a wider range of operations, you can do so through synchronized and Lock. Since synchronized and Lock can ensure that only one thread executes the code block at any given moment, there is naturally no atomicity problem, thus ensuring atomicity.

Orderliness/reordering induced

Ordering (Ordering): refers to the sequence of the program code in the execution process, due to java in the compiler as well as runtime optimization, resulting in the order of execution of the code may not be the order in which the developer writes the code.

int i = 0;
boolean flag = false;
i = 1; //Statement 1
flag = true; //statement 2

Why reordering? Generally believe that the order of writing the code is the final order of execution of the code, then in fact it is not necessarily so, in order to improve the efficiency of the program execution, java will be optimized at compile time and run-time code (JIT compiler), will lead to the final execution of the program is not necessarily the order of writing the code. Reordering is a means by which compilers and processors reorder sequences of instructions to optimize program performance;

The sequence of instructions from the java source code to the final actual execution undergoes the following three types of reordering:

  1. Compiler-optimized reordering. The compiler can reorder the execution of statements without changing the semantics of a single-threaded program.
  2. Instruction-Level Parallelism for Reordering. Modern processors use Instruction-Level Parallelism (ILP) to overlap the execution of multiple instructions. In the absence of data dependencies, the processor can change the order of execution of machine instructions corresponding to statements.
  3. Reordering of the memory system. Since the processor uses caches and read/write buffers, this makes load and store operations appear as if they may be executed in a chaotic order.

1 above is a compiler reordering and 2 and 3 are processor reorders. All of these reorderings can cause memory visibility problems in multithreaded programs. For compilers, the JMM's compiler reordering rules prohibit certain types of compiler reordering (not all compiler reordering is prohibited). For processor reordering, the JMM's processor reordering rules require the java compiler to insert a specific type of memory barriers (intel calls them memory fences) directive when generating instruction sequences, which prohibits a specific type of processor reordering (not all processor reordering is to be prohibited) through a memory barrier directive.

Addresses orderliness:

  1. You can use synchronized blocks to ensure order; with synchronized, instruction reordering still occurs (look at the DCL singleton pattern), except that with synchronized blocks, you can ensure that only one thread executes the code in the synchronized block, which ensures order.

  2. Add the volatile keyword to shared variables to solve the ordering problem.

    • The write barrier will ensure that instruction reordering does not rank code before the write barrier after the write barrier;

    • The read barrier will ensure that instruction reordering does not place code after the read barrier before the read barrier;

Happens-Before Rule

Happens-Before is a visibility rule that expresses the idea that the result of a preceding operation is visible to subsequent operations. It is interpreted as "Happens-Before..."

A happens-before B, which means that the result of A's execution is visible to B

The single-thread (program order) principle

Single Thread rule: Within a thread, operations in the front of the program occur first before operations in the back.

as-id-serio Semantics

Pipelining Lock (Monitor Lock) Rules

Monitor Lock Rule: Unlocking a Lock Happens-Before Subsequent Locking of the Lock

volatile variable rules

Volatile Variable Rule: Writes to a volatile field happen-before any subsequent reads to the volatile field.

Thread startstart rules

Thread Start Rule: The start() method of a Thread object calls every action that occurs in this thread first.

If thread A performs operation () (which starts thread B), then the () operation in thread A hapens-before any operation in thread B

Thread join join rules

Thread Join Rule: The end of a Thread object occurs first when the join() method returns.

If thread A performs operation () and returns successfully, then any operation in thread B hapens-before thread A returns successfully from operation ().

Thread interruption rules

Thread Interruption Rule: The call to the thread interrupt() method occurs first when the code of the interrupted thread detects the occurrence of an interruption event.

Object termination rules

Finalizer Rule: The completion of an object's initialization (the end of constructor execution) occurs first at the beginning of its finalize() method.

transferability

Transitivity: if operation A occurs before operation B, and operation B occurs before operation C, then operation A occurs before operation C.

Security Release Targets

Release and Escape

Publishing means making an object available to code outside its current scope

public static Hashset<Person> persons;
public void init(){
    persons = new HashSet<Person>;
}

Unsafe release: private array, but external scope can also be used, leading to unsafe release

private string[] states = {"a","b","c","d"};
//Posting out a
public string[] getstates(){
    return states;
}

public static void main(string[] args){
    App unSafePub = new App();
    ("Init array is:" + (()));
    ()[0] = "Seven!";
    ("After array is: " + (()));
}

Object overflow:

An erroneous release that makes an object visible to other threads when it hasn't been constructed yet

public cass FinalReferenceEscapeExample {
    final int i;
    static FinalReferenceEscapeExample obj;
    
    public FinalReferenceEscapeExample() {
        i = 1; //1.writefina]domain (taxonomy)
        obj = this; // quote"abscond"
    }
    
    public static void writer() {
        new FinalReferenceEscapeExample();
    }
    public static void reader() {
        if(obj != null){ //3.
            int temp = ; //4.
        }
    }
}

Problems arising from escape

Four Ways to Publish Objects Securely

  • Initializing an object reference in a static initialization function

  • Save a reference to an object into a domain of volatile type or an AtomicReference object (using the volatile happen-before rule)

  • Save a reference to an object into some final type field of a correctly constructed object (initialization security)

  • Saving a reference to an object into a lock-protected field (reads and writes are locked)

Thread-safe implementation

mutually exclusive synchronization

synchronized and ReentrantLock.

non-blocking synchronization

The main problem with mutual exclusion synchronization is the performance problems caused by thread blocking and wakeups, so this type of synchronization is also called blocking synchronization.

Mutually exclusive synchronization belongs to a pessimistic concurrency strategy that always assumes that if you don't go to the right synchronization measures, then problems are bound to occur. Regardless of whether or not there will actually be contention for shared data, it has to perform operations such as locking (the discussion here is about the conceptual model; in reality, the virtual machine will optimize away a large portion of unnecessary locking), user-state core-state transitions, maintaining lock counters, and checking to see if there are any blocked threads that need to be woken up.

CAS

With the development of hardware instruction sets, it is possible to use an optimistic concurrency strategy based on conflict detection: the operation is performed first, and if no other threads are contending for the shared data, then the operation succeeds, otherwise compensatory measures are taken (retrying again and again until it succeeds). Many implementations of this optimistic concurrency strategy do not require threads to be blocked, so this type of synchronous operation is called non-blocking synchronization.

Optimistic locking requires atomicity in both the operation and conflict detection steps, which can no longer be guaranteed using mutex synchronization, but can only be accomplished by hardware. The most typical hardware-supported atomic operation is Compare-and-Swap (CAS), which requires three operands, namely the memory address V, the old expected value A, and the new value B. When the operation is executed, the value of V is updated to B only if the value of V is equal to that of A. The CAS instruction also requires that the value of B be updated to B only if the value of V is equal to that of A. The CAS instruction also requires that the value of A be updated to B only if the value of V is equal to that of A.

AtomicInteger

The AtomicInteger class of integers inside the package, where methods such as compareAndSet() and getAndIncrement() use the CAS operations of the Unsafe class.

The following code performs a self-incrementing operation using an AtomicInteger.

private AtomicInteger cnt = new AtomicInteger();

public void add() {
    ();
}

The following code is the source of incrementAndGet(), which calls unsafe getAndAddInt().

public final int incrementAndGet() {
    return (this, valueOffset, 1) + 1;
}

The following code is the source code for getAndAddInt(). var1 indicates the object memory address, var2 indicates the offset of the field relative to the object memory address, and var4 indicates the value to be added for the operation, in this case 1. The old expected value is obtained by getIntVolatile(var1, var2), and a CAS comparison is performed by calling compareAndSwapInt() to perform a CAS comparison, and if the value in the field's memory address is equal to var5, then the variable with memory address var1+var2 is updated to var5+var4.

You can see that getAndAddInt() proceeds in a loop, and the conflicting practice is to keep retrying.

public final int getAndAddInt(Object var1, long var2, int var4) {
    int var5;
    do {
        var5 = (var1, var2);
    } while(!(var1, var2, var5, var5 + var4));

    return var5;
}

ABA

If a variable is initially read with a value of A, and its value is changed to B, and later changed back to A, the CAS operation mistakenly assumes that it was never changed.

The package provides a tagged atomic reference class, AtomicStampedReference, to solve this problem by controlling the version of a variable's value to ensure CAS correctness. In most cases, the ABA problem does not affect the correctness of program concurrency, and if you need to solve the ABA problem, switching to traditional mutex synchronization may be more efficient than atomic classes.

No synchronization scheme

Synchronization is not necessary to ensure thread safety. If a method doesn't involve sharing data, it doesn't need any synchronization to ensure correctness.

stack closure (computing)

There is no thread-safety issue when multiple threads access local variables of the same method because the local variables are stored on the virtual machine stack and are thread-private.

import ;
import ;

public class StackClosedExample {
    public void add100() {
        int cnt = 0;
        for (int i = 0; i < 100; i++) {
            cnt++;
        }
        (cnt);
    }
}

Thread Local Storage

If a piece of code requires data that must be shared with other code, see if the code that shares the data can be guaranteed to execute in the same thread. If so, you can limit the visibility of the shared data to the same thread, so that there is no need for synchronization to ensure that there is no data contention between threads.

It is not uncommon for applications to fit this profile, and most architectural patterns that use consumption queues (e.g., the Producer-Consumer pattern) try to consume as much of the product as possible in a single thread. One of the most important examples of this is the classic Web interaction model of Thread-per-Request, which is widely used in many Web server applications to address thread safety issues by using thread-local storage. security issues.

You can use classes to implement thread-local storage functionality.

For the following code, thread1 sets threadLocal to 1 and thread2 sets threadLocal to 2. After some time, thread1 reads threadLocal as 1, unaffected by thread2.

public class ThreadLocalExample {
    public static void main(String[] args) {
        ThreadLocal threadLocal = new ThreadLocal();
        Thread thread1 = new Thread(() -> {
            (1);
            try {
                (1000);
            } catch (InterruptedException e) {
                ();
            }
            (());
            ();
        });
        Thread thread2 = new Thread(() -> {
            (2);
            ();
        });
        ();
        ();
    }
}

ThreadLocal is not theoretically designed to solve the problem of multithreaded concurrency, since there is no multithreaded competition at all.

In some scenarios (especially with thread pools) where ThreadLocal has memory leaks due to its underlying data structure, you should manually call remove() after each use of ThreadLocal whenever possible to avoid the risk of ThreadLocal's classic memory leaks or even the risk of messing up your own business.

Re-entrant Code (Reentrant Code)

This type of code, also called Pure Code, can be interrupted at any point in its execution to execute another piece of code (including the recursive call itself) without any errors in the original program after control is returned.

Reentrant code has some common characteristics, such as not relying on data stored on the heap and common system resources, the amount of state used is passed in by parameters, and non-reentrant methods are not called.

About the Author.

From the first-line programmer Seven's exploration and practice, continuous learning iteration in the~

This article is included in my personal blog:https://

Public number: seven97, welcome to follow~

<Previous Next>