Problema das chamadas bloqueantes

1. Introdução

Chamada bloqueante — é qualquer chamada que “bloqueia” a execução da thread até que alguma operação seja concluída. Normalmente é:

• Leitura ou escrita de dados (por exemplo, do disco).
• Uma consulta longa ao banco de dados ou à rede.
• Chamada a uma biblioteca externa que funciona “devagar”.

Nesses momentos a thread fica só parada, dando voltinhas e esperando: “E aí, quando vem a resposta?”

Exemplo da vida real

// Sua lógica principal
Console.WriteLine("Aguardando resposta do servidor...");
string response = CallServer(); // aqui tudo travou!
Console.WriteLine("Servidor respondeu: " + response);

Enquanto o servidor não responder, sua thread "travou" — e não pode fazer mais nada!

Como isso aparece nas aplicações

Em diferentes tipos de aplicações isso se manifesta de maneiras diferentes. Numa aplicação console parece que ela simplesmente “congelou” — o cursor para de piscar e não há reação. Na interface gráfica, por exemplo WinForms ou WPF, a janela de repente para de responder, aparece o famoso “not responding”, e o usuário já está pronto pra xingar seu software e seu sobrenome. E em aplicações server-side a situação é ainda pior: uma thread travada significa menos um usuário atendido.

2. Chamadas bloqueantes em C# na prática

Vamos “tocar” a situação com as mãos, usando um projeto de estudo. Suponha que temos uma aplicação da bola de cristal. Nela pode haver, por exemplo, um trecho assim:

Console.WriteLine("Digite sua pergunta para a bola de cristal:");
string question = Console.ReadLine(); // chamada bloqueante: esperamos a entrada!
Console.WriteLine("Pensando na resposta...");
Thread.Sleep(5000); // Emulação de trabalho demorado
Console.WriteLine("Resposta: tente novamente amanhã!");

• Console.ReadLine() — espera a entrada do usuário pelo tempo que for preciso (bloqueando a thread).
• Thread.Sleep(5000) — artificialmente faz uma pausa, congela a thread.

Pergunta: O que há de ruim se estamos só trabalhando numa aplicação console?

Resposta: Na aplicação console isso não é tão crítico — seu usuário mesmo espera. Mas e se o usuário não for um só? Se for um servidor recebendo 1000 requisições ao mesmo tempo? Ou uma app GUI, onde o usuário espera a interface reagir e não seus devaneios filosóficos?

Exemplo: Bloqueando o UI

// No handler de um botão no WinForms:
private void button1_Click(object sender, EventArgs e)
{
    label1.Text = "Carregando...";
    DoHeavyWork(); // operação pesada (por exemplo, consulta ao DB)
    label1.Text = "Pronto!";
}

Problema: Enquanto DoHeavyWork executa, a janela não atualiza a interface, não responde ao teclado e mouse, não é redesenhada. Se o usuário tentar fechar a janela — o Windows mostrará "não responde" e sugerirá finalizar a tarefa.

3. A grande dor do mundo multithread

Problemas das chamadas bloqueantes

• Desperdício de recursos. Cada thread (Thread) no .NET é um objeto relativamente “pesado”. O SO reserva memória para o seu stack (geralmente 1 MB), handles, sincronização etc. Se a thread fica “ociosa” (esperando arquivo ou rede), ela está fazendo trabalho inútil (“não fazendo nada, come memória”).
• Limitação de threads. Em aplicações server-side normalmente existe um pool de threads. Se todas as threads se bloqueiam — novas requisições não são atendidas. Por exemplo, no ASP.NET: se todas as threads disponíveis esperam resposta do banco, o site “congela” para novos usuários.
• Mau feedback da interface. Em apps GUI a janela para de responder até em ações básicas, como “fechar”, quando a UI-thread está bloqueada.
• Queda de performance. Quanto mais threads bloqueadas, mais trocas de contexto, maior carga no SO, mais lento fica tudo.

Fontes típicas de chamadas bloqueantes

Vamos ver quais chamadas podem “do nada” bloquear uma thread:

• Operações de rede: chamadas a APIs, download de arquivos, atualização de conteúdo.
• Disco/Sistema de arquivos: ler ou escrever arquivos grandes.
• Bancos de dados: consulta longa ao SQL Server ou mesmo a um banco local.
• Entrada do usuário: um longo ReadLine — pequeno, mas também bloqueia.
• Thread.Sleep, Task.Delay: “congelam” a thread artificialmente.

