What Is Synchronization in Java — Mutual Exclusion and Memory Visibility Explained

Synchronization is how Java serializes access to shared mutable state.

Why it's needed — two separate problems

• Race conditions — counter++ is actually read-add-write; two threads interleaving lose updates
• Memory visibility — CPUs write to per-core caches; one thread may never see another thread's write without synchronization
• Classic symptom: a while(running) loop never exits because the other thread's running = false is cached

The three guarantees `synchronized` provides

• Mutual exclusion — only one thread inside the protected section
• Memory visibility — writes inside the block are visible after another thread acquires the same lock
• Ordering — no reordering of reads or writes across the lock boundary
• These are formalized by the Java Memory Model (JSR 133) via happens-before relationships

The tool layers in Java

• `synchronized` — all three guarantees; simplest; reentrant; uninterruptible
• `volatile` — visibility only, NOT atomicity; perfect for one-writer-many-readers flags
• `java.util.concurrent.atomic` — lock-free atomics: AtomicInteger, AtomicReference, LongAdder
• `ReentrantLock` — synchronized on steroids: tryLock(timeout), fairness, interruptibility, multiple conditions
• `StampedLock` / `ReadWriteLock` — for read-heavy workloads
• Concurrent collections — ConcurrentHashMap, CopyOnWriteArrayList, BlockingQueue

How `synchronized` works internally

• Every Java object has a hidden mark word for monitor state
• Uncontended: lightweight lock with CAS on the mark word — tens of nanoseconds
• Under contention: inflates to an OS mutex; blocked threads park in the kernel
• Reentrant: a thread that owns the lock can enter again
• Automatically released on exception (implicit finally)

Common pitfalls

• volatile on a counter — doesn't make counter++ atomic
• Synchronizing on this or on public fields — external code can also synchronize on them, causing unexpected contention; always use a private final lock object
• Large synchronized blocks — hold the lock longer than needed, reducing throughput
• Nested locks in inconsistent order — deadlock

Recommendation: Reach for the lightest tool that fits. Flag-style visibility → volatile. Simple counters → AtomicInteger or LongAdder. Small critical sections → synchronized(privateLock) with a private final lock object. Need tryLock, fairness, or interruptibility → ReentrantLock. Shared maps/queues → concurrent collections from java.util.concurrent. Never hand-roll synchronization when a concurrent collection or atomic exists — the JDK implementations are battle-tested and much faster than what you'd build under contention.