Hoe synchroniseer je toegang tot gedeelde state?

Question

Accepted Answer

**Synchronisatie** coördineert de toegang van threads tot gedeelde mutable state zodat operaties niet gevaarlijk door elkaar lopen, waardoor **race conditions** worden voorkomen. Java biedt meerdere mechanismen, van het ingebouwde `synchronized` sleutelwoord tot expliciete locks en 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` zorgt ervoor dat slechts één thread tegelijk de beveiligde code uitvoert (mutual exclusion) en biedt **visibility** — veranderingen door één thread worden zichtbaar voor anderen (het kruist de memory barrier).

## volatile — visibility zonder 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` garandeert dat lees-/schrijfbewerkingen van een variabele zichtbaar zijn voor threads — maar maakt samengestelde operaties (zoals `count++`) **NIET** atomic. Gebruik het voor eenvoudige flags, niet voor 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 bieden thread-veilige operaties zonder locks — vaak sneller dan `synchronized` voor eenvoudige tellers/accumulators.

## Expliciete Locks — meer controle

```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` biedt features die `synchronized` mist: `tryLock()` (non-blocking), timed waits, fairness en read-write scheiding.

## De gevaren om te beheren

```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
```

## Waarom het belangrijk is

Synchronisatie is essentieel voor correctheid wanneer meerdere threads toegang hebben tot gedeelde mutable state — zonder het veroorzaken race conditions beschadigde data en intermittente, vrijwel onmogelijk op te sporen fouten.

Het kennen van de tools en hun precieze garanties is kritiek: `synchronized` (mutual exclusion + visibility), `volatile` (alleen visibility — GEEN atomicity, een veel voorkomend misverstand), atomic classes (lock-free voor eenvoudige ops) en expliciete Locks (geavanceerde controle).

Evenals belangrijk is het begrijpen van de gevaren — **deadlock** en over-synchronisatie die performance schaadt — en de discipline om minimaal en consistent te synchroniseren.

Dit is kernkennis met hoge inzet voor concurrent server-side Java en een diep interview onderwerp dat ontwikkelaars onderscheidt die correct multithreaded code kunnen schrijven.