Experience of Learning Java Memory Model JMM

Sometimes compiler and processor optimizations can cause runtime to be different from what we expect, for this reason, Java makes some restrictions on compilers and processors, JAVA memory model (JMM) abstracts these out, so when writing code, you don't have to consider so many low-level details, and ensure that 'as long as the program is written according to the rules of JMM, its running result will definitely be correct'.

JMM's abstract structure

In Java, all instances and static variables are stored in heap memory, which can be shared between threads, and this part is also calledShared variables. Local variables, method definition parameters, and exception handling parameters are on the stack, and stack memory is not shared between threads.

And due to the optimization of compilers and processors, it can lead to visibility problems with shared variables, like in multi-core processors (multi-processor), threads can be executed on different processors, andProcessor caches that are not consistent between processors can cause visibility problems with shared variables, it is possible for two threads to see different values of the same variable.

JMM abstracts these hardware optimizations into each thread having its local memory. When reading and writing shared variables, a copy is copied from the main memory to the local memory. When writing shared variables, they are first written to the local memory and then refreshed to the main memory at a later time. When reading shared variables again, they will only be read from the local memory.

So communication between threads needs to go through two steps:

Write thread: refresh the local memory to the main memory Read thread: read the updated value from the main memory

So in writing-There is a delay between reading: when is the local memory refreshed to the main memory? This leads to visibility problems, and different threads may see different shared variables.

happens-before

Literally, happens-The meaning of 'before' is 'happens before'. This is the rule that Java sets for the execution order of the program, and synchronization must follow this rule to implement it. This way, the programmer only needs to write the correct synchronization program, happens-The 'before' rule ensures that the running result will not be wrong.

A happens-Before B, not only does it mean that A is executed before B, but also that the execution result of A is visible to B, which ensures visibility.

A happens-Before B, A does not necessarily have to be executed before B. If A and B alternate, the execution result can still be correct, allowing the compiler and processor to optimize and reorder. Therefore, as long as the program result is correct, there is no problem with how the compiler and processor optimize and reorder, and they are all good.

happens-The 'before' rule

Program order rule: in a thread, the operation before happens-The locking rule after 'before': unlocking happens for the same lock-The volatile domain rule before locking: writing to a volatile variable, happens-transitivity of any read operation of this volatile variable after before: A happens-before B, B happens-before C, then A happens-before ThreadB.start() rule: If thread A executes ThreadB.start(), then ThreadB.start() happens-before any operation of thread B join() rule: If thread A executes ThreadB.join(), then all operations in thread B happen-before ThreadB.join()

The following example is helpful to understand happens-before

double pi = 3.14; //A
double r = 1.0; //B
double area = pi * r *r; //C

There are three happens here-before relationship, rule1,2It is the program order rule, rule3It is derived from the transitive rule:

A happens-before B B happens-before C A happens-before C

C depends on A and B, but neither A nor B depends on each other. Therefore, even if A and B are reordered, the execution result will not change. This reordering is running under JMM.

The results of the two execution orders are both correct.

That's all the content we have organized for you about the learning experience of Java Memory Model JMM. More questions can be discussed below, thank you for your support of the Yell tutorial.

Statement: The content of this article is from the Internet, and the copyright belongs to the original author. The content is contributed and uploaded by Internet users spontaneously. This website does not own the copyright, has not been manually edited, and does not assume relevant legal liability. If you find any content suspected of copyright infringement, please send an email to: notice#oldtoolbag.com (Please replace # with @ when sending an email for reporting. Provide relevant evidence, and once verified, this site will immediately delete the infringing content.)