Java memory model

The access rules for each variable in the main memory and the Working memory definition program. Specifies the minimum guarantee that the JVM must follow. Defines the partial-order relationship for an operation. Happens-before Rules: Publishing sharedObject with another thread AccessObject. Explains the The memory operation of a thread, in which case it is visible to other threads。 Occurs before: Happens-before a block of code is completed before the other begins. Synchronization constraints: Synchronized-with to synchronize object views with main memory "Rules"1. There is a synchronization constraint for unlocking and subsequent lock operations. 2.volatile variable write and read synchronization constraints exist. 3. If a is constrained by the synchronization of B, then a occurs before B. 4. A appears before B in the program, then a occurs before B. The memory model of the Java language consists of some rulesRules that determine the thread's How memory access is sortedAnd when to make sure they is visible to threadsOf "Features" atomicity, visibility, order. "reordering of compiler action instructions"

The memory model describes the possible behavior of the program. A specific compiler implementation can produce whatever code it likes--as long as all the results from executing the code are consistent with the results of the memory model predictions. This provides a great freedom for compiler implementations, including reordering of operations .

The order in which the compiler generates instructions can be different from the "obvious" version implied by the source code.

The re-ordered instructions, for the optimization of execution and the use of the mature global register allocation algorithm, are very beneficial to the spleen, which makes the program in the computational performance has a great improvement.

Reorder types include:

• The order in which the compiler generates instructions can be different from the "obvious" version implied by the source code.
• The processor can execute commands in a random order or in parallel.
• The cache changes the order in which variables are written to the main memory.

 Memory Visibility

Because modern, shareable memory multiprocessor architectures can cause one thread to not see the results of another thread operation immediately (or even forever). So the Java memory model prescribes a minimum guarantee for the JVM: when to write a variable is visible to other threads .

In modern shareable memory, each processor in a multiprocessor architecture has its own cache and is periodically aligned with the main memory . Assuming that thread a writes a variable value of V, and then another thread B reads the value of the variable V, the value read by thread B may not be the most recent value written by thread A in the following cases:

• The processor executing thread A caches the variable V in the register.
• The processor executing thread A caches the variable V in its own cache, but has not yet flushed to the main memory synchronously.
• The cache of the processor executing thread B has the old value of the variable V.

 Happens-before Relationship

Happens-before Relationship Assurance: If thread A and thread B satisfy the happens-before relationship, the result of thread A performing the action is visible to thread B. If two operations are not sorted by Happens-before, the JVM will be able to reorder them arbitrarily.

Here are a few of the happens-before relationship rules that are related to understanding Concurrenthashmap:

1. Program Order rule: If all action A appears before action B in the program, every action A in the thread is happens-before to every action B in that thread.
2. Monitor lock rule: Unlocking a monitor happens-before to each subsequent locking of the same monitor.
3. Volatile variable rule: write operations on volatile fields are happens-before to each subsequent read operation of the same volatile.
4. Transitivity: If a happens-before to B, and B happens-before C, then a Happens-before c.

Java memory model