Wie synchronisieren Sie den Zugriff auf gemeinsam genutzten Zustand?

Question

Accepted Answer

**Synchronisierung** koordiniert den Zugriff von Threads auf gemeinsam genutzten veränderbaren Zustand, sodass Operationen nicht gefährlich verschachtelt werden und **Race Conditions** verhindert werden. Java bietet mehrere Mechanismen, vom eingebauten `synchronized`-Schlüsselwort bis zu expliziten Locks und Lock-freien Atomaren.

## synchronized — gegenseitiger Ausschluss (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` stellt sicher, dass nur ein Thread den geschützten Code gleichzeitig ausführt (gegenseitiger Ausschluss) und bietet **Sichtbarkeit** — Änderungen durch einen Thread werden für andere sichtbar (es überquert die Memory Barrier).

## volatile — Sichtbarkeit ohne Atomarität

```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` garantiert, dass Lese- und Schreibvorgänge einer Variable über Threads hinweg sichtbar sind — macht aber **NICHT** zusammengesetzte Operationen (wie `count++`) atomar. Verwenden Sie es für einfache Flags, nicht für Read-Modify-Write-Operationen.

## Atomic-Klassen — Lock-freie Atomarität

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

Atomic-Klassen bieten Thread-sichere Operationen ohne Locks — oft schneller als `synchronized` für einfache Zähler/Akumulatoren.

## Explizite Locks — mehr Kontrolle

```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` bietet Features, die `synchronized` fehlen: `tryLock()` (non-blocking), zeitgesteuerte Wartezeiten, Fairness und Read-Write-Separation.

## Die Gefahren, die zu bewältigen sind

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

## Warum es wichtig ist

Synchronisierung ist wesentlich für Korrektheit, wenn mehrere Threads auf gemeinsam genutzten veränderbaren Zustand zugreifen — ohne sie führen Race Conditions zu beschädigten Daten und flüchtigen, fast unmöglich zu debuggenden Fehlern.

Die Kenntnis der Tools und ihrer genauen Garantien ist entscheidend: `synchronized` (gegenseitiger Ausschluss + Sichtbarkeit), `volatile` (nur Sichtbarkeit — NICHT Atomarität, ein häufiges Missverständnis), Atomic-Klassen (Lock-frei für einfache Ops) und explizite Locks (erweiterte Kontrolle).

Ebenso wichtig ist das Verständnis der Gefahren — **Deadlock** und Über-Synchronisierung, die die Leistung beeinträchtigen — und die Disziplin, minimal und konsistent zu synchronisieren.

Dies ist fundamentales, risikoreiches Wissen für nebenläufiges Server-seitiges Java und ein tiefes Interview-Thema, das Entwickler unterscheidet, die korrekten multithreaded Code schreiben können.