How do you synchronize access to shared state?

Question

Accepted Answer

**Synchronization** coordinates threads' access to shared mutable state so that operations don't interleave dangerously, preventing **race conditions**. Java offers several mechanisms, from the built-in `synchronized` keyword to explicit locks and lock-free atomics.

## synchronized — mutual exclusion (intrinsic locks)

```java
class BankAccount {
    private double balance;

// synchronized method — acquires the object's lock; only ONE thread at a time
    public synchronized void withdraw(double amount) {
        if (balance >= amount) {
            balance -= amount;   // protected — no interleaving
        }
    }
    // synchronized block — finer-grained, lock on a specific object
    public void deposit(double amount) {
        synchronized (this) {
            balance += amount;
        }
    }
}
```

`synchronized` ensures only one thread executes the protected code at a time (mutual exclusion) and provides **visibility** — changes by one thread become visible to others (it crosses the memory barrier).

## volatile — visibility without atomicity

```java
private volatile boolean running = true;   // guarantees VISIBILITY across threads

public void stop() { running = false; }     // other threads see the change immediately
public void run() { while (running) { ... } } // without volatile, might never see false
```

`volatile` guarantees that reads/writes of a variable are visible across threads — but does **NOT** make compound operations (like `count++`) atomic. Use it for simple flags, not for read-modify-write.

## Atomic classes — lock-free atomicity

```java
AtomicInteger counter = new AtomicInteger(0);
counter.incrementAndGet();        // atomic ++ without locking (uses CPU CAS instructions)
counter.compareAndSet(5, 10);     // atomic conditional update
```

Atomic classes provide thread-safe operations without locks — often faster than `synchronized` for simple counters/accumulators.

## Explicit Locks — more control

```java
ReentrantLock lock = new ReentrantLock();
lock.lock();
try {
    // critical section
} finally {
    lock.unlock();   // ALWAYS unlock in finally
}
// ReadWriteLock allows many concurrent readers but exclusive writers
```

`ReentrantLock` offers features `synchronized` lacks: `tryLock()` (non-blocking), timed waits, fairness, and read-write separation.

## The dangers to manage

```text
⚠️ Deadlock — two threads each hold a lock the other needs → both stuck forever
   (avoid by always acquiring locks in a consistent order)
⚠️ Performance — over-synchronizing serializes everything, killing concurrency
   (synchronize the SMALLEST necessary section)
⚠️ Forgetting to unlock (with explicit Locks) → use try/finally
```

## Why it matters

Synchronization is essential for correctness whenever multiple threads access shared mutable state — without it, race conditions produce corrupted data and intermittent, nearly-impossible-to-debug failures.

Knowing the tools and their precise guarantees is critical: `synchronized` (mutual exclusion + visibility), `volatile` (visibility only — NOT atomicity, a common misunderstanding), atomic classes (lock-free for simple ops), and explicit Locks (advanced control).

Equally important is understanding the dangers — **deadlock** and over-synchronization hurting performance — and the discipline to synchronize minimally and consistently.

This is core, high-stakes knowledge for concurrent server-side Java and a deep interview topic that distinguishes developers who can write correct multithreaded code.