In concurrent programming, there are two key issues that need to be addressed: how to communicate between threads and how threads are synchronized. Communication refers to how information is exchanged between threads, and in imperative programming, there are two mechanisms for communication between threads: Memory sharing and message passing. synchronization refers to a mechanism in the program that controls the relative order of operations between different threads. In the shared-memory concurrency model, synchronization is explicit. The programmer needs to explicitly set the mutex execution between the threads of a piece of code. In the concurrency model of messaging, synchronization is implicit because the message must be sent before the message is accepted. java Concurrent adoption is a shared memory model. The key technical points of java memory model (JMM) are built around the atomicity, ordering and visibility of multithreading. 1. atomicity-atomicity atomicity means that an operation is non-interruptible. Even when multiple threads are executing together, an operation will not be disturbed by other threads once it is started. For example, for a static variable I, two threads assign a value to it, thread a assigns it a value of 1, and thread B assigns it a value of 2, so no matter how the two threads work, I either 1 or 2. There is no interference between threads A and B, which is a characteristic of atomicity and cannot be interrupted. However, if you use a long type (long is 64 bits), for a 32-bit operating system, the read and write of Long data is not an atomic operation, that is, multiple threads operate on a long at the same time, The results between threads are disturbing.  2. Visibility-visibility Visibility is when a thread modifies the value of a shared variable, and whether another thread can immediately know the change. For a serial program, this problem does not exist, because the variable value is modified in any one step, read this value in the subsequent steps, must be modified. But not necessarily in parallel programs. If a thread modifies the value of a variable, other threads may not be able to immediately know the change. A thread and thread B read the variable i,a and then operate on the variable I, and B is not necessarily immediately known. 3. ordered-ordering onIn the execution code of a thread, we are always accustomed to assume that the execution of code is executed in the previous order. However, when concurrency occurs, the execution of the program can occur in a disorderly order. The intuitive feeling is that the code behind it executes first and then executes after the previous code. It sounds incredible, because the program is executing, it may be a command rearrangement, that is, without affecting the serial semantics of the order of the instructions to adjust to optimize the efficiency of the CPU execution (instruction Reflow can guarantee the consistency of the serial semantics, but there is no way to ensure that the semantics of multi-threading is consistent). For instructions rearrangement, take the time to write a special article to explain. Although the Java Virtual machine and the execution system will rearrange the instructions, there are some principles that command rearrangement cannot be violated, that is, Happen-before rules: A sequence principle: The serialization of semantics within a thread b Volatile rules: The write of volatile variables, which occurs first in the read, ensures the visibility of volatile variables (an introduction to volatile)  C Lock rule: Unlocking (unlock) must occur before the subsequent locking (lock) d transitivity: A precedes b,b before C, a must precede c e thread's start () method precedes every action of it  F All operations of the thread precede the end of the thread (Thread.Join ())  G thread interrupts (interrupt ()) prior to the code of the interrupted thread  H The constructor of the object executes, ends before the Finalize () method
Java Multi-threading base-java memory model (JMM)
