Quand utiliser le package sync plutôt que les channels ?

Question

Accepted Answer

Go offre deux approches pour la sécurité concurrente : les **channels** (« partager la mémoire en communiquant ») et le **package `sync`** (mutex/verrous pour protéger directement la mémoire partagée). Malgré la philosophie Go axée sur les channels, les primitives sync sont souvent le choix plus simple et plus efficace pour protéger l'état partagé.

## sync.Mutex — protéger l'état partagé avec un verrou

```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` garantit qu'un seul goroutine accède aux données protégées à la fois, prévenant les data races. Le modèle `Lock()`/`defer Unlock()` est idiomatique.

## sync.RWMutex — plusieurs lecteurs OU un écrivain

```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` permet les lectures concurrentes mais les écritures exclusives — idéal pour les données de lecture intensive comme les caches.

## Autres primitives 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
```

## Quand utiliser 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
```

La règle pratique : **« Ne communiquez pas en partageant la mémoire » est une ligne directrice, pas un dogme.** Pour simplement protéger l'état partagé, un mutex est plus clair et plus efficace que de contourner la logique avec des channels.

## Pourquoi c'est important

Savoir quand utiliser le package `sync` par rapport aux channels est un signe clé de maturité en concurrence Go.

Bien que Go promeuve les channels (« partager la mémoire en communiquant »), c'est une ligne directrice — et une erreur courante est de forcer les channels là où un simple **mutex** serait plus clair et plus rapide.

Le package `sync` est l'outil approprié et idiomatique pour **protéger l'état partagé** (compteurs, caches, maps) : mutexes pour l'accès exclusif, `RWMutex` pour les données de lecture intensive, `WaitGroup` pour attendre les goroutines, `Once` pour l'initialisation unique, et `atomic`/`sync.Map` pour les cas spécialisés.

Comprendre que les channels excèlent à la *communication et coordination* tandis que les primitives sync excèlent à la *protection de la mémoire partagée* — et choisir l'outil approprié plutôt que d'utiliser dogmatiquement les channels — conduit à un code concurrent plus simple, plus efficace et plus correct.

Ce jugement est exactement ce qui distingue les développeurs Go expérimentés et est un sujet d'entretien avancé fréquent.