sync.Mutex, RWMutex & WaitGroup

Q: Posso usar defer RUnlock?

Sim - defer c.mu.RUnlock() após RLock espelha os bloqueios de escrita.

Q: E se o contador WaitGroup ficar negativo?

Wait entra em pânico se Add tornar o contador negativo. Combine cada Add(1) com exatamente um Done.

Q: WaitGroup pode ser reutilizado?

Sim, após Wait retornar e nenhuma goroutine ainda chamar Done. Espere até que Wait complete antes de um novo lote de Add.

Q: Devo incorporar Mutex em structs exportadas?

Incorpore mu sync.Mutex não exportado em tipos que você controla. Mutexes exportados tentam os chamadores a bloquear incorretamente.

Q: WaitGroup vs canal de término?

WaitGroup é mais simples para juntar N workers. Canais são excelentes para enviar resultados ou sinais de desligamento também.

O pacote sync fornece mutexes para estado compartilhado e WaitGroup para esperar por lotes de goroutines.

Use-os quando pipelines de canal obscurecerem uma seção crítica simples ou uma barreira de conclusão.

Resumo

sync.Mutex serializa o acesso de leitura/escrita a dados compartilhados.

sync.RWMutex permite muitos leitores concorrentes, mas escritores exclusivos.

sync.WaitGroup conta as goroutines pendentes; Wait bloqueia até que a contagem chegue a zero.

Mutexes não devem ser copiados após o primeiro uso; WaitGroup requer pares Add/Done correspondentes.

Receita

Cartão de referência rápida - pronto para copiar e colar.

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()

Quando usar isso:

Proteger mapas, slices e structs modificados por múltiplas goroutines.
RWMutex quando leituras dominam e escritas são raras.
WaitGroup em limites de fork/join sem passar um canal de término.
Preferir canais quando transferir propriedade supera compartilhar uma struct mutável.

Exemplo de Trabalho

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())
}

O que isso demonstra:

Mutex protege escritas em Inc.
O bloqueio de leitura RWMutex em Value permite leitores concorrentes.
WaitGroup espera por todas as goroutines de incremento.
Métodos em uma struct mantêm a disciplina de bloqueio localizada.

Mergulho Profundo

Como Funciona

Mutex.Lock bloqueia até ficar disponível; Unlock libera.
RWMutex.RLock bloqueia apenas se um escritor detiver o bloqueio; escritores bloqueiam todos os leitores.
O contador WaitGroup incrementa com Add, decrementa com Done, Wait bloqueia em zero.
Bloqueio/desbloqueio estabelecem arestas "happens-before" para memória protegida.
Copiar Mutex ou WaitGroup duplica o estado interno - use ponteiros ou incorpore em structs passadas por ponteiro.

Mutex vs RWMutex

Primitiva	Leitores	Escritores	Sobrecarga
`Mutex`	Exclusivo	Exclusivo	Menor
`RWMutex`	Concorrente	Exclusivo	Maior escalabilidade de leitores

Regras do WaitGroup

Chamada	Contrato
`Add(n)`	Antes de iniciar goroutines (ou dentro da goroutine antes do trabalho)
`Done()`	Uma vez por `Add(1)` - `defer wg.Done()` idiomático
`Wait()`	Após todas as chamadas `Add`; bloqueia até o contador zerar

Notas Go

// Errado: copiar WaitGroup
wg2 := wg // quebrado
 
// Errado: Add após Wait retornar
go func() { wg.Add(1) }() // race com Wait
 
// Certo: Add antes de go
wg.Add(1)
go func() {
    defer wg.Done()
}()

Armadilhas

Unlock esquecido - Deadlock. Correção: defer mu.Unlock() imediatamente após Lock.
Ciclos de ordem de bloqueio - Goroutine A bloqueia mu1 e depois mu2, B inverte - deadlock. Correção: ordem global de bloqueio ou um único mutex.
WaitGroup.Add após Wait - Race. Correção: todos os Add antes de Wait, ou use um canal de barreira.
RWMutex para cargas de trabalho com muitas escritas - Leitores ainda bloqueiam escritores; pode ser mais lento que Mutex. Correção: benchmark; muitas vezes o Mutex simples vence.
Manter o bloqueio durante I/O - Bloqueia todos os esperadores. Correção: copiar dados sob bloqueio, liberar, então I/O.

Alternativas

Alternativa	Usar Quando	Não Usar Quando
`sync.Mutex`	Struct compartilhada geral	Com muitas leituras e poucas escritas (tente RWMutex)
`sync/atomic`	Contadores/flags simples	Invariantes complexas que necessitam de múltiplos campos
Handoff de canal	Transferência de propriedade	Cache quente compartilhado com muitos leitores
`errgroup`	Tarefas + primeiro erro	Junção simples sem erros