Exemplo (download de dados de um site)

using System.Net.Http;

HttpClient client = new HttpClient();
string result = client.GetStringAsync("https://google.com").Result; // chamada síncrona bloqueante!
Console.WriteLine(result);

O que acontece aqui? O membro .Result bloqueia a thread até receber a resposta!

4. Como entender que sua chamada está bloqueando a thread?

É simples: se o método não retorna o controle durante sua execução (espera, entrada, rede, disco) — é uma chamada bloqueante.

• Métodos com Thread.Sleep, Task.Wait, .Result, .Wait() — bloqueiam.
• Métodos que fazem “leitura/escrita” sem assíncrono — também.
• Janela travada ou servidor pendurado — sinal clássico.

Elemento visual: Fluxograma da chamada bloqueante

+-------------------+
| Início do método  |
+-------------------+
         |
         v
+-------------------+
| Chamada de método |
| bloqueante (ex.:  |
| ler arquivo)      |
+-------------------+
         |
         v
+-------------------+
| Espera término da |
| operação          |
+-------------------+
         |
         v
+-------------------+
| Retorna do método |
| e continua        |
+-------------------+

5. Por que chamadas bloqueantes são ruins em servidores

A maioria das aplicações modernas é de rede ou server-side. Mesmo se você faz um jogo, tem carregamento do servidor. Se você faz um site, vai ter rede e disco.

Imagine que seu servidor lida com 1000 requisições por segundo. Cada requisição precisa falar com o banco. Você escreve:

// Handler web
string data = db.ReadDataSync(); // bloqueio síncrono!
return new Response(data);

Enquanto a requisição espera o banco, a thread só fica ociosa. Uma requisição — ok. Mas quando elas se acumulam, todas as threads ficam ocupadas. Novas não conseguem entrar e ficam na fila. No fim o servidor vira não uma máquina, mas uma fila gigante onde todo mundo está esperando até alguém andar um centímetro.

Ilustração: "Processamento síncrono de requisições"

Requisição 1: pegou thread -> espera o banco -> liberou
Requisição 2: pegou thread -> espera o banco -> liberou
...
Requisição 100: sem threads livres, espera na fila...

6. Assíncrono — remédio para chamadas bloqueantes

Para combater bloqueio, usamos chamadas assíncronas. Em C# as palavras mágicas são: async e await.

Elas permitem:

• Não bloquear a thread (especialmente a valiosa UI- ou thread do servidor).
• Não ocupar recursos inutilmente.
• Melhorar a responsividade da GUI.
• Não “segurar” a thread enquanto uma operação lenta acontece.

Observação: não começamos a usar assíncrono “do dia pra noite”, porque ele requer entendimento de threads e bloqueios. Agora que você entendeu o sofrimento causado pelas chamadas bloqueantes, a abordagem assíncrona vai parecer um baita alívio pro seu cérebro e pros usuários.

Tabela: O que bloqueia e o que não bloqueia?

Console.ReadLine()

Thread.Sleep(1000)

File.ReadAllText()

Task.Delay(1000).Wait()

HttpClient.GetStringAsync().Result

await File.ReadAllTextAsync()

await Task.Delay(1000)

await HttpClient.GetStringAsync()

NB: await funciona só dentro de uma função assíncrona (async Task ...), que vamos ver em detalhe nas próximas aulas.

7. Erros clássicos ao trabalhar com chamadas bloqueantes

“Bloqueio do UI — usuário amaldiçoa tudo”

private void btnLoad_Click(object sender, EventArgs e)
{
    var data = BigFileReader.Read(@"C:\huge.dat"); // chamada bloqueante!
    textBox1.Text = data;
}

Enquanto o arquivo enorme não for lido — a janela “travará”.

“Servidor pendurado — clientes fogem”

public IActionResult Download()
{
    var content = File.ReadAllBytes("bigfile.zip"); // síncrono, demorado, bloqueia a thread do ASP.NET!
    return File(content, "application/zip");
}

Servidores pequenos (por exemplo, hospedados de graça) podem simplesmente “cair” com esse tipo de abordagem.

“Método assíncrono + .Wait()/.Result = morte síncrona”

public void LoadData()
{
    var result = DoAsyncWork().Result; // Bloqueia a thread!
}

.Result e .Wait() transformam até um código assíncrono bem escrito em uma chamada bloqueante simples.