När använder du sync-paketet istället för channels?

Question

Accepted Answer

Go erbjuder två tillvagagångssätt för concurrency safety: **channels** ("share memory by communicating") och **`sync`-paketet** (mutexes/locks för att skydda delat minne direkt). Trots Gos kanal-först-filosofi är sync-primitiver ofta det enklare och mer effektiva valet för att skydda delad state.

## sync.Mutex — skydda delad state med ett 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` säkerställer att endast en goroutin får åtkomst till den skyddade datan åt gången, vilket förhindrar datarace. Mönstret `Lock()`/`defer Unlock()` är idiomatiskt.

## sync.RWMutex — många läsare ELLER en skrivare

```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` tillåter samtidiga läsningar men exklusiva skrivningar — perfekt för läsintensiv data som caches.

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

## När man använder sync vs 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 praktiska regeln: **"Don't communicate by sharing memory" är en riktlinje, inte dogma.** För att helt enkelt skydda delad state är en mutex tydligare och mer effektiv än att förvränga logiken till channels.

## Varför det spelar roll

Att veta när man använder `sync`-paketet kontra channels är ett nyckeltecken på Go concurrency-mognad.

Med tanke på att Go befrämjar channels ("share memory by communicating"), är det en riktlinje — och ett vanligt misstag är att tvinga channels där en enkel **mutex** skulle vara tydligare och snabbare.

`sync`-paketet är det rätta, idiomatiska verktyget för att **skydda delad state** (räknare, caches, maps): mutexes för exklusiv åtkomst, `RWMutex` för läsintensiv data, `WaitGroup` för att vänta på goroutines, `Once` för engångsinitialering, och `atomic`/`sync.Map` för specialiserade fall.

Att förstå att channels utmärker sig vid *kommunikation och samordning* medan sync-primitiver utmärker sig vid *att skydda delat minne* — och att välja lämpligt verktyg snarare än att dogmatiskt använda channels — leder till enklare, mer effektiv, mer korrekt concurrency-kod.

Den här bedömningen är exakt vad som skiljer erfarna Go-utvecklare åt och är ett frekvent avancerat intervjuämne.