FAQs

Mutex ou canal para um contador?

Mutex + int é bom para contadores em memória.

Canais adicionam sobrecarga, a menos que o contador seja parte de um estágio de pipeline.

Posso usar defer RUnlock?

Sim - defer c.mu.RUnlock() após RLock espelha os bloqueios de escrita.

RWMutex é sempre mais rápido para leituras?

Não - bloqueios de leitor têm custo de contabilidade.

Faça benchmark do seu padrão de acesso; código com muitas escritas pode preferir Mutex.

E se o contador WaitGroup ficar negativo?

Wait entra em pânico se Add tornar o contador negativo.

Combine cada Add(1) com exatamente um Done.

WaitGroup pode ser reutilizado?

Sim, após Wait retornar e nenhuma goroutine ainda chamar Done.

Espere até que Wait complete antes de um novo lote de Add.

Mutexes são justos?

Mutexes Go não são estritamente FIFO justos, mas evitam inanição na prática.

Não confie na ordem de bloqueio para correção.

Devo incorporar Mutex em structs exportadas?

Incorpore mu sync.Mutex não exportado em tipos que você controla.

Mutexes exportados tentam os chamadores a bloquear incorretamente.

Como isso interage com -race?

O detector de race verifica se o bloqueio cobre acessos conflitantes.

Bloqueios ausentes ainda relatam races, mesmo que os testes passem às vezes.

Receptor de ponteiro é necessário?

Métodos que bloqueiam devem usar receptores de ponteiro para que todos os chamadores compartilhem um único mutex.

WaitGroup vs canal de término?

WaitGroup é mais simples para juntar N workers.

Canais são excelentes para enviar resultados ou sinais de desligamento também.

Relacionado

Fundamentos de Concorrência - introdução a mutex e WaitGroup
sync.Once, Cond, Pool & sync.Map - outras primitivas de sync
Race Detector: Executando e Interpretando Saída - verificar bloqueios
Concorrência em Go: Goroutines e Canais Primeiro - canais vs bloqueios
Melhores Práticas de Fundamentos de Concorrência - hábitos de ordem de bloqueio

Versões de Stack: Esta página foi escrita para Go 1.26.x (GC padrão Green Tea, go fix modernizers - verificar patch na compilação), chi (última - verificar na compilação), gin (última - verificar na compilação), echo (última - verificar na compilação), google.golang.org/grpc (última - verificar na compilação), sigs.k8s.io/controller-runtime (última - verificar na compilação), kubebuilder (última - verificar na compilação), tinygo (última - verificar alvos de placa na compilação), wazero (última - verificar na compilação), e golangci-lint (última - verificar conjunto de linters na compilação).

Use-os quando pipelines de canal obscurecerem uma seção crítica simples ou uma barreira de conclusão.

Resumo

sync.Mutex serializa o acesso de leitura/escrita a dados compartilhados.

sync.RWMutex permite muitos leitores concorrentes, mas escritores exclusivos.

sync.WaitGroup conta as goroutines pendentes; Wait bloqueia até que a contagem chegue a zero.

Mutexes não devem ser copiados após o primeiro uso; WaitGroup requer pares Add/Done correspondentes.

Receita

Cartão de referência rápida - pronto para copiar e colar.

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()

Quando usar isso:

Proteger mapas, slices e structs modificados por múltiplas goroutines.
RWMutex quando leituras dominam e escritas são raras.
WaitGroup em limites de fork/join sem passar um canal de término.
Preferir canais quando transferir propriedade supera compartilhar uma struct mutável.

Exemplo de Trabalho

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())
}

O que isso demonstra:

Mutex protege escritas em Inc.
O bloqueio de leitura RWMutex em Value permite leitores concorrentes.
WaitGroup espera por todas as goroutines de incremento.
Métodos em uma struct mantêm a disciplina de bloqueio localizada.

Mergulho Profundo

Como Funciona

Mutex.Lock bloqueia até ficar disponível; Unlock libera.
RWMutex.RLock bloqueia apenas se um escritor detiver o bloqueio; escritores bloqueiam todos os leitores.
O contador WaitGroup incrementa com Add, decrementa com Done, Wait bloqueia em zero.
Bloqueio/desbloqueio estabelecem arestas "happens-before" para memória protegida.
Copiar Mutex ou WaitGroup duplica o estado interno - use ponteiros ou incorpore em structs passadas por ponteiro.

Mutex vs RWMutex

Primitiva	Leitores	Escritores	Sobrecarga
`Mutex`	Exclusivo	Exclusivo	Menor
`RWMutex`	Concorrente	Exclusivo	Maior escalabilidade de leitores

