Why define the Java memory model? Most modern computer architectures use a symmetric multiprocessor architecture. Each processor has an independent register set and cache, and multiple processors can execute different threads in the same process at the same time. This is called processor out-of-order execution. In Java, different threads may access the same shared or shared variable. If the compiler or processor is allowed to optimize these accesses, it is likely that an unthinkable problem will occur, which is referred to as compiler reordering. In addition to out-of-order execution of processors, reordering of compilers, and reordering of memory systems. Therefore, the Java language specification introduces the Java memory model, which restricts the compiler and processor by defining multiple rules, mainly for visibility and order.
Three basic principles: atomicity, visibility, and orderliness.
The Java memory model involves several keywords: locks, volatile fields, final modifiers, and the secure release of objects. Among them: the first is the lock. The lock operation has a happens-before relationship. After the unlock operation happens-before, the same lock is added. In fact, when unlocking, the JVM needs to force a flush of the cache to make the memory modified by the current thread visible to other threads. The second is the volatile field. The volatile field can be regarded as a feature that does not guarantee atomic synchronization but guarantees visibility. Its performance is often better than lock operations. However, frequent access to volatile fields will also cause problems that affect the performance of the program due to the constant forced flushing of the cache. The third is the final modifier, and the final modified instance field is related to the issue of newly created objects. When an object contains a final decorated instance field, other threads can see the initialized final instance field, which is safe.
Happens-Before 7 rules:
(1). Program order rules: In a thread, in accordance with the program code order, the operations written first occur first in the operations written later. To be precise, it should be the control flow order rather than the program code order, because branches, loops, and other structures need to be considered.
(2). Locking rules of the management process: An unlock operation first occurs in the following lock operation on the same lock. It must be emphasized here that the same lock, and "behind" refers to the sequence in time.
(3). Volatile variable rule: A write operation to a volatile variable occurs first in a subsequent read operation on this variable. Here, "behind" also refers to the sequence in time.
(4). Thread start rule: The start () method of the Thread object first occurs in every action of this thread.
(5). Thread termination rules: All operations in a thread first occur in the termination detection of this thread. We can detect that the thread has terminated by means such as the end of the Thread.join () method and the return value of Thread.isAlive (). carried out.
(6). Thread interruption rules: The call to the thread interrupt () method first occurs when the interrupted thread's code detects the occurrence of the interruption event. You can detect whether an interruption occurs through the Thread.interrupted () method.
(7). Object termination rules: The initialization of an object (the end of the execution of the constructor) first occurs at the beginning of its finalize () method.
Happens-Before 1 feature: transitivity.
How is the underlying Java memory model implemented? Reordering is prohibited mainly through a memory barrier. The real-time compiler replaces these memory barriers with specific CPU instructions according to the specific underlying architecture. For the compiler, the memory barrier will limit the reordering optimizations it can do. For processors, memory barriers will cause cache flush operations. For example, for volatile, the compiler will insert some memory barriers before and after the volatile field read and write operations.
评论