Why does even an empty synchronized block carry memory-barrier (acquire/release) effects, and what does this reveal about where Java's visibility guarantee comes from?

## Setting the stage: barriers vs. block bodies To see why an empty `synchronized` block still 'does something', you must understand that the memory guarantees attach to two **events** — acquiring a monitor and releasing it — and not to the statements between them. ### Define the events - **Monitor acquire** happens on entry to a `synchronized` region. The JVM marks the object's lock as held by this thread (blocking if another thread holds it). - **Monitor release** happens on exit (normal or exceptional). The JVM frees the lock. ### Define the barriers A **memory barrier** (a.k.a. fence) is an instruction/semantic that restricts how reads and writes may be reordered and when they become visible: - An **acquire barrier** says: operations *after* it cannot be moved to *before* it, and the thread refreshes its view of shared memory. Practically, caches are invalidated so the thread re-reads current values rather than trusting stale local copies. - A **release barrier** says: operations *before* it cannot be moved to *after* it, and all those prior writes are made visible (flushed) before the barrier completes. The JMM binds an **acquire barrier to monitor acquire** and a **release barrier to monitor release**. That binding is the whole point: it is the *act of acquiring/releasing*, independent of any body, that carries the effect. ### Therefore: the empty block Consider: ```java synchronized (lock) { } ``` This is `acquire; release` with nothing in between. The acquire still invalidates and re-reads; the release still flushes prior writes. So if thread A had earlier mutated shared fields (anywhere before this point, by program order) and then runs this empty block, the release publishes those writes. A thread B that subsequently does its own `synchronized (lock) { }` performs an acquire and is guaranteed (by the **monitor-lock happens-before rule**: an unlock happens-before every later lock of the same monitor) to observe A's published writes. ### What this reveals It reveals that **visibility in Java is a property of the synchronization protocol, not of the work done inside the critical section.** People sometimes imagine the lock 'protects the variables you touch inside.' More precisely, the lock establishes ordering edges; what becomes visible is *everything before the release*, surfacing to *everything after a matching acquire*. The body is where you *use* mutual exclusion; the boundary is where you *get* the memory effect. ### Historical / idiom note Before `volatile` had today's strong semantics (Java 5+, JSR-133), and in some low-level coordination code, people occasionally used empty or near-empty synchronized blocks purely as a fence. Today that is an anti-pattern: prefer `volatile`, `final`, `java.util.concurrent` primitives, or `VarHandle` fences (`fullFence`, `acquireFence`, `releaseFence`) when you genuinely need an explicit barrier. The empty-block fact is best treated as a *conceptual* probe of where the guarantee lives, not a coding recommendation. ### Relationship to volatile `volatile` gives a similar acquire (on read) / release (on write) pairing without mutual exclusion. A volatile write is like a lightweight release; a volatile read is like a lightweight acquire. So the same 'boundary, not body' principle underlies volatile too — there is no body at all, just the single field access carrying the barrier. ### Caveat: don't conclude empty blocks are useful The JIT can, in principle, optimize a provably-uncontended, effect-free lock (biased/elided locking historically), but the *memory-model semantics* still require the ordering be respected as observed. Regardless, relying on empty blocks for fencing is fragile and unclear; the takeaway is understanding, not a technique.