13.2 Memory Visibility, `volatile`, Intrinsic Locks, and Synchronization

Memory Visibility, volatile, Intrinsic Locks, and Synchronization

When multiple threads read and modify shared memory simultaneously, software systems face two fundamental hazards: race conditions (threads interleaving execution in unpredictable orders) and visibility failures (one thread failing to see the memory writes executed by another thread due to compiler optimizations and CPU core caching). Java addresses these challenges through intrinsic synchronization, the volatile modifier, and the formal guarantees of the Java Memory Model (JMM).

---

Race Conditions, Critical Sections, and Data Races

• Race Condition: A flaw in software execution timing where the correctness of a program depends on the relative timing or interleaving of concurrent execution paths.
• Critical Section: A block of code that accesses shared mutable state and must be executed atomically by at most one thread at a time.
• Data Race: Occurs when two or more concurrent threads access the same memory location simultaneously without synchronization, and at least one of those accesses is a write.

The Non-Atomicity of Compound Operations

A classic trap involves incrementing an integer counter across threads:

public class Counter {
    private int count = 0;
    public void increment() {
        count++; // SEEMINGLY ATOMIC, BUT ACTUALLY THREE DISTINCT OPERATIONS!
    }
}

At the bytecode level, count++ breaks down into three non-atomic steps:

1. getfield: Read the current value of count from memory into a local operand stack.
2. iadd: Add 1 to the loaded value on the operand stack.
3. putfield: Write the incremented value from the operand stack back to the heap field.

If Thread A and Thread B read count simultaneously when its value is 5, both compute 6 independently, and both write 6 back to memory. Two increments occurred, but the counter advances by only 1—a lost update.

---

Intrinsic Monitors and Reentrancy

Every object in the Java heap possesses an associated intrinsic monitor (also called an intrinsic lock or monitor lock). The synchronized keyword uses this monitor to enforce mutual exclusion across critical sections.

Lock Reentrancy

Java's intrinsic locks are reentrant: lock acquisition is scoped to the thread, not the invocation. If a thread already holds the intrinsic monitor for Object X, it can enter any other code block or method that synchronizes on Object X without blocking:

public class ReentrantExample {
    public synchronized void outerMethod() {
        // Thread acquires lock on 'this' (counter = 1)
        innerMethod();
    }
    
    public synchronized void innerMethod() {
        // Same thread re-acquires lock on 'this' (counter = 2)
        System.out.println("Inside innerMethod without deadlock!");
    } // Lock counter decremented to 1 upon exit
}     // Lock counter decremented to 0 and released upon exit

Without reentrancy, a synchronized method calling another synchronized method on the same object would deadlock with itself.

synchronized Methods vs. synchronized Blocks

Synchronization can be applied at the method level or scoped to explicit blocks.

Instance Methods vs. Static Methods

• Instance Synchronized Method: Locks on the intrinsic monitor of the calling instance (this):

  public synchronized void performTask() { /* Locks on this */ }
  

• Static Synchronized Method: Locks on the intrinsic monitor of the java.lang.Class object corresponding to that class in the JVM classloader hierarchy:

  public static synchronized void logEvent() { /* Locks on Logger.class */ }
  

Synchronized Blocks and Explicit Lock Objects

Synchronized blocks provide fine-grained locking, minimizing the time a thread holds a monitor:

public class BankAccount {
    private double balance;
    // Best practice: private final dedicated lock object
    private final Object balanceLock = new Object();

    public void deposit(double amount) {
        validateAmount(amount); // Executed outside lock (uncontended)
        synchronized (balanceLock) {
            balance += amount;  // Critical section
        }
    }
}

Why private final Object is Best Practice

• private: Prevents untrusted external code from synchronizing on the same lock object, eliminating unintended contention or external deadlocks.
• final: Guarantees that the reference cannot be reassigned. If a lock reference changes, subsequent threads synchronize on different instances, violating mutual exclusion.
• Avoid String Literals and Boxed Primitives: Never synchronize on String literals (synchronized ("LOCK")) or boxed primitives (Integer.valueOf(1)). String pooling and wrapper caching share instances across unrelated classes and libraries, causing JVM-wide lock contention.

---

Memory Visibility, Caching, and the volatile Keyword

Modern hardware employs hierarchical caches (L1, L2, L3) per CPU core. A thread running on Core 1 may cache a variable in L1 cache, while Core 2 modifies that variable in main memory. Without synchronization, Core 1 may continue reading stale data indefinitely.

+-----------------------+           +-----------------------+
| CPU Core 1            |           | CPU Core 2            |
| [L1/L2 Cache: flag=0] |           | [L1/L2 Cache: flag=1] |
+-----------------------+           +-----------------------+
           |                                    |            
           +-----------------+------------------+            
                             v                               
                 +-----------------------+                   
                 | Main Memory (RAM)     |                   
                 | flag = 0 (Stale!)     |                   
                 +-----------------------+                   

The volatile Modifier

Declaring a field volatile establishes two guarantees:

1. Memory Visibility: Every write to a volatile variable is immediately flushed to main memory, and every read is fetched directly from main memory. CPU register and local cache values are invalidated.
2. Instruction Reordering Prevention: The compiler and CPU hardware are forbidden from reordering instructions across memory barriers (fences) placed around volatile reads and writes.

public class TaskRunner {
    private volatile boolean active = true;

    public void stop() {
        active = false; // Immediately visible to all threads
    }

    public void run() {
        while (active) {
            // Safely polls volatile variable without caching
        }
    }
}

---

The Java Memory Model (JMM) and Happens-Before

The JMM formalizes memory visibility through the happens-before relationship. If Action A happens-before Action B, then the memory writes performed by Action A are guaranteed to be visible to Action B.

Primary Happens-Before Rules

1. Program Order Rule: Within a single thread, each action happens-before every action that appears later in the source code.
2. Monitor Lock Rule: An unlock on an intrinsic monitor happens-before every subsequent lock on the same monitor.
3. Volatile Variable Rule: A write to a volatile field happens-before every subsequent read of that same field.
4. Thread Start Rule: A call to Thread.start() happens-before any action in the started thread.
5. Thread Termination Rule: Any action in a thread happens-before any other thread successfully completes a join() on that thread or detects isAlive() == false.
6. Transitivity: If A happens-before B, and B happens-before C, then A happens-before C.

---

Concurrency Hazards: Deadlock, Livelock, and Starvation

The Four Coffman Conditions for Deadlock

Deadlock occurs if and only if all four conditions hold simultaneously:

1. Mutual Exclusion: At least one resource is held in a non-shareable mode.
2. Hold and Wait: A thread holds a resource while requesting another resource.
3. No Preemption: Resources cannot be forcibly confiscated from a thread.
4. Circular Wait: A closed chain of threads exists where each thread holds a lock needed by the next thread in the chain.