20.2. Key Concepts in the JMM

• Threads have working memory (cache). • Changes to variables are not guaranteed to be visible to other threads unless flushed to main memory.

In Java, threads work with their own copy of variables known as working memory (or cache). When one thread modifies a variable, that change is made in its own working memory. However, this change does not automatically propagate to other threads. Other threads will not see this change unless the data is flushed (updated) to the main memory where all threads can access it. This means that if two threads are trying to read and write to the same variable, one thread might not see the latest value if the changes aren't properly synchronized.

Think of a group of friends each working in their own office but sharing access to a common whiteboard in the hallway. If one friend writes a new note (a variable change) on the whiteboard and doesn't go back to the hallway to do so (flush to main memory), the other friends (other threads) won't see the updated note. They may keep referring to the old information written earlier.

A change made by one thread may not be immediately visible to others unless: • The variable is declared volatile, or • Access is synchronized.

Example:

boolean flag = false;
void writer() {
flag = true;
}
void reader() {
if (flag) {
System.out.println("Flag is true");
}
}

Without volatile, the reader thread may never see flag = true.

Visibility in the context of threads means the ability of one thread to see the changes made by another thread. If a variable is not declared as 'volatile' or if access to the variable is not synchronized, one thread may not see the changes made to that variable by another thread. In the provided example, the 'writer()' method sets the flag to true, but if no synchronization is used, the 'reader()' method may keep seeing the flag as false, even after 'writer()' has executed.

Imagine two friends texting each other. Friend A sends a message saying 'I am ready' (setting the flag to true). If Friend B checks their text messages but their phone is not synced to the latest messages (not volatile/synchronized), they'll only see Friend A's old message saying 'I am busy'. Thus, Friend B thinks Friend A is still busy even though they are ready.

Atomicity ensures that a variable update is not interrupted or seen partially. • Basic data types like int or boolean are atomic only for read/write, not compound actions. • Compound operations (like x++) are not atomic.

Atomicity in programming refers to operations that are completed in a single step without the possibility of interruption. In Java, simple read/write operations on basic data types, like an 'int' or 'boolean', are atomic, which means that when one thread reads or writes a value, the operation is completed entirely without interference. However, more complex operations such as incrementing a value (like 'x++') are not atomic. This means that they can be interrupted, leading to inconsistencies if multiple threads try to update the same variable at the same time.

Imagine you are the only one allowed to put a letter into a mailbox (atomic action). If someone else tries to take the letter out before you’ve closed and locked the mailbox (non-atomic action), there could be confusion about whether the letter is in the mailbox or not. Ensuring you finish the action completely without interruption is what atomicity ensures, especially in multithreading.

The JVM and CPU may reorder instructions for optimization, unless prevented by: • Happens-before relationships • Synchronization blocks • Volatile fields.

Reordering refers to the ability of Java Virtual Machine (JVM) and CPU to rearrange the order of instructions during execution to optimize performance. However, this can lead to unexpected behaviors in a multithreaded environment if one thread executes instructions in a different order than another. To prevent issues caused by reordering, the Java Memory Model includes rules such as happens-before relationships, synchronization blocks, and the use of volatile fields, ensuring the correct order of operations and visibility between threads.

Picture a chef preparing multiple dishes in a restaurant. The chef may decide to chop vegetables (instruction A) and start boiling water (instruction B) in the order that seems most efficient rather than the strict recipe instructions. If Chef A tells Chef B that the soup is ready, but Chef B has not actually added the seasonings yet (because they were reordered), the soup might taste bland. The JMM ensures that chefs follow specific orders when serving dishes to avoid such mishaps in a kitchen (thread execution).

--