Java Memory Model and The Volatile Keyword

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) .

What You'll Learn

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

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.

Memory Structure in Java

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.

Join the 1M+ learners on CodeSignal

Be a part of our community of 1M+ users who develop and demonstrate their skills on CodeSignal

Example: Observing Memory Visibility Issues

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

public class Main {
    private static volatile boolean stop = false;

    public static void main(String[] args) throws InterruptedException {
        Thread worker = new Thread(() -> {
            int i = 0;
            while (!stop) {
                i++;
            }
            System.out.println("Stopped at i = " + i);
        });
        worker.start();
        Thread.sleep(1000);
        stop = true;
        System.out.println("stop set to true");
    }
}

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.