Wanneer gebruik je het sync package in plaats van channels?

Question

Accepted Answer

Go biedt twee benaderingen voor concurrency-veiligheid: **channels** ("share memory by communicating") en het **`sync` package** (mutexes/locks voor het rechtstreeks beschermen van gedeeld geheugen). Ondanks Go's channel-first filosofie zijn sync primitives vaak de eenvoudigere, efficiëntere keuze voor het beschermen van gedeelde toestand.

## sync.Mutex — bescherm gedeelde toestand met een slot

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

Een `Mutex` zorgt ervoor dat slechts één goroutine tegelijk toegang heeft tot de beschermde gegevens, waardoor data races worden voorkomen. Het `Lock()`/`defer Unlock()` patroon is idiomatisch.

## sync.RWMutex — veel lezers OF één schrijver

```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` staat gelijktijdig lezen toe maar exclusief schrijven — ideaal voor read-heavy data zoals caches.

## Andere sync primitives

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

## Wanneer sync of channels gebruiken

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

De praktische regel: **"Don't communicate by sharing memory" is een richtlijn, geen dogma.** Voor het eenvoudig beschermen van gedeelde toestand is een mutex duidelijker en efficiënter dan de logica in channels uit te rekken.

## Waarom het belangrijk is

Weten wanneer je het `sync` package tegenover channels gebruikt, is een belangrijk teken van Go concurrency-volwassenheid.

Alhoewel Go channels bevordert ("share memory by communicating"), is dit een richtlijn — en een veelgemaakte fout is channels forceren waar een eenvoudige **mutex** duidelijker en sneller zou zijn.

Het `sync` package is het juiste, idiomatische gereedschap voor **het beschermen van gedeelde toestand** (counters, caches, maps): mutexes voor exclusieve toegang, `RWMutex` voor read-heavy data, `WaitGroup` voor wachten op goroutines, `Once` voor eenmalige initialisatie, en `atomic`/`sync.Map` voor gespecialiseerde gevallen.

Inzien dat channels uitblinken in *communicatie en coördinatie* terwijl sync primitives uitblinken in *het bewaken van gedeeld geheugen* — en het passende gereedschap kiezen in plaats van dogmatisch channels te gebruiken — leidt tot eenvoudiger, efficiënter en correcter concurrent code.

Deze oordeling is precies wat ervaren Go-ontwikkelaars onderscheidt en is een frequent geavanceerd interviewonderwerp.