In our previous lessons, we explored synchronization and data sharing between threads, learning how to use the synchronized keyword to prevent race conditions and ensure data integrity. Today, we continue our journey into Java concurrency by focusing on another key aspect: visibility and the use of the volatile keyword, framed within the context of the Java Memory Model (JMM).

By the end of this lesson, you will:

• Understand the concept of visibility in multi-threaded programs.
• Learn about the Java Memory Model (JMM) and how it affects visibility.
• Learn how to use the volatile keyword to address visibility issues.
• Identify and avoid memory consistency errors.

Let's dive into the details and see how we can use the JMM and the volatile keyword to handle common concurrency problems.

The Java Memory Model (JMM) is crucial to understanding how multi-threaded programs work in Java. The JMM defines how Java threads interact with memory, ensuring the correct visibility of shared variables and preventing unpredictable behavior due to caching and compiler optimizations.

The JVM (Java Virtual Machine) plays a key role in the interaction between memory and threads. It provides a virtualized environment in which the code runs, isolating the underlying system from the application and ensuring that the operations of memory allocation, object handling, and synchronization are managed consistently across different hardware architectures. The JVM also interacts with various levels of memory, including registers, cache, RAM, and sometimes non-volatile memory (NVM), to ensure efficient execution and data integrity.

When a Java program is running, memory is organized into different regions that each have specific roles:

• Heap Memory: Shared by all threads, this is where objects are stored.
• Thread Stack: Each thread has its own stack where it stores local variables and method calls. This stack is private to the thread.

A key point here is that each thread has its own copy of local variables when executing methods, even if those methods are part of the same code being executed by multiple threads. This isolation helps ensure that there is no direct interference between threads' local data. However, challenges arise when multiple threads need to access and update shared variables stored in the heap memory.

The following diagram illustrates how memory is organized within the Java Virtual Machine (JVM):

• Thread Stacks: Each thread has its own stack containing local variables and method execution details.
• Heap: This is the shared memory accessible to all threads, where objects are stored.

The thread stack is closely associated with CPU registers, cache, and RAM (main memory):

• CPU Registers: These are the fastest storage locations, used to hold data that the CPU is currently processing. When a thread is executing, its local variables and method calls might be temporarily stored in registers for quick access.

• CPU Cache: This is a small, fast memory layer between the CPU and RAM. It stores frequently accessed data to speed up processing. Threads may have their stack data cached here to improve performance.

• RAM (Main Memory): This is where the thread stack resides when not in registers or cache. It's the main storage for all thread data, including local variables and method calls.

The interaction between these components helps optimize the execution speed of threads, but it also introduces potential visibility issues in multi-threaded programs. For example, if a thread’s data is cached and not properly synchronized with RAM, other threads may not see the latest changes made by the first thread.

When working with multi-threaded applications, it is important to understand the issue of visibility—whether changes made by one thread to shared data are immediately visible to other threads.

The following diagram provides additional insight into how memory operations interact at the JVM and computer levels:

• JVM Side: This part shows how memory is divided in the Java Virtual Machine, with separate Thread Stacks and the Heap which is shared across threads.
• Computer Side: On the hardware level, each CPU core has its own registers and cache, which are used to improve performance. RAM is the shared memory that is accessed by the CPUs.

This diagram helps illustrate how different threads can have isolated local variables in their Thread Stacks while sharing data in the Heap. Visibility issues can arise because of the interaction between CPU caches, registers, and main memory.

Without proper handling of shared variables, several issues can occur due to the complex interaction between threads and memory:

1. Reading Outdated Variables: As each CPU core may have its own cache, changes made by one thread may not be visible to other threads immediately. This can lead to a situation where one thread is working with stale data that is no longer accurate.

2. Race Conditions: If two threads attempt to update a shared variable simultaneously without synchronization, the result can be unpredictable. This is because each thread may have its own cached copy of the variable, and updates from one thread may overwrite the updates from the other thread.

3. Memory Consistency Errors: The Java compiler and CPU may reorder instructions for optimization purposes. Without proper precautions, a thread may see variables in an unexpected state, leading to memory consistency errors where the program's behavior is erratic and difficult to predict.

In the first course, we used the synchronized keyword to handle these issues. Synchronization prevents multiple threads from executing critical sections of code at the same time, ensuring that shared variables are accessed and modified in a safe manner. However, synchronization can be costly in terms of performance, as it involves locking mechanisms.

In this lesson, we will learn another way to ensure visibility, which is less costly for some specific use cases: the volatile keyword.

The volatile keyword is another way to solve visibility issues for single-read and single-write operations, ensuring that changes made by one thread are immediately visible to others.

When a variable is declared as volatile, it ensures that:

• No Caching: Every time a thread reads a volatile variable, it reads directly from the main memory (RAM), ensuring that it sees the latest value.
• Visibility Guarantee: Writes to a volatile variable are immediately written to the main memory, making them visible to all other threads.

The volatile keyword is ideal for situations where you need to ensure that threads always have the most up-to-date value of a variable but without requiring the overhead of full synchronization.

In the following example, we demonstrate how the volatile keyword helps in avoiding visibility issues between threads. Let’s explore a situation where two threads are sharing a variable:

Java
Copy to clipboard
1public class Main {
2    private static volatile boolean stop = false;
3
4    public static void main(String[] args) throws InterruptedException {
5        Thread worker = new Thread(() -> {
6            int i = 0;
7            while (!stop) {
8                i++;
9            }
10            System.out.println("Stopped at i = " + i);
11        });
12        worker.start();
13        Thread.sleep(1000);
14        stop = true;
15        System.out.println("stop set to true");
16    }
17}

In this code, the variable stop is declared as volatile, ensuring that any update made by one thread (in this case, the main thread) is immediately visible to the other threads (e.g., the worker thread).

• The worker thread runs a loop, continuously checking the value of stop. Since stop is marked as volatile, the worker thread reads it directly from the main memory each time it accesses the variable. This guarantees that when the main thread changes stop to true, the worker thread sees the change immediately and stops executing the loop.
• Without volatile, the value of stop could be cached in the local cache of the worker thread's CPU, resulting in a scenario where the worker thread does not see the updated value set by the main thread, leading to the loop running indefinitely.

This example ties directly back to the Java Memory Model (JMM) we discussed earlier. The JMM allows each thread to have a cached version of shared variables, which can lead to visibility problems if the variable's updates are not propagated correctly. By declaring stop as volatile, we ensure that all reads and writes occur directly with the main memory, thus maintaining consistency between the worker and main threads.

The use of the volatile keyword here helps us avoid caching-related visibility issues, thereby ensuring correct program behavior. It also avoids the heavier cost of using synchronization, making it a more efficient solution for simpler visibility requirements.

Visibility issues and memory consistency errors are common in concurrent programming. The volatile keyword provides a straightforward way to address visibility issues without the overhead of synchronization mechanisms. Understanding when and how to use volatile is essential for building efficient and correct multi-threaded applications.

By mastering the volatile keyword, you will enhance your ability to write more efficient and reliable multi-threaded programs, decreasing the chances of hard-to-debug concurrency issues.

Ready to practice and solidify your understanding of volatile? Let's get started!