Regras do WaitGroup

Chamada	Contrato
`Add(n)`	Antes de iniciar goroutines (ou dentro da goroutine antes do trabalho)
`Done()`	Uma vez por `Add(1)` - `defer wg.Done()` idiomático
`Wait()`	Após todas as chamadas `Add`; bloqueia até o contador zerar

Notas Go

// Errado: copiar WaitGroup
wg2 := wg // quebrado
 
// Errado: Add após Wait retornar
go func() { wg.Add(1) }() // race com Wait
 
// Certo: Add antes de go
wg.Add(1)
go func() {
    defer wg.Done()
}()

Armadilhas

Unlock esquecido - Deadlock. Correção: defer mu.Unlock() imediatamente após Lock.
Ciclos de ordem de bloqueio - Goroutine A bloqueia mu1 e depois mu2, B inverte - deadlock. Correção: ordem global de bloqueio ou um único mutex.
WaitGroup.Add após Wait - Race. Correção: todos os Add antes de Wait, ou use um canal de barreira.
RWMutex para cargas de trabalho com muitas escritas - Leitores ainda bloqueiam escritores; pode ser mais lento que Mutex. Correção: benchmark; muitas vezes o Mutex simples vence.
Manter o bloqueio durante I/O - Bloqueia todos os esperadores. Correção: copiar dados sob bloqueio, liberar, então I/O.

Alternativas

Alternativa	Usar Quando	Não Usar Quando
`sync.Mutex`	Struct compartilhada geral	Com muitas leituras e poucas escritas (tente RWMutex)
`sync/atomic`	Contadores/flags simples	Invariantes complexas que necessitam de múltiplos campos
Handoff de canal	Transferência de propriedade	Cache quente compartilhado com muitos leitores
`errgroup`	Tarefas + primeiro erro	Junção simples sem erros

FAQs

Mutex ou canal para um contador?

Mutex + int é bom para contadores em memória.

Canais adicionam sobrecarga, a menos que o contador seja parte de um estágio de pipeline.

Posso usar defer RUnlock?

Sim - defer c.mu.RUnlock() após RLock espelha os bloqueios de escrita.

RWMutex é sempre mais rápido para leituras?

Não - bloqueios de leitor têm custo de contabilidade.

Faça benchmark do seu padrão de acesso; código com muitas escritas pode preferir Mutex.

E se o contador WaitGroup ficar negativo?

Wait entra em pânico se Add tornar o contador negativo.

Combine cada Add(1) com exatamente um Done.

WaitGroup pode ser reutilizado?

Sim, após Wait retornar e nenhuma goroutine ainda chamar Done.

Espere até que Wait complete antes de um novo lote de Add.

Mutexes são justos?

Mutexes Go não são estritamente FIFO justos, mas evitam inanição na prática.

Não confie na ordem de bloqueio para correção.

Devo incorporar Mutex em structs exportadas?

Incorpore mu sync.Mutex não exportado em tipos que você controla.

Mutexes exportados tentam os chamadores a bloquear incorretamente.

Como isso interage com -race?

O detector de race verifica se o bloqueio cobre acessos conflitantes.

Bloqueios ausentes ainda relatam races, mesmo que os testes passem às vezes.

Receptor de ponteiro é necessário?

Métodos que bloqueiam devem usar receptores de ponteiro para que todos os chamadores compartilhem um único mutex.

WaitGroup vs canal de término?

WaitGroup é mais simples para juntar N workers.

Canais são excelentes para enviar resultados ou sinais de desligamento também.

Relacionado

Fundamentos de Concorrência - introdução a mutex e WaitGroup
sync.Once, Cond, Pool & sync.Map - outras primitivas de sync
Race Detector: Executando e Interpretando Saída - verificar bloqueios
Concorrência em Go: Goroutines e Canais Primeiro - canais vs bloqueios
Melhores Práticas de Fundamentos de Concorrência - hábitos de ordem de bloqueio

Versões de Stack: Esta página foi escrita para Go 1.26.x (GC padrão Green Tea, go fix modernizers - verificar patch na compilação), chi (última - verificar na compilação), gin (última - verificar na compilação), echo (última - verificar na compilação), google.golang.org/grpc (última - verificar na compilação), sigs.k8s.io/controller-runtime (última - verificar na compilação), kubebuilder (última - verificar na compilação), tinygo (última - verificar alvos de placa na compilação), wazero (última - verificar na compilação), e golangci-lint (última - verificar conjunto de linters na compilação).

sync.Mutex, RWMutex & WaitGroup

Buscar na documentação

sync.Mutex, RWMutex & WaitGroup