sync.Mutex, RWMutex y WaitGroup

El paquete sync proporciona mutexes para el estado compartido y WaitGroup para esperar lotes de goroutines.

Úsalos cuando los pipelines de canales oscurezcan una sección crítica simple o una barrera de finalización.

Resumen

sync.Mutex serializa el acceso de lectura/escritura a datos compartidos.

sync.RWMutex permite muchos lectores concurrentes pero escritores exclusivos.

sync.WaitGroup cuenta las goroutines pendientes; Wait se bloquea hasta que el contador llega a cero.

Los mutexes no deben copiarse después del primer uso; WaitGroup requiere pares Add/Done coincidentes.

Receta

Tarjeta de receta de referencia rápida - lista para copiar y pegar.

var (
    mu    sync.Mutex
    cache map[string]string
    wg    sync.WaitGroup
)
 
func load(key string) {
    wg.Add(1)
    go func() {
        defer wg.Done()
        mu.Lock()
        defer mu.Unlock()
        cache[key] = fetch(key)
    }()
}
 
wg.Wait()

Cuándo usar esto:

• Protege mapas, slices y structs mutados por múltiples goroutines.
• RWMutex cuando las lecturas dominan y las escrituras son raras.
• WaitGroup en límites de bifurcación/unión sin pasar un canal de finalización (done channel).
• Prefiere canales cuando transferir la propiedad supera compartir una struct mutable.

Ejemplo de Trabajo

package main
 
import (
    "fmt"
    "sync"
    "time"
)
 
type SafeCounter struct {
    mu sync.RWMutex
    n  int
}
 
func (c *SafeCounter) Inc() {
    c.mu.Lock()
    c.n++
    c.mu.Unlock()
}
 
func (c *SafeCounter) Value() int {
    c.mu.RLock()
    defer c.mu.RUnlock()
    return c.n
}
 
func main() {
    var c SafeCounter
    var wg sync.WaitGroup
    for i := 0; i < 10; i++ {
        wg.Add(1)
        go func() {
            defer wg.Done()
            for j := 0; j < 100; j++ {
                c.Inc()
                time.Sleep(time.Microsecond)
            }
        }()
    }
    wg.Wait()
    fmt.Println(c.Value())
}

Lo que esto demuestra:

• Mutex protege las escrituras en Inc.
• RWMutex el lock de lectura en Value permite lectores concurrentes.
• WaitGroup espera a todas las goroutines de incremento.
• Los métodos en una struct mantienen la disciplina de lock localizada.

Inmersión Profunda

Cómo Funciona

• Mutex.Lock se bloquea hasta que está disponible; Unlock libera.
• RWMutex.RLock se bloquea solo si un escritor tiene el lock; los escritores bloquean a todos los lectores.
• El contador de WaitGroup se incrementa con Add, se decrementa con Done, Wait se bloquea en cero.
• El lock/unlock establece bordes de "happens-before" para la memoria protegida.
• Copiar Mutex o WaitGroup duplica el estado interno - usa punteros o incrusta en structs pasadas por puntero.

Mutex vs RWMutex

Reglas de WaitGroup

Notas de Go

// Incorrecto: copiar WaitGroup
wg2 := wg // roto
 
// Incorrecto: Add después de que Wait retorna
go func() { wg.Add(1) }() // carrera con Wait
 
// Correcto: Add antes de go
wg.Add(1)
go func() {
    defer wg.Done()
}()

Trampas Comunes

• Unlock Olvidado - Deadlock. Solución: defer mu.Unlock() inmediatamente después de Lock.
• Ciclos de orden de locks - Goroutine A bloquea mu1 y luego mu2, B invierte - deadlock. Solución: orden global de locks o un solo mutex.
• WaitGroup.Add después de Wait - Carrera. Solución: todas las Add antes de Wait, o usar un canal de barrera.
• RWMutex para cargas de trabajo con muchas escrituras - Los lectores aún bloquean a los escritores; puede ser más lento que Mutex. Solución: hacer benchmark; a menudo Mutex simple gana.
• Mantener el lock durante I/O - Bloquea a todos los que esperan. Solución: copiar los datos bajo el lock, liberarlo, y luego realizar I/O.

Alternativas

Preguntas Frecuentes

Relacionados

• Conceptos Básicos de Concurrencia - introducción a mutex y WaitGroup
• sync.Once, Cond, Pool y sync.Map - otras primitivas de sync
• Detector de Carreras: Ejecución e Interpretación de Salida - verificación de locks
• Concurrencia en Go: Goroutines y Canales Primero - canales vs locks
• Buenas Prácticas de Fundamentos de Concurrencia - hábitos de orden de locks

Versiones de Stack: Esta página fue escrita para Go 1.26.x (GC por defecto Green Tea, go fix modernizers - verificar parche en build), chi (última - verificar en build), gin (última - verificar en build), echo (última - verificar en build), google.golang.org/grpc (última - verificar en build), sigs.k8s.io/controller-runtime (última - verificar en build), kubebuilder (última - verificar en build), tinygo (última - verificar objetivos de placa en build), wazero (última - verificar en build), y golangci-lint (última - verificar conjunto de linters en build).