Synchronization in Java

JavaMidjava

The Question

What is synchronization in Java?

What a Strong Answer Covers

• one thread at a time
• intrinsic lock/monitor
• synchronized method
• synchronized block
• static synchronization
• prevents race conditions
• performance overhead

Senior-Level Answer

Synchronization in Java is the mechanism by which the JVM controls access to shared resources by multiple threads, preventing data races and ensuring memory visibility.

Every Java object has an intrinsic lock (monitor). When a thread enters a `synchronized` method or block, it acquires the lock on the specified object. Other threads attempting to acquire the same lock block until the first thread releases it by exiting the synchronized scope. Synchronized methods lock on `this` (for instance methods) or on the class object (for static methods).

Synchronization provides two guarantees: 1. **Mutual exclusion**: only one thread executes the synchronized code at a time. 2. **Memory visibility**: changes made inside a synchronized block are visible to any thread that subsequently acquires the same lock (happens-before relationship in the Java Memory Model).

`volatile` is a lighter-weight alternative for visibility without mutual exclusion. A write to a volatile field is immediately visible to all threads. It does not, however, provide atomicity for compound operations — `count++` on a volatile int is still a race condition because it is a read-modify-write sequence of three operations.

The `java.util.concurrent` package provides higher-level alternatives: - `ReentrantLock`: explicit locking with `lock()` and `unlock()`, supports try-lock with timeout, fair ordering. - `ReadWriteLock`: separate locks for read and write — multiple readers can proceed concurrently; writes are exclusive. - `AtomicInteger`, `AtomicReference`, etc.: lock-free atomic operations using CPU compare-and-swap (CAS) instructions. - `CountDownLatch`, `CyclicBarrier`, `Semaphore`: coordination primitives for common concurrency patterns.

Pitfalls: holding locks for too long increases contention; synchronizing on publicly accessible objects allows external code to interfere; using `synchronized` on `String` literals or autoboxed `Integer` values shares locks unexpectedly across the codebase.

What Separates a 2/3 from a 3/3

Common Mistakes

• Thinking volatile provides atomicity for compound operations — count++ is three operations; only a single read or write is atomic on a volatile.
• Synchronizing on the wrong object (different locks on different threads) — threads will not block each other and the race condition remains.
• Using synchronized excessively when a ReadWriteLock or AtomicInteger would reduce contention.

Follow-Up Questions

• What is the Java Memory Model's happens-before relationship, and why does it matter for synchronization? — Happens-before guarantees that writes before a lock release are visible to a thread that subsequently acquires the same lock, preventing stale reads.
• When would you use ReentrantLock over synchronized? — When you need try-lock with timeout, interruptible locking, fair ordering, or separate lock and unlock in different methods.
• How do AtomicInteger operations avoid locking? — They use CPU-level compare-and-swap (CAS) instructions — no OS kernel call or thread suspension, just a spin-retry loop on hardware.

Related Questions

• JVM vs JRE vs JDK
• Java Platform Independence
• How JVM Works
• Main Features of Java
• public static void main