Forklar atomiske operationer, memory visibility og memory barriers.

Question

IT Interview Practice · Accepted Answer

**En atomisk operation fuldføres udeleligt — ingen anden tråd ser en halvfærdig tilstand; memory visibility er, hvorvidt én tråds writes ses af en anden; memory barriers håndhæver rækkefølge, så de writes bliver synlige.** Locks er ikke den eneste bekymring — memory-modellen er.

## Atomicitet

En atomisk op (f.eks. `fetch_add`, compare-and-swap) udføres som ét udeleligt trin, så ingen race splitter den. Hardware og sprog stiller atomics til rådighed for tællere og flags uden en fuld lock.

```java
AtomicInteger counter = new AtomicInteger();
counter.incrementAndGet();  // atomic read-modify-write, no lock
```

## Synlighed og reordering

Moderne CPU'er og compilere cacher værdier i registre og omordner instruktioner for hastighedens skyld. Så et write i én tråd kan sidde i en store buffer, usynligt for andre, og operationer kan fremstå ude af rækkefølge.

```java
// Without 'volatile', thread B may loop forever:
volatile boolean ready = false;  // volatile → writes are visible + ordered
// Thread A: data = 42; ready = true;
// Thread B: while (!ready) {}  then read data
```

## Memory barriers

En **barrier** (fence) er en instruktion, der forhindrer reordering hen over sig selv og flusher/loader hukommelse, hvilket garanterer rækkefølge. `volatile`, `synchronized` og atomics indsætter de rigtige barriers, så en happens-before-relation holder: det, A skrev før frigivelse, ser B efter erhvervelse.

## Hvorfor det betyder noget

Atomicitet alene er ikke nok — uden synlighedsgarantier kan en korrekt-låst værdi stadig læses forældet. Dette forklarer, hvorfor `volatile` eksisterer, hvorfor double-checked locking er subtilt, og hvorfor lock-free-kode kræver omhyggelige valg om memory-ordering. Det er forskellen mellem "virker på min maskine" og korrekt på rigtig multi-core-hardware.

Atomicitet

Synlighed og reordering

Memory barriers

Hvorfor det betyder noget

Relaterede spørgsmål