Thread pool starvation é uma das condições mais insidiosas em aplicações .NET. Ela ocorre quando todas as threads do pool estão bloqueadas em operações síncronas, e o runtime não consegue injetar novas threads rápido o suficiente para atender as requisições que continuam chegando. O resultado é uma aplicação que parece travada: requests ficam na fila por segundos ou minutos, timeouts disparam em cascata, e o Kestrel começa a emitir avisos de heartbeat. Este artigo apresenta os cinco padrões de código que mais causam starvation, com exemplos funcionais do problema e da correção. Além dos padrões destrutivos, você aprenderá a diagnosticar thread pool starvation em tempo real usando dotnet-counters, dotnet-stack e dotnet-trace. Verá como configurar monitoramento contínuo com OpenTelemetry para detectar o problema antes que ele afete usuários. E entenderá por que ThreadPool.SetMinThreads é uma solução temporária que pode, inclusive, falhar silenciosamente. Todos os exemplos de código são 100% funcionais em .NET 8+ e podem ser copiados e testados localmente.
Insights
- O thread pool do .NET injeta novas threads a uma taxa de apenas 1-2 por segundo: Quando todas as threads estão bloqueadas, a aplicação leva dezenas de segundos para se recuperar. Cada thread bloqueada é um recurso que não volta.
- Sync-over-async é o padrão mais destrutivo em aplicações ASP.NET Core: Chamar
Task.ResultouTask.Wait()dentro de um handler HTTP bloqueia a thread do pool enquanto espera uma operação que, ironicamente, foi projetada para não bloquear. - O Kestrel emite um aviso claro quando detecta starvation: A mensagem
Heartbeat took longer than "00:00:01"é o sinal mais visível de que o thread pool está exausto. Se você vê essa mensagem nos logs, o problema já está acontecendo. dotnet-countersedotnet-stacksão suficientes para diagnosticar 90% dos casos: Monitorethreadpool-thread-countcrescendo acima de 50 ethreadpool-queue-lengthacima de 0 persistentemente. Usedotnet-stackpara encontrar as threads bloqueadas.ThreadPool.SetMinThreadsé um curativo, não uma cura: Aumentar o número mínimo de threads apenas adia o problema. A única solução real é eliminar os bloqueios síncronos do código.
O que é thread pool starvation e por que ela derruba aplicações
O CLR mantém um pool de threads reutilizáveis para executar trabalho assíncrono, callbacks de I/O e itens enfileirados via ThreadPool.QueueUserWorkItem. Esse pool começa com um número de threads igual ao número de processadores lógicos da máquina. Quando todos os threads estão ocupados, o runtime detecta que há trabalho enfileirado e começa a injetar novas threads — mas a uma taxa deliberadamente lenta de 1 a 2 threads por segundo.
Essa taxa lenta é intencional. O algoritmo de hill climbing do thread pool tenta encontrar o número ideal de threads para maximizar throughput sem sobrecarregar o sistema com troca de contexto excessiva. Em condições normais, isso funciona perfeitamente. O problema começa quando as threads não estão executando trabalho real — elas estão bloqueadas, esperando por algo.
Quando uma thread bloqueia, ela sai do jogo. Ela não está disponível para processar outras requisições, mas também não “devolve” seu espaço no pool. Se 100 requisições chegam simultaneamente e cada uma bloqueia uma thread com Task.Result, o pool precisa criar 100 novas threads. A 1-2 por segundo, isso leva de 50 a 100 segundos. Enquanto isso, as requisições ficam na fila, timeouts disparam, e a aplicação parece completamente travada.
flowchart TD
A[Requisição HTTP chega] --> B[ThreadPool atribui uma thread]
B --> C{Thread executa código bloqueante?}
C -->|Não| D[Thread completa e retorna ao pool]
C -->|Sim| E[Thread fica bloqueada esperando]
E --> F[ThreadPool detecta fila crescendo]
F --> G[Injeta 1-2 threads por segundo]
G --> H{Novas threads também bloqueiam?}
H -->|Sim| E
H -->|Não| D
F --> I[Requisições acumulam na fila]
I --> J[Latência dispara para segundos]
J --> K[Kestrel heartbeat warning]
K --> L[Timeouts em cascata]O impacto no ASP.NET Core e no Kestrel
O Kestrel, servidor web do ASP.NET Core, depende diretamente do thread pool para processar requisições. Ele mantém um timer interno chamado heartbeat que dispara a cada segundo para realizar tarefas de manutenção como verificar timeouts de conexão e gerenciar keep-alive. Quando o thread pool está esgotado, até o callback do heartbeat fica na fila esperando uma thread disponível.
Quando o heartbeat leva mais de 1 segundo para ser executado, o Kestrel emite este aviso nos logs:
warn: Microsoft.AspNetCore.Server.Kestrel[22]
Heartbeat took longer than "00:00:01" at "2024-01-15T10:23:45.1234567Z".
This could be caused by thread pool starvation.Se você vê essa mensagem, o problema já está acontecendo. A aplicação já está degradada e os usuários já estão sendo afetados. O ideal é detectar a starvation antes que ela chegue a esse ponto.
Cinco padrões de código que causam thread pool starvation
Os padrões a seguir são os causadores mais comuns de thread pool starvation em aplicações ASP.NET Core. Para cada um, apresento o código que causa o problema, a explicação de por que ele bloqueia threads, e a correção correta.
Padrão 1 — Task.Result e Task.Wait() bloqueiam a thread do pool
O padrão sync-over-async é o mais comum e o mais destrutivo. Ele ocorre quando código síncrono chama uma operação assíncrona e bloqueia a thread esperando o resultado.
Código que causa starvation:
|
1 2 3 4 5 6 7 8 9 |
// RUIM: bloqueia a thread do pool esperando o resultado app.MapGet("/clientes/{id}", (int id, HttpClient httpClient) => { // Task.Result bloqueia a thread até a resposta HTTP chegar var response = httpClient.GetAsync($"https://api.exemplo.com/clientes/{id}").Result; var conteudo = response.Content.ReadAsStringAsync().Result; return Results.Ok(conteudo); }); |
Por que causa starvation: quando Task.Result é chamado, a thread atual do pool entra em estado de espera (blocking wait). Ela não é devolvida ao pool. Se a chamada HTTP leva 500ms e 200 requisições chegam simultaneamente, 200 threads ficam bloqueadas por 500ms cada. O thread pool precisa de 100 segundos para injetar 200 novas threads. Durante esse tempo, a fila cresce e a aplicação trava.
Código corrigido:
|
1 2 3 4 5 6 7 8 9 |
// BOM: a thread é devolvida ao pool durante a espera app.MapGet("/clientes/{id}", async (int id, HttpClient httpClient) => { // await libera a thread enquanto espera a resposta HTTP var response = await httpClient.GetAsync($"https://api.exemplo.com/clientes/{id}"); var conteudo = await response.Content.ReadAsStringAsync(); return Results.Ok(conteudo); }); |
Com await, a thread é devolvida ao pool imediatamente quando a operação de I/O inicia. Quando a resposta HTTP chega, qualquer thread disponível do pool continua a execução. Nenhuma thread fica bloqueada.
Padrão 2 — Thread.Sleep dentro de métodos async congela a thread
Thread.Sleep suspende a thread atual pelo tempo especificado. Em código assíncrono, isso desperdiça uma thread do pool que poderia estar processando outras requisições.
Código que causa starvation:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
// RUIM: Thread.Sleep bloqueia a thread do pool app.MapPost("/pedidos", async (Pedido pedido, AppDbContext db) => { db.Pedidos.Add(pedido); await db.SaveChangesAsync(); // Simula espera antes de enviar notificação // Thread.Sleep bloqueia a thread por 5 segundos Thread.Sleep(5000); await EnviarNotificacaoAsync(pedido); return Results.Created($"/pedidos/{pedido.Id}", pedido); }); |
Por que causa starvation: Thread.Sleep(5000) mantém a thread do pool suspensa por 5 segundos inteiros. Se 50 requisições de pedido chegam ao mesmo tempo, 50 threads ficam dormindo por 5 segundos. Em uma máquina com 8 núcleos, o pool começa com 8 threads. As primeiras 8 requisições bloqueiam todas as threads. As 42 restantes esperam na fila enquanto o runtime injeta 1-2 threads por segundo.
Código corrigido:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
// BOM: Task.Delay não bloqueia a thread app.MapPost("/pedidos", async (Pedido pedido, AppDbContext db) => { db.Pedidos.Add(pedido); await db.SaveChangesAsync(); // Task.Delay libera a thread durante a espera await Task.Delay(5000); await EnviarNotificacaoAsync(pedido); return Results.Created($"/pedidos/{pedido.Id}", pedido); }); |
Task.Delay registra um timer e devolve a thread ao pool imediatamente. Quando o timer dispara, uma thread disponível continua a execução. Zero threads bloqueadas.
Padrão 3 — I/O síncrono no corpo da requisição bloqueia a thread
Ler o corpo de uma requisição HTTP de forma síncrona bloqueia a thread do pool enquanto os dados são transferidos da rede.
Código que causa starvation:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
// RUIM: leitura síncrona do body bloqueia a thread app.MapPost("/importar", (HttpContext context) => { // Habilita leitura síncrona (necessário no Kestrel) context.Request.EnableBuffering(); // ReadToEnd bloqueia a thread até ler todo o body using var reader = new StreamReader(context.Request.Body); var json = reader.ReadToEnd(); var dados = JsonSerializer.Deserialize<List<Produto>>(json); return Results.Ok(new { Importados = dados?.Count ?? 0 }); }); |
Por que causa starvation: ReadToEnd() é uma operação síncrona que bloqueia a thread até que todo o corpo da requisição seja lido da stream de rede. Para payloads grandes (1MB+), isso pode levar centenas de milissegundos. Para uploads lentos, pode levar segundos. A thread fica bloqueada durante toda a transferência.
Código corrigido:
|
1 2 3 4 5 6 7 8 9 |
// BOM: desserialização assíncrona direto da stream app.MapPost("/importar", async (HttpContext context) => { // DeserializeAsync lê a stream de forma assíncrona var dados = await JsonSerializer.DeserializeAsync<List<Produto>>( context.Request.Body); return Results.Ok(new { Importados = dados?.Count ?? 0 }); }); |
JsonSerializer.DeserializeAsync lê a stream de forma assíncrona, devolvendo a thread ao pool enquanto espera dados da rede. Além de não bloquear, é mais eficiente em memória porque não precisa alocar uma string intermediária com todo o JSON.
Padrão 4 — SemaphoreSlim.Wait() bloqueia quando deveria esperar de forma assíncrona
SemaphoreSlim é frequentemente usado para limitar concorrência. A versão síncrona Wait() bloqueia a thread, enquanto WaitAsync() a libera.
Código que causa starvation:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
public class RelatorioService { private static readonly SemaphoreSlim _semaforo = new(3); // máximo 3 simultâneos // RUIM: Wait() bloqueia a thread do pool public RelatorioComplexo GerarRelatorio(int clienteId) { // Bloqueia a thread até conseguir entrar no semáforo _semaforo.Wait(); try { // Simula geração demorada var dados = ObterDadosDoCliente(clienteId); return ProcessarRelatorio(dados); } finally { _semaforo.Release(); } } } |
Por que causa starvation: se o semáforo permite 3 execuções simultâneas e 50 requisições chegam, 3 threads executam o relatório e as outras 47 ficam bloqueadas em Wait(). Essas 47 threads estão bloqueadas, não disponíveis para processar outras requisições. Se a geração do relatório leva 10 segundos, essas 47 threads ficam presas por até 10 segundos.
Código corrigido:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
public class RelatorioService { private static readonly SemaphoreSlim _semaforo = new(3); // máximo 3 simultâneos // BOM: WaitAsync() libera a thread enquanto espera public async Task<RelatorioComplexo> GerarRelatorioAsync(int clienteId) { // Libera a thread enquanto espera vaga no semáforo await _semaforo.WaitAsync(); try { var dados = await ObterDadosDoClienteAsync(clienteId); return await ProcessarRelatorioAsync(dados); } finally { _semaforo.Release(); } } } |
Com WaitAsync(), as 47 threads que não conseguem entrar no semáforo são devolvidas ao pool. Elas ficam disponíveis para processar outras requisições. Quando uma vaga no semáforo abre, qualquer thread disponível continua a execução.
Padrão 5 — acesso síncrono a HttpContext.Request.Form bloqueia a leitura do corpo
Acessar Request.Form de forma síncrona força a leitura completa do corpo da requisição de forma bloqueante.
Código que causa starvation:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
// RUIM: Request.Form lê o body de forma síncrona app.MapPost("/upload", (HttpContext context) => { // Acesso síncrono a Form lê todo o body de forma bloqueante var form = context.Request.Form; var arquivo = form.Files.FirstOrDefault(); if (arquivo is null) return Results.BadRequest("Nenhum arquivo enviado"); using var stream = arquivo.OpenReadStream(); // Processa o arquivo... return Results.Ok(new { arquivo.FileName, arquivo.Length }); }); |
Por que causa starvation: a propriedade Request.Form internamente chama ReadForm(), que lê e faz o parse de todo o corpo da requisição de forma síncrona. Para uploads de arquivos, isso pode levar vários segundos dependendo do tamanho do arquivo e da velocidade da conexão. A thread fica bloqueada durante toda a leitura.
Código corrigido:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
// BOM: ReadFormAsync() lê o body de forma assíncrona app.MapPost("/upload", async (HttpContext context) => { // ReadFormAsync lê o body sem bloquear a thread var form = await context.Request.ReadFormAsync(); var arquivo = form.Files.FirstOrDefault(); if (arquivo is null) return Results.BadRequest("Nenhum arquivo enviado"); await using var stream = arquivo.OpenReadStream(); // Processa o arquivo... return Results.Ok(new { arquivo.FileName, arquivo.Length }); }); |
ReadFormAsync() lê o corpo da requisição de forma assíncrona, devolvendo a thread ao pool enquanto os dados são transferidos da rede.
Como diagnosticar thread pool starvation com ferramentas do .NET
O diagnóstico de thread pool starvation requer combinar métricas em tempo real com análise de call stacks. As ferramentas da plataforma .NET fornecem tudo o que você precisa.
Diagnóstico com dotnet-counters
dotnet-counters é a ferramenta mais rápida para confirmar se starvation está ocorrendo. Instale e execute:
|
1 2 3 4 5 |
# Instalar a ferramenta dotnet tool install --global dotnet-counters # Monitorar contadores de runtime dotnet-counters monitor -p <PID> --counters System.Runtime |
Os três contadores mais importantes para diagnosticar starvation:
| Contador | Valor normal | Valor sob starvation | O que indica |
|---|---|---|---|
threadpool-thread-count | Próximo ao número de CPUs (4-16) | Crescendo continuamente (50, 100, 200+) | Threads sendo criadas para compensar bloqueios |
threadpool-queue-length | 0 ou próximo de 0 | Acima de 0 persistentemente (10, 50, 100+) | Trabalho acumulado esperando thread disponível |
cpu-usage | Proporcional à carga | Baixo mesmo com alta latência | Threads bloqueadas não consomem CPU |
O padrão clássico de starvation é: CPU baixa, thread count crescendo, queue length acima de zero. Se a CPU está baixa mas o número de threads continua subindo, as threads não estão executando trabalho real — elas estão bloqueadas.
|
1 2 3 |
# Monitorar apenas os contadores relevantes para starvation dotnet-counters monitor -p <PID> --counters \ System.Runtime[threadpool-thread-count,threadpool-queue-length,cpu-usage,threadpool-completed-items] |
Diagnóstico com dotnet-stack
Depois de confirmar que há starvation com dotnet-counters, use dotnet-stack para identificar onde as threads estão bloqueadas:
|
1 2 3 4 5 |
# Instalar a ferramenta dotnet tool install --global dotnet-stack # Capturar stacks de todas as threads dotnet-stack report -p <PID> |
Procure por estes padrões nas call stacks — eles indicam threads bloqueadas:
# Padrão 1: sync-over-async (Task.Result / Task.Wait)
System.Threading.Tasks.Task.SpinThenBlockingWait
System.Threading.ManualResetEventSlim.Wait
# Padrão 2: Thread.Sleep
System.Threading.Thread.Sleep
# Padrão 3: Locks e semáforos síncronos
System.Threading.SemaphoreSlim.Wait
System.Threading.Monitor.Enter
# Padrão 4: I/O síncrono
System.IO.StreamReader.ReadToEnd
System.IO.Stream.ReadSe dezenas de threads mostram o mesmo padrão de bloqueio, você encontrou a causa raiz. Siga a stack para cima até encontrar o código da aplicação que está chamando a operação bloqueante.
O aviso do Kestrel
O Kestrel monitora automaticamente a saúde do thread pool através do seu mecanismo de heartbeat. Quando o heartbeat atrasa, o seguinte aviso é registrado:
warn: Microsoft.AspNetCore.Server.Kestrel[22]
Heartbeat took longer than "00:00:01" at "2024-01-15T10:23:45.1234567Z".
This could be caused by thread pool starvation.Para capturar essa mensagem, certifique-se de que o nível de log para Microsoft.AspNetCore.Server.Kestrel está em Warning ou inferior no appsettings.json:
|
1 2 3 4 5 6 7 |
{ "Logging": { "LogLevel": { "Microsoft.AspNetCore.Server.Kestrel": "Warning" } } } |
Diagnóstico avançado com dotnet-trace no .NET 9+
A partir do .NET 9, o runtime emite eventos WaitHandleWait que permitem rastrear exatamente quais operações de espera estão bloqueando threads. Use dotnet-trace para capturá-los:
|
1 2 3 4 5 6 |
# Instalar a ferramenta dotnet tool install --global dotnet-trace # Capturar eventos de wait com provider de threading dotnet-trace collect -p <PID> \ --providers "System.Threading.WaitHandle:0xFFFFFFFF:5" |
Abra o trace no PerfView ou Speedscope para visualizar quais wait handles estão causando bloqueios e por quanto tempo.
Monitoramento contínuo em produção com OpenTelemetry
Diagnosticar starvation em desenvolvimento é relativamente simples. O desafio real é detectá-la em produção antes que afete usuários. OpenTelemetry é a solução padrão da indústria para isso.
Configurando métricas de runtime com OpenTelemetry
Instale os pacotes necessários:
|
1 2 3 |
dotnet add package OpenTelemetry.Extensions.Hosting dotnet add package OpenTelemetry.Instrumentation.Runtime dotnet add package OpenTelemetry.Exporter.Prometheus.AspNetCore |
Configure a instrumentação de runtime no Program.cs:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
using OpenTelemetry.Metrics; var builder = WebApplication.CreateBuilder(args); builder.Services.AddOpenTelemetry() .WithMetrics(metrics => { metrics // Instrumentação de runtime: thread pool, GC, JIT .AddRuntimeInstrumentation() // Instrumentação de ASP.NET Core: request duration, active requests .AddAspNetCoreInstrumentation() // Exportar via Prometheus .AddPrometheusExporter(); }); var app = builder.Build(); // Endpoint para Prometheus scraping app.MapPrometheusScrapingEndpoint(); app.MapGet("/", () => "OK"); app.Run(); |
Métricas expostas para monitoramento de starvation
Com a instrumentação de runtime ativa, as seguintes métricas ficam disponíveis:
| Métrica OpenTelemetry | Descrição | Alerta recomendado |
|---|---|---|
dotnet.thread_pool.thread.count | Número atual de threads no pool | Acima de 3x o número de CPUs por mais de 30 segundos |
dotnet.thread_pool.queue.length | Itens na fila esperando thread | Acima de 0 por mais de 10 segundos |
dotnet.thread_pool.completed_items.count | Total de itens completados | Queda abrupta indica starvation |
Exemplo de regra de alerta no Prometheus
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 |
groups: - name: dotnet_threadpool rules: - alert: ThreadPoolStarvation expr: dotnet_thread_pool_thread_count > (system_runtime_cpu_count * 3) for: 30s labels: severity: critical annotations: summary: "Thread pool starvation detectada" description: > A aplicação {{ $labels.instance }} tem {{ $value }} threads no pool, indicando possível starvation. Investigue com dotnet-stack para identificar threads bloqueadas. - alert: ThreadPoolQueueGrowing expr: dotnet_thread_pool_queue_length > 0 for: 10s labels: severity: warning annotations: summary: "Fila do thread pool crescendo" description: > A aplicação {{ $labels.instance }} tem {{ $value }} itens na fila do thread pool, indicando que threads estão bloqueadas. |
ThreadPool.SetMinThreads é um curativo, não uma cura
Quando thread pool starvation é diagnosticada, a reação comum é aumentar o número mínimo de threads:
|
1 2 |
// "Solução" temporária: aumentar mínimo de threads ThreadPool.SetMinThreads(workerThreads: 200, completionPortThreads: 200); |
Isso funciona como paliativo, mas traz problemas:
- Não resolve a causa raiz: as threads continuam bloqueadas. Você apenas tem mais threads para bloquear antes que a fila comece a crescer.
- Cada thread consome ~1MB de stack: 200 threads extras consomem 200MB de memória só em stacks. Em containers com limite de memória, isso pode causar OOMKill.
SetMinThreadspode falhar silenciosamente: se você chamarSetMinThreadscom um valor menor que o atual ou com valores inválidos, ele retornafalsesem lançar exceção. Muitos desenvolvedores não verificam o retorno:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
// RUIM: ignora o retorno — pode não ter funcionado ThreadPool.SetMinThreads(200, 200); // BOM: verifica se a configuração foi aplicada bool sucesso = ThreadPool.SetMinThreads(workerThreads: 200, completionPortThreads: 200); if (!sucesso) { Console.WriteLine("AVISO: SetMinThreads falhou. " + "O valor pode ser menor que o mínimo atual do runtime."); } // Verificar o valor efetivo ThreadPool.GetMinThreads(out int workerMin, out int completionMin); Console.WriteLine($"MinThreads efetivo: worker={workerMin}, completionPort={completionMin}"); |
Configuração via runtimeconfig.json
Para aplicações que não podem ser modificadas em código, é possível configurar o mínimo de threads via runtimeconfig.json:
|
1 2 3 4 5 6 7 |
{ "runtimeOptions": { "configProperties": { "System.Threading.ThreadPool.MinThreads": 50 } } } |
Ou via variável de ambiente:
|
1 |
export DOTNET_ThreadPool_MinThreads=50 |
Use SetMinThreads apenas como medida emergencial enquanto trabalha na correção real: eliminar os bloqueios síncronos do código.
Programa completo que simula e diagnostica thread pool starvation
O programa abaixo cria uma API ASP.NET Core que demonstra starvation em ação. Ele expõe dois endpoints: um que causa starvation e outro que funciona corretamente. Você pode usar dotnet-counters para observar a diferença em tempo real.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 |
// Program.cs - Simulador de Thread Pool Starvation // Requisitos: .NET 8+ // Executar: dotnet run // Testar: usar os scripts de teste abaixo using System.Diagnostics; using System.Text.Json; var builder = WebApplication.CreateBuilder(args); builder.Services.AddHttpClient("ApiExterna", client => { client.BaseAddress = new Uri("https://httpbin.org/"); client.Timeout = TimeSpan.FromSeconds(30); }); var app = builder.Build(); // Endpoint de saúde que mostra estado do thread pool app.MapGet("/diagnostico", () => { ThreadPool.GetAvailableThreads(out int workerDisponivel, out int ioDisponivel); ThreadPool.GetMinThreads(out int workerMin, out int ioMin); ThreadPool.GetMaxThreads(out int workerMax, out int ioMax); return Results.Ok(new { ThreadPool = new { WorkerThreads = new { Disponivel = workerDisponivel, Minimo = workerMin, Maximo = workerMax, EmUso = workerMax - workerDisponivel }, IoThreads = new { Disponivel = ioDisponivel, Minimo = ioMin, Maximo = ioMax, EmUso = ioMax - ioDisponivel }, PendingWorkItemCount = ThreadPool.PendingWorkItemCount }, Processo = new { ThreadCount = Process.GetCurrentProcess().Threads.Count, WorkingSetMB = Process.GetCurrentProcess().WorkingSet64 / 1024 / 1024 } }); }); // RUIM: endpoint que causa starvation app.MapGet("/starvation/{id}", (int id, IHttpClientFactory httpClientFactory) => { var client = httpClientFactory.CreateClient("ApiExterna"); // Task.Result bloqueia a thread do pool var response = client.GetAsync($"delay/2").Result; var conteudo = response.Content.ReadAsStringAsync().Result; return Results.Ok(new { Id = id, Modo = "sync-over-async (RUIM)", Conteudo = conteudo[..Math.Min(100, conteudo.Length)] }); }); // BOM: endpoint que não causa starvation app.MapGet("/correto/{id}", async (int id, IHttpClientFactory httpClientFactory) => { var client = httpClientFactory.CreateClient("ApiExterna"); // await libera a thread durante a espera var response = await client.GetAsync($"delay/2"); var conteudo = await response.Content.ReadAsStringAsync(); return Results.Ok(new { Id = id, Modo = "async/await (BOM)", Conteudo = conteudo[..Math.Min(100, conteudo.Length)] }); }); Console.WriteLine("=== Simulador de Thread Pool Starvation ==="); Console.WriteLine(); Console.WriteLine("Endpoints:"); Console.WriteLine(" GET /diagnostico → Estado atual do thread pool"); Console.WriteLine(" GET /starvation/{id} → Causa starvation (sync-over-async)"); Console.WriteLine(" GET /correto/{id} → Não causa starvation (async/await)"); Console.WriteLine(); Console.WriteLine("Para monitorar, execute em outro terminal:"); Console.WriteLine($" dotnet-counters monitor -p {Environment.ProcessId} --counters System.Runtime"); Console.WriteLine(); app.Run(); |
Script para reproduzir starvation
Use o seguinte script bash para gerar carga no endpoint que causa starvation:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
#!/bin/bash # teste-starvation.sh # Envia 50 requisições simultâneas para o endpoint bloqueante echo "=== Teste de Thread Pool Starvation ===" echo "Enviando 50 requisições simultâneas para /starvation/..." echo "" for i in $(seq 1 50); do curl -s -o /dev/null -w "Request $i: HTTP %{http_code} em %{time_total}s\n" \ "http://localhost:5000/starvation/$i" & done wait echo "" echo "=== Teste concluído ===" |
Compare com o mesmo teste no endpoint correto:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
#!/bin/bash # teste-correto.sh # Envia 50 requisições simultâneas para o endpoint async echo "=== Teste do Endpoint Correto ===" echo "Enviando 50 requisições simultâneas para /correto/..." echo "" for i in $(seq 1 50); do curl -s -o /dev/null -w "Request $i: HTTP %{http_code} em %{time_total}s\n" \ "http://localhost:5000/correto/$i" & done wait echo "" echo "=== Teste concluído ===" |
Resultado esperado:
/starvation/{id}: as primeiras requisições completam em ~2s, mas as últimas levam 20-50s porque ficam na fila esperando threads/correto/{id}: todas as requisições completam em ~2s porque nenhuma thread é bloqueada
Observando com dotnet-counters
Enquanto o teste de starvation executa, observe no dotnet-counters:
[System.Runtime]
ThreadPool Thread Count 87 ← crescendo rapidamente
ThreadPool Queue Length 23 ← trabalho acumulado
ThreadPool Completed Work Item Count 1,247,891
CPU Usage (%) 3 ← CPU baixa = threads bloqueadasCompare com o teste do endpoint correto:
[System.Runtime]
ThreadPool Thread Count 9 ← estável
ThreadPool Queue Length 0 ← sem fila
ThreadPool Completed Work Item Count 1,248,102
CPU Usage (%) 12 ← CPU proporcional à cargaResumo das boas práticas para evitar thread pool starvation
| Prática | Ação |
|---|---|
Nunca use Task.Result ou Task.Wait() | Substitua por await |
Nunca use Thread.Sleep em código async | Substitua por await Task.Delay() |
| Nunca leia streams de forma síncrona | Use ReadToEndAsync() ou DeserializeAsync() |
Nunca use SemaphoreSlim.Wait() em código async | Substitua por await WaitAsync() |
Nunca acesse Request.Form diretamente | Use await ReadFormAsync() |
Monitore threadpool-thread-count e threadpool-queue-length | Configure alertas no OpenTelemetry |
Trate SetMinThreads como medida emergencial | Corrija o código bloqueante |
| Configure logs do Kestrel em nível Warning | Capture avisos de heartbeat |
FAQ – Perguntas Frequentes
1. Como sei se minha aplicação está sofrendo thread pool starvation e não outro tipo de problema de performance?
O padrão característico de thread pool starvation é: alta latência com CPU baixa. Se a CPU está abaixo de 20% mas as requisições demoram 10-30 segundos, provavelmente há threads bloqueadas. Confirme com dotnet-counters: se threadpool-thread-count está crescendo continuamente acima do número de CPUs e threadpool-queue-length permanece acima de zero, é starvation. Em problemas de CPU (hot path, algoritmo ineficiente), a CPU estaria alta. Em problemas de memória (GC pressure), o GC pause time estaria alto. Starvation é especificamente threads bloqueadas com CPU ociosa.
2. Por que o .NET não cria threads mais rápido quando detecta starvation?
O algoritmo de hill climbing do thread pool usa uma taxa deliberadamente lenta de 1-2 threads por segundo porque criar threads em excesso causa problemas piores: troca de contexto excessiva, consumo de memória (cada thread usa ~1MB de stack) e contenção de locks. O runtime assume que os bloqueios são temporários e que a demanda vai diminuir. A solução correta não é criar threads mais rápido, mas não bloquear threads em primeiro lugar. O design assíncrono do .NET é construído em torno dessa premissa: operações de I/O devem usar await para devolver a thread ao pool durante a espera.
3. ConfigureAwait(false) ajuda a prevenir thread pool starvation?
ConfigureAwait(false) não previne starvation diretamente. Ele apenas indica que a continuação após o await não precisa retornar ao synchronization context original (relevante em aplicações WPF/WinForms, não em ASP.NET Core). Em ASP.NET Core, que não tem synchronization context, ConfigureAwait(false) não tem efeito prático. O que previne starvation é usar await em vez de Task.Result ou Task.Wait(). O await em si já é a solução, independente do ConfigureAwait.
4. Thread pool starvation pode acontecer mesmo se todo o meu código é async/await?
Sim, embora seja raro. Pode ocorrer se você usa bibliotecas de terceiros que internamente fazem chamadas síncronas, ou se o volume de trabalho CPU-bound enfileirado via Task.Run é maior do que o pool consegue processar. Outro cenário é quando callbacks de timers ou event handlers executam operações bloqueantes. Use dotnet-stack para inspecionar todas as threads e identificar qual código está bloqueando. Verifique também dependências NuGet — nem todas as bibliotecas seguem boas práticas assíncronas.
5. Quando devo usar ThreadPool.SetMinThreads e qual valor devo configurar?
Use ThreadPool.SetMinThreads apenas como medida emergencial enquanto trabalha na correção real do código bloqueante. O valor depende do cenário: se você tem 100 requisições simultâneas e cada uma bloqueia por 2 segundos, precisaria de pelo menos 100 threads mínimas para evitar starvation durante picos. Uma regra prática é configurar um valor entre 50 e 200. Mas lembre-se: cada thread consome ~1MB de memória. Em containers com 512MB de limite, 200 threads extras podem causar OOMKill. Sempre verifique o retorno de SetMinThreads — ele retorna false se o valor for menor que o mínimo atual do runtime ou inválido, e muitos desenvolvedores ignoram esse retorno silenciosamente.
