Java Memory Model (JMM) is a set of rules to ensure the consistency of concurrent execution of Java programs on different platforms. 1. It improves performance through the division of main memory and working memory, but may lead to variable visibility problems; 2. JMM defines 8 operations to control memory interactions, such as read, load, use, assign, store, write, lock, unlock, and requires pairs to appear to ensure synchronization; 3. The volatile keyword guarantees visibility and orderliness, but does not guarantee atomicity, and is suitable for use in combination with state flags and CAS; 4. The happens-before principle provides a basis for judging memory visibility, including rules such as program sequence, lock, volatile variables, thread startup and termination, to help rationally use concurrent control means.

The Java Memory Model (JMM) is a set of rules defined in the Java language specifications, which are used to block the differences in memory access between different operating systems and hardware platforms, and ensure that Java programs can achieve consistent concurrent execution results on various platforms. Simply put, it defines the read and write behavior of variables in a multi-threaded environment, especially the visibility, orderliness and atomicity of shared variables.

The following is to understand the practical significance and key points of the Java memory model from several key perspectives.

1. The relationship between main memory and working memory

The Java memory model divides memory into main memory (Main Memory) and thread-private working memory (Working Memory) . Each thread has its own working memory, which stores a copy of the variables used by the thread.

• Threads cannot directly operate variables in the main memory, and can only operate copy of variables in their own working memory and then synchronize them back to the main memory.
• This design is designed to improve performance, but it also brings about variable visibility issues.

For example:
Thread A modified a shared variable, but has not written it back to main memory yet; at this time, thread B reads this variable, and may read the old value. This causes data inconsistency.

2. Interaction between memory

JMM defines 8 basic operations to control the interaction between main memory and working memory:

• read : Read variables from main memory into working memory
• load : put the read value into the variable copy of the working memory
• use : Pass the value in working memory to the execution engine
• assign : Assign the value received by the execution engine to the variable in the working memory
• store : transfer variable values ??in working memory to main memory
• write : Write the stored value into the variable in the main memory
• lock (lock)
• unlock

These operations must meet certain order and atomic requirements, such as read and load must appear in pairs, and the same is true for store and write.

3. The role of volatile keywords

volatile is a very important keyword in JMM, which can ensure the "visibility" and "orderline" of variables.

• Visibility: When one thread modifies the value of the volatile variable, other threads can immediately see the latest value.
• Orderability: prohibits instruction reordering and optimization to ensure that the code execution order is consistent with the writing order.

But it does not guarantee atomicity . For example, if you do i operation on a volatile variable, you still need to lock or use tool classes such as AtomicInteger to ensure thread safety.

Recommended usage:

• Mostly used for status flags (such as switch variables)
• Not suitable for complex composite operations
• Use with CAS to improve performance

4. happens-before principle

JMM uses the "wappens-before" principle to determine whether there is a memory visibility relationship between two operations. If A operates happens-before B operation, the result of operation A is visible to operation B.

Common happens-before rules include:

• Program Sequence Rules: Every operation in the same thread occurs in order
• Monitor lock rules: Unlocking operations occur before subsequent locking operations on the same lock
• volatile variable rules: The write operation to the volatile variable occurs before the subsequent read operation to the variable
• Thread start rule: Thread.start() occurs before any operation of that thread
• Thread termination rule: All operations of a thread occur before the end of that thread

These rules help us understand which operations are guaranteed to have memory visibility and avoid blindly using synchronized or volatile.

Basically that's it. Understanding Java memory model is not to remember all the details, but to know when to add locks, when you can use volatile, and when something goes wrong when writing concurrent programs. Although these mechanisms are at the bottom, they are very important in actual development.

The above is the detailed content of What is the Java Memory Model?. For more information, please follow other related articles on the PHP Chinese website!