Quando você usa o pacote sync em vez de channels?

Question

Accepted Answer

Go oferece duas abordagens para concorrência segura: **channels** ("compartilhar memória por comunicação") e o **pacote `sync`** (mutexes/locks para proteger memória compartilhada diretamente). Apesar da filosofia Go orientada a channels, primitivas sync são frequentemente a escolha mais simples e eficiente para proteger estado compartilhado.

## sync.Mutex — proteger estado compartilhado com um 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
}
```

Um `Mutex` garante que apenas uma goroutine acesse os dados protegidos por vez, prevenindo data races. O padrão `Lock()`/`defer Unlock()` é idiomático.

## sync.RWMutex — muitos leitores OU um escritor

```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` permite leituras concorrentes mas escritas exclusivas — ideal para dados com muita leitura, como caches.

## Outras primitivas 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 usar 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
```

A regra prática: **"Não comunique compartilhando memória" é uma diretriz, não dogma.** Para simplesmente proteger estado compartilhado, um mutex é mais claro e eficiente do que contorcer a lógica em channels.

## Por que isso importa

Saber quando usar o pacote `sync` versus channels é um sinal chave de maturidade em concorrência Go.

Enquanto Go promove channels ("compartilhar memória por comunicação"), isso é uma diretriz — e um erro comum é forçar channels onde um simples **mutex** seria mais claro e rápido.

O pacote `sync` é a ferramenta correta e idiomática para **proteger estado compartilhado** (contadores, caches, maps): mutexes para acesso exclusivo, `RWMutex` para dados com muita leitura, `WaitGroup` para aguardar goroutines, `Once` para inicialização única, e `atomic`/`sync.Map` para casos especializados.

Entender que channels se destacam em *comunicação e coordenação* enquanto primitivas sync se destacam em *guardar memória compartilhada* — e escolher a ferramenta apropriada em vez de usar channels dogmaticamente — leva a código concorrente mais simples, mais eficiente e mais correto.

Este julgamento é exatamente o que distingue desenvolvedores Go experientes e é um tópico frequente em entrevistas avançadas.