Hvordan synkroniserer du adgang til delt tilstand?

Question

Accepted Answer

**Synkronisering** koordinerer trådenes adgang til delt mutable tilstand, så operationer ikke interleaves farligt og forebygger **race conditions**. Java tilbyder flere mekanismer, fra det indbyggede `synchronized` nøgleord til eksplicitte locks og 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` sikrer, at kun én tråd udfører den beskyttede kode på én gang (mutual exclusion) og giver **visibility** — ændringer foretaget af en tråd bliver synlige for andre (den krydser memory barrier).

## volatile — visibility uden 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` garanterer, at læsninger/skrivninger af en variabel er synlige på tværs af tråde — men gør **IKKE** sammensatte operationer (som `count++`) atomare. Brug det til simple flags, ikke til 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 giver thread-safe operationer uden locks — ofte hurtigere end `synchronized` til simple tællere/accumulators.

## Explicit Locks — mere kontrol

```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` tilbyder funktioner, som `synchronized` mangler: `tryLock()` (non-blocking), tidsbestemte venter, fairness, og read-write separation.

## De farer, der skal håndteres

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

## Hvorfor det betyder noget

Synkronisering er essentiel for korrekthed, når flere tråde får adgang til delt mutable tilstand — uden det producerer race conditions korrupt data og intermittente, næsten umulige-at-debug fejl.

At kende værktøjerne og deres præcise garantier er kritisk: `synchronized` (mutual exclusion + visibility), `volatile` (kun visibility — IKKE atomicity, en almindelig misforståelse), atomic classes (lock-free til simple operationer), og eksplicitte Locks (avanceret kontrol).

Ligeså vigtig er det at forstå farerne — **deadlock** og over-synkronisering, der skader ydeevnen — og disciplinen til at synkronisere minimalt og konsistent.

Dette er kernekendskab med høj indsats for concurrent server-side Java og et dybt interviewemne, der adskiller udvikler, som kan skrive korrekt multithreaded kode.