Why volatile Beats synchronized: A Deep Dive into Java’s Lightweight Lock

Lightweight Lock: volatile vs. synchronized

Earlier chapters described synchronized as a heavyweight lock that the JVM optimizes heavily. In contrast, volatile acts as a lightweight lock: it avoids thread context switches and scheduling, making it cheaper than synchronized.

When a variable is declared volatile, Java guarantees that all threads see a consistent value. An update by one thread becomes immediately visible to others, providing thread‑visibility.

Memory Model Foundations

Understanding volatile requires basic knowledge of the Java Memory Model (JMM). The CPU executes instructions faster than main memory accesses, so each core has its own cache. While caches improve performance, they introduce data‑consistency problems because each core may hold a stale copy of a variable.

When two threads increment a shared variable i++, each reads the initial value (1) into its own cache, increments locally, and writes back. The final value becomes 2 instead of the expected 3—a classic cache‑coherency issue.

Two resolution strategies exist:

Bus‑locking (adding a LOCK# on the bus), which serializes access but severely reduces parallelism.

Cache‑coherency protocols such as MESI, which invalidate other cores’ cached copies when one core writes, forcing them to reload from main memory.

Key JMM Guarantees

In concurrent programming, three core guarantees are essential:

Atomicity – an operation (or group of operations) executes completely or not at all.

Visibility – a write by one thread becomes instantly observable by others.

Ordering – program execution follows the source‑code order unless reordering is allowed. volatile provides visibility and ordering but does not guarantee atomicity . For example, i++ is not atomic even when i is volatile.

Atomicity Details

Only reads/writes of primitive variables are atomic; compound actions (read‑modify‑write) are not. On a 32‑bit JVM, 64‑bit types like long and double are not atomic either. To achieve atomicity, use locks or synchronized.

Ordering and the Happens‑Before Principle

The JMM allows compilers and processors to reorder instructions for performance, which is safe for single‑threaded code but can break multithreaded correctness. The happens‑before rule defines ordering guarantees:

Program order within a single thread.

Unlock on a monitor happens‑before subsequent lock.

Write to a volatile variable happens‑before any subsequent read of that same variable.

Thread start happens‑before any actions in the new thread.

Thread join happens‑before actions after the join.

Transitivity: if A happens‑before B and B happens‑before C, then A happens‑before C.

Thus, a write to a volatile field establishes a happens‑before relationship with any later read of that field.

How volatile Prevents Reordering

At the JVM level, volatile is implemented using a memory barrier (the lock prefix on x86). This barrier blocks both compiler and processor reordering around the volatile access.

When to Use volatile

Use volatile only if:

The write does not depend on the current value (no read‑modify‑write).

The variable is not part of a larger invariant involving other variables.

Typical scenarios are simple state flags and the double‑checked locking pattern for lazy initialization.

Summary

volatile

is a lightweight synchronization tool that guarantees visibility and ordering via memory barriers, but it cannot provide atomicity for compound actions. Understanding the Java Memory Model, cache‑coherency, and the happens‑before rule is essential to use volatile correctly and avoid subtle multithreading bugs.