Deep Dive into Java Volatile Keyword: CPU Cache, MESI Protocol, and JMM

This article provides a comprehensive explanation of computer models, focusing on the interaction between CPU and memory, I/O buses, and CPU cache coherence protocols. It details the Java Memory Model (JMM) and its role in multi-threaded environments.

The Von Neumann computer model is introduced as a fundamental concept where program instructions and data are stored together. The five core components are: Arithmetic Logic Unit (ALU), Memory, Controller, Input devices, and Output devices.

The article explains CPU multi-level cache architecture (L1, L2, L3) and the MESI cache coherence protocol. MESI (Modified, Exclusive, Shared, Invalid) uses a snooping mechanism where CPUs monitor the bus to detect data changes and invalidate their cache lines accordingly.

JMM is described as an abstract specification defining how variables are accessed in multi-threaded programs. It divides memory into main memory (shared) and working memory (thread-private). The model defines eight operations for synchronization between working memory and main memory.

The volatile keyword in Java serves two purposes: ensuring visibility across threads and preventing instruction reordering. When a volatile variable is modified, the lock assembly instruction ("lock addl $0x0,(%rsp)") ensures immediate visibility to other CPUs and acts as a memory barrier.

The article provides practical examples including a visibility problem demonstration and the classic instruction reordering case where two threads reading/writing variables can produce unexpected results. It also explains memory barriers (sfence, lfence, mfence) and their relationship to Unsafe class methods in JDK 1.8+.

Finally, the article explains why volatile is necessary in the double-checked locking singleton pattern - to prevent instruction reordering during object initialization, which could lead to partially constructed objects being visible to other threads.