Qual é a diferença entre operações bloqueantes e não bloqueantes no Node.js?

Question

IT Interview Practice · Accepted Answer

Operações **bloqueantes** (blocking) rodam de forma síncrona e seguram a única thread do JavaScript até terminarem — nada mais pode rodar nesse meio-tempo. Operações **não bloqueantes** (non-blocking) iniciam o trabalho, retornam imediatamente e entregam o resultado depois via callback, Promise ou evento, então a thread fica livre para fazer outras coisas.

## Por que o Node é single-thread e ainda assim não bloqueante

Seu JavaScript roda em **uma** thread guiada pelo **event loop**. O I/O (arquivos, rede, DNS) é delegado ao **libuv**, que usa os recursos assíncronos do sistema operacional e uma pequena **thread pool** por baixo dos panos. Enquanto esse trabalho acontece fora da thread, o event loop continua processando outros callbacks. Quando o I/O termina, seu callback é enfileirado e executado.

```js
const fs = require("node:fs");

// Blocking: o processo inteiro espera aqui; nenhuma outra requisição é atendida.
const data = fs.readFileSync("big.json");
console.log("done reading");

// Non-blocking: retorna imediatamente; o callback roda quando o I/O termina.
fs.readFile("big.json", (err, data) => {
  console.log("done reading");
});
console.log("this logs first");
```

## Bloqueante vs não bloqueante

| | Bloqueante | Não bloqueante |
|---|---|---|
| Estilo de API | `*Sync` (`readFileSync`) | callback / Promise / `async` |
| Thread | Segura o event loop | Libera o event loop |
| Vazão | Uma requisição por vez | Muitas requisições concorrentes |
| Usar quando | Scripts de inicialização/CLI | Servidores, handlers de requisição |

## A armadilha: trabalho ligado à CPU ainda bloqueia

O não bloqueio só ajuda com **I/O**. Uma computação síncrona pesada (fazer parse de um payload JSON gigante, criptografia, redimensionar imagem, um loop apertado) bloqueia o event loop mesmo dentro de uma função `async`, porque o próprio trabalho de CPU roda na thread do JS.

```js
// Bloqueia o event loop durante todo o loop, apesar de ser "async".
async function hash(n) {
  let x = 0;
  for (let i = 0; i < n; i++) x += Math.sqrt(i); // ligado à CPU, síncrono
  return x;
}
```

Transfira o trabalho ligado à CPU para **`worker_threads`**, um processo filho ou uma fila, para que o event loop permaneça responsivo:

```js
const { Worker } = require("node:worker_threads");
new Worker("./cpu-task.js"); // roda em uma thread separada
```

## Regras práticas

- Nunca chame APIs `*Sync` dentro de um handler de requisição em um servidor.
- Use I/O assíncrono em todos os pontos do caminho crítico (hot path).
- Mova o trabalho pesado de CPU para fora da thread principal.
- Fique atento a bloqueios acidentais: `JSON.parse` grande, criptografia síncrona, regexes com backtracking catastrófico.

## Por que isso importa

O modelo de desempenho do Node depende inteiramente de manter livre a única thread do event loop. Uma única chamada bloqueante perdida — um `readFileSync`, um hash síncrono, um regex lento — trava **todas** as requisições concorrentes, não apenas a que a disparou. Entender o que bloqueia e o que não bloqueia é a diferença entre um servidor que escala para milhares de conexões e um que congela sob carga.

	Bloqueante	Não bloqueante
Estilo de API	`*Sync` (`readFileSync`)	callback / Promise / `async`
Thread	Segura o event loop	Libera o event loop
Vazão	Uma requisição por vez	Muitas requisições concorrentes
Usar quando	Scripts de inicialização/CLI	Servidores, handlers de requisição

Por que o Node é single-thread e ainda assim não bloqueante

Bloqueante vs não bloqueante

A armadilha: trabalho ligado à CPU ainda bloqueia

Regras práticas

Por que isso importa

Perguntas relacionadas