Hvordan synkroniserer du tilgang til delt tilstand?

Question

Accepted Answer

**Synkronisering** koordinerer trådenes tilgang til delt mutable tilstand slik at operasjoner ikke blir interleaved på en farlig måte, og forhindrer **race conditions**. Java tilbyr flere mekanismer, fra det innebygde `synchronized`-nøkkelordet til eksplisitte låser og lock-free atomics.

## synchronized — gjensidig ekskludering (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 bare én tråd utfører den beskyttede koden på en gang (gjensidig ekskludering) og gir **visibility** — endringer av én tråd blir synlige for andre (den krysser minnebarrieren).

## volatile — visibility uten 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 lesing/skriving av en variabel er synlig på tvers av tråder — men gjør **IKKE** sammensatte operasjoner (som `count++`) atomiske. Bruk det for enkle flagg, ikke 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 gir trådsikre operasjoner uten låser — ofte raskere enn `synchronized` for enkle tellere/akkumulatorer.

## Eksplisitte låser — mer kontroll

```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` tilbyr funksjoner som `synchronized` mangler: `tryLock()` (non-blocking), tidsbestemte venter, fairness, og lesing-skriving-separasjon.

## Farene å håndtere

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

Synkronisering er essensielt for korrekthet når flere tråder får tilgang til delt mutable tilstand — uten det produserer race conditions korrupte data og intermittente, nesten umulige å debugge feil.

Å kjenne verktøyene og deres presise garantier er kritisk: `synchronized` (gjensidig ekskludering + visibility), `volatile` (visibility bare — IKKE atomicity, en vanlig misforståelse), atomic classes (lock-free for enkle operasjoner), og eksplisitte Locks (avansert kontroll).

Like viktig er det å forstå farene — **deadlock** og over-synkronisering som skader ytelse — og disiplinen til å synkronisere minimalt og konsekvent.

Dette er kjernekunnskap, høyt innsats, for concurrent server-side Java og et dypt intervjutema som skiller utviklere som kan skrive korrekt multithreaded-kode.