¿Cuándo usas el paquete sync en lugar de channels?

Question

IT Interview Practice · Accepted Answer

Go ofrece dos enfoques para la seguridad de la concurrencia: **channels** ("comparte memoria mediante comunicación") y el **paquete `sync`** (mutexes/bloqueos para proteger la memoria compartida directamente). A pesar de la filosofía de Go centrada en channels, las primitivas sync suelen ser la opción más simple y eficiente para proteger el estado compartido.

## sync.Mutex — protege el estado compartido con un bloqueo

```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` asegura que solo una gorrutina pueda acceder a los datos protegidos a la vez, previniendo condiciones de carrera. El patrón `Lock()`/`defer Unlock()` es idiomático.

## sync.RWMutex — muchos lectores O un 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 lecturas concurrentes pero escritura exclusiva — ideal para datos de lectura intensiva como cachés.

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

## Cuándo usar sync versus 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 regla práctica: **"No comuniques compartiendo memoria" es una directriz, no un dogma.** Para simplemente proteger el estado compartido, un mutex es más claro y eficiente que contorsionar la lógica en channels.

## Por qué es importante

Saber cuándo usar el paquete `sync` versus channels es una señal clave de madurez de la concurrencia en Go.

Aunque Go promueve channels ("comparte memoria mediante comunicación"), esto es una directriz — y un error común es forzar channels donde un simple **mutex** sería más claro y rápido.

El paquete `sync` es la herramienta correcta e idiomática para **proteger el estado compartido** (contadores, cachés, mapas): mutexes para acceso exclusivo, `RWMutex` para datos de lectura intensiva, `WaitGroup` para esperar gorrutinas, `Once` para inicialización única, y `atomic`/`sync.Map` para casos especializados.

Comprender que los channels sobresalen en *comunicación y coordinación* mientras que las primitivas sync sobresalen en *proteger la memoria compartida* — y elegir la herramienta apropiada en lugar de usar channels dogmáticamente — lleva a código concurrente más simple, más eficiente y más correcto.

Este juicio es exactamente lo que distingue a los desarrolladores Go experimentados y es un tema de entrevista avanzada frecuente.

sync.Mutex — protege el estado compartido con un bloqueo

sync.RWMutex — muchos lectores O un escritor

Otras primitivas sync

Cuándo usar sync versus channels

Por qué es importante

Preguntas relacionadas