Quando usi il pacchetto sync invece dei channel?

Question

Accepted Answer

Go offre due approcci alla sicurezza della concorrenza: **channel** ("condividere la memoria comunicando") e il **pacchetto `sync`** (mutex/lock per proteggere direttamente la memoria condivisa). Nonostante la filosofia dei channel-first di Go, i primitivi sync sono spesso la scelta più semplice e efficiente per proteggere lo stato condiviso.

## sync.Mutex — proteggi lo stato condiviso con un lock

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

Un `Mutex` garantisce che un solo goroutine acceda ai dati protetti alla volta, prevenendo le data race. Il pattern `Lock()`/`defer Unlock()` è idiomatico.

## sync.RWMutex — molti lettori OPPURE uno scrittore

```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` consente letture concorrenti ma scritture esclusive — ideale per dati con molte letture come cache.

## Altri primitivi sync

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

## Quando usare sync vs channel

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

La regola pratica: **"Non comunicare condividendo memoria" è una linea guida, non un dogma.** Per semplicemente proteggere lo stato condiviso, un mutex è più chiaro ed efficiente che contorcere la logica nei channel.

## Perché è importante

Sapere quando usare il pacchetto `sync` rispetto ai channel è un segno chiave di maturità nella concorrenza in Go.

Mentre Go promuove i channel ("condividere la memoria comunicando"), questa è una linea guida — e un errore comune è forzare i channel dove un semplice **mutex** sarebbe più chiaro e veloce.

Il pacchetto `sync` è lo strumento giusto e idiomatico per **proteggere lo stato condiviso** (contatori, cache, mappe): mutex per accesso esclusivo, `RWMutex` per dati con molte letture, `WaitGroup` per attendere goroutine, `Once` per inizializzazione una tantum, e `atomic`/`sync.Map` per casi specializzati.

Comprendere che i channel eccellono nella *comunicazione e coordinamento* mentre i primitivi sync eccellono nel *proteggere la memoria condivisa* — e scegliere lo strumento appropriato piuttosto che usare dogmaticamente i channel — porta a codice concorrente più semplice, efficiente e corretto.

Questo giudizio è esattamente ciò che distingue gli sviluppatori Go esperti ed è un argomento frequente in interviste avanzate.