Boas Práticas de Concorrência

Regras para concorrência segura e de fácil manutenção em Rust - prefira passagem de mensagens, minimize o escopo de locks e ajuste o modelo de paralelismo à carga de trabalho.

Como Usar Esta Lista

• Aplique antes de adicionar Arc<Mutex<Everything>> a um serviço.
• Use como um checklist de PR para mudanças de spawning de threads e estado compartilhado.
• Revise após incidentes (deadlocks, contagens incorretas, encerramento travado).

A - Seleção de Modelo

• Faça o profiling antes de escolher threads vs Rayon vs async. Rótulos enganam sem dados de tempo.
• Prefira passagem de mensagens em vez de mutação compartilhada. Canais codificam a transferência de propriedade claramente.
• Use Rayon para maps/reduces de paralelismo de dados limitados por CPU. Não para I/O bloqueante dentro de closures.
• Reserve threads do SO para paralelismo real ou isolamento de bloqueio. Milhares de threads são um mau sinal.
• Documente o modelo de concorrência no README do módulo ou ADR. Leitores futuros precisam do porquê.

B - Locks & Estado Compartilhado

• Mantenha as seções críticas curtas. Clone os dados antes de I/O lento ou chamadas de sistema.
• Adquira locks em uma ordem global fixa. Documente a ordem para prevenir deadlocks.
• Prefira RwLock apenas para dados com muitas leituras. Escritores dominam -> use Mutex ou canais.
• Use atômicos para contadores simples e flags de shutdown. Emparelhe Release/Acquire ao publicar estado.
• Evite objetos "god" Arc<Mutex<LargeAppState>>. Particione o estado ou use tarefas de ator.

C - Threads & Lifetimes

• Use thread::scope ao emprestar dados da stack. Evite clones desnecessários de Arc para dividir e conquistar.
• Junte ou desanexe intencionalmente. Threads desanexadas não devem tocar em recursos pais após a saída.
• Nomeie threads para observabilidade. Aparece em logs, traces e dumps de crash.
• Trate JoinError e envenenamento de mutex. Não use unwrap silenciosamente em caminhos de produção.
• Limite a contagem de workers aos orçamentos de CPU, memória e FD. Matemática, não apenas padrões.

D - Canais & Shutdown

• Prefira canais com limite sob carga. Filas ilimitadas escondem backpressure até OOM.
• Descarte todos os remetentes ou envie um sentinela de shutdown. Recebedores não devem bloquear para sempre.
• Use recv_timeout em testes e shutdown. Falhe ruidosamente em vez de travar o CI.
• Envie Result por item em pipelines. Falha parcial é melhor que pânico de tudo ou nada.
• Separe o plano de controle dos canais do plano de dados. Sinais de parada vs mensagens de trabalho.

E - Limite Async

• Não bloqueie o executor async em mutex.lock() ou recv(). Use primitivas tokio::sync em código async.
• Descarregue trabalho de CPU com spawn_blocking ou Rayon a partir do async. Mantenha a latência previsível.
• Nunca mantenha std::sync::MutexGuard através de .await. Quebra Send e atrasa workers.
• Reavalie pools de threads quando bibliotecas se tornam async. Menos pontes, topologia mais simples.
• Teste de carga de shutdown gracioso. Corridas aparecem na implantação e SIGTERM.

FAQs

Relacionados

• Noções Básicas de Concorrência - começando
• Canais - passagem de mensagens
• Deadlocks & Condições de Corrida - modos de falha
• Boas Práticas Async - regras específicas de async
• Boas Práticas do Tokio - ajuste do runtime

Versões da Stack: Esta página foi escrita para Rust 1.97.0 (edição 2024), Tokio 1.x, Axum 0.8, serde 1.0, sqlx 0.8, clap 4, e Polars 0.46+.