Hvornår bruger du sync-pakken i stedet for channels?

Question

Accepted Answer

Go tilbyder to tilgange til concurrency-sikkerhed: **channels** ("del hukommelse via kommunikation") og **`sync`-pakken** (mutexes/låse til at beskytte delt hukommelse direkte). På trods af Gos channel-første filosofi er sync-primitiver ofte det simplere og mere effektive valg til at beskytte delt tilstand.

## sync.Mutex — beskyt delt tilstand med en lås

```go
type Counter struct {
    mu    sync.Mutex
    count int
}

func (c *Counter) Increment() {
    c.mu.Lock()           // acquire the lock — only one goroutine at a time past here
    defer c.mu.Unlock()    // release on return (defer ensures it always happens)
    c.count++              // safe — protected critical section
}
```

En `Mutex` sikrer, at kun en goroutine kan få adgang til de beskyttede data ad gangen, hvilket forhindrer datakapløb. Mønsteret `Lock()`/`defer Unlock()` er idiomatisk.

## sync.RWMutex — mange læsere ELLER en skriver

```go
type Cache struct {
    mu   sync.RWMutex
    data map[string]string
}
func (c *Cache) Get(key string) string {
    c.mu.RLock()           // READ lock — multiple readers allowed concurrently
    defer c.mu.RUnlock()
    return c.data[key]
}
func (c *Cache) Set(key, value string) {
    c.mu.Lock()            // WRITE lock — exclusive
    defer c.mu.Unlock()
    c.data[key] = value
}
```

`RWMutex` tillader samtidigt læsning, men eksklusiv skrivning — ideelt til læsekrævende data som caches.

## Andre sync-primitiver

```go
sync.WaitGroup           // wait for a group of goroutines to finish (Add/Done/Wait)
sync.Once                // run something EXACTLY once (lazy init, singletons)
  var once sync.Once
  once.Do(initialize)    // initialize runs only on the first call, ever
sync.Map                 // a concurrent map (specialized cases)
atomic.AddInt64(&n, 1)   // lock-free atomic operations for simple counters
```

## Hvornår skal man bruge sync versus channels

```text
Use sync (Mutex/RWMutex/atomic) when:
  ✓ Protecting simple shared STATE (a counter, a cache, a map)
  ✓ The logic is "guard this data" — locking is simpler and faster than channels here
  ✓ Read-heavy data (RWMutex), one-time init (Once), simple counters (atomic)

Use channels when:
  ✓ COMMUNICATING/passing data between goroutines, signaling, coordinating
  ✓ Pipelines, worker distribution, ownership transfer
```

Den praktiske regel: **"Kommuniker ikke ved at dele hukommelse" er en retningslinje, ikke dogme.** For blot at beskytte delt tilstand er en mutex mere klar og effektiv end at vride logikken ind i channels.

## Hvorfor det betyder noget

At vide, hvornår man skal bruge `sync`-pakken versus channels, er et nøgletegn på Go concurrency-modenhed.

Selvom Go fremmer channels ("del hukommelse via kommunikation"), er dette en retningslinje — og en almindelig fejl er at tvinge channels derhen, hvor en simpel **mutex** ville være mere klar og hurtig.

`sync`-pakken er det rigtige, idiomatiske værktøj til at **beskytte delt tilstand** (tællere, caches, kort): mutexes for eksklusiv adgang, `RWMutex` for læsekrævende data, `WaitGroup` for at vente på goroutines, `Once` til engangs-initialisering og `atomic`/`sync.Map` til særlige tilfælde.

At forstå, at channels udmærker sig i *kommunikation og koordinering*, mens sync-primitiver udmærker sig i *at beskytte delt hukommelse* — og at vælge det passende værktøj i stedet for dogmatisk at bruge channels — fører til enklere, mere effektiv og mere korrekt concurrent kode.

Denne dømmekraft er præcis det, der adskiller erfarne Go-udviklere, og det er et hyppigt avanceret interviewemne.