How do the memory effects of a synchronized block compare to those of a volatile field, and when does each carry an additional guarantee the other does not?

## Two tools, one memory-model foundation Both `synchronized` and `volatile` are built on the same JMM primitives — **acquire** and **release** barriers — but they bundle them differently. ### Define the two barriers (recap) - **Acquire barrier:** when crossing it, the thread refreshes its view of shared memory (invalidate + re-read), and later reads cannot move before it. - **Release barrier:** when crossing it, the thread's prior writes are flushed (made visible), and earlier writes cannot move after it. ### Where each tool places the barriers **synchronized:** - Entry = **monitor acquire** = acquire barrier. - Exit = **monitor release** = release barrier. - Happens-before rule: an unlock on a monitor **happens-before** every subsequent lock of the *same* monitor. - **Plus mutual exclusion:** only one thread holds the monitor at a time. **volatile:** - A **volatile read** = acquire barrier. - A **volatile write** = release barrier. - Happens-before rule: a volatile write to a field **happens-before** every subsequent volatile read of the *same* field. - **No mutual exclusion:** nothing is serialized. ### The shared guarantee: visibility & ordering For *publishing one value and observing it*, the two are equivalent in memory effect. If thread A writes data then writes a volatile flag, a thread B that reads the volatile flag (and sees it set) is guaranteed to also see `data` — exactly as if A had released and B had acquired a monitor. This is because the release flushes *all prior writes*, and the matching acquire observes them. So the often-quoted line is: **a volatile write/read pair has the same memory semantics as a monitor release/acquire pair.** ### Where synchronized is strictly stronger: atomicity of compound actions Visibility is not atomicity. Consider `count++` where `count` is volatile: ```java volatile int count; count++; // read count, add 1, write count — THREE steps ``` Each individual read and write is visible, but two threads can both read 5, both compute 6, and both write 6 — a **lost update**. `volatile` does nothing to prevent the interleave. With `synchronized`: ```java synchronized (lock) { count++; } ``` the lock serializes the whole read-modify-write, so it is **atomic** with respect to other holders of the same lock. The same applies to **check-then-act** (e.g., lazy init, `if (instance == null) instance = new X()`), where volatile alone is insufficient unless paired with a careful pattern like double-checked locking (which itself combines volatile *and* synchronized). ### Where volatile is preferable: cost and simplicity When you only need visibility of a single field (a stop flag, a published reference, a generation counter you only read), `volatile` is cheaper: no lock object, no blocking, no risk of deadlock, no contention. Using `synchronized` there works but adds unnecessary serialization. So volatile is the right tool for the *publish-once / observe* pattern. ### A table to lock it in | Property | synchronized | volatile | |---|---|---| | Acquire barrier | on entry | on each read | | Release barrier | on exit | on each write | | Visibility / ordering (happens-before) | yes (same monitor) | yes (same field) | | Mutual exclusion | **yes** | no | | Atomic compound op (read-modify-write) | **yes** | no | | Blocking / can deadlock | yes | no | | Typical use | critical sections, invariants over multiple fields | single-flag/reference publish & observe | ### The nuance interviewers like - Neither is 'stronger' on **memory effects** — both give the full acquire/release visibility. - `synchronized` is strictly stronger on **exclusion/atomicity**. - Double-checked locking needs **both**: `volatile` for the visibility of the reference, `synchronized` for the atomic check-then-construct. ### Related modern primitives `java.util.concurrent.atomic` (e.g., `AtomicInteger`) gives atomic compound operations (CAS-based `incrementAndGet`) *with* volatile-like visibility but *without* a lock — a middle ground. `VarHandle` exposes explicit acquire/release/opaque/plain access modes and standalone fences for fine-grained control. These build on the same acquire/release model.