¿Cuál es la diferencia entre operaciones bloqueantes y no bloqueantes en Node.js?

Question

IT Interview Practice · Accepted Answer

Las operaciones **bloqueantes** se ejecutan de forma síncrona y retienen el único hilo de JavaScript hasta que terminan — mientras tanto no puede ejecutarse nada más. Las operaciones **no bloqueantes** inician el trabajo, retornan de inmediato y entregan el resultado más tarde mediante un callback, una Promise o un evento, de modo que el hilo queda libre para hacer otras cosas.

## Por qué Node es de un solo hilo y aun así no bloqueante

Tu JavaScript se ejecuta en **un** hilo gobernado por el **event loop**. El I/O (archivos, red, DNS) se delega a **libuv**, que por debajo usa las facilidades asíncronas del sistema operativo y un pequeño **thread pool**. Mientras ese trabajo ocurre fuera del hilo, el event loop sigue procesando otros callbacks. Cuando el I/O se completa, su callback se encola y se ejecuta.

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

// Blocking: todo el proceso espera aquí; ninguna otra request se atiende.
const data = fs.readFileSync("big.json");
console.log("done reading");

// Non-blocking: retorna de inmediato; el callback se ejecuta cuando termina el I/O.
fs.readFile("big.json", (err, data) => {
  console.log("done reading");
});
console.log("this logs first");
```

## Bloqueante vs no bloqueante

| | Blocking | Non-blocking |
|---|---|---|
| Estilo de API | `*Sync` (`readFileSync`) | callback / Promise / `async` |
| Hilo | Retiene el event loop | Libera el event loop |
| Rendimiento | Una request a la vez | Muchas requests concurrentes |
| Úsalo cuando | Scripts de arranque/CLI | Servidores, manejadores de requests |

## La trampa: el trabajo ligado a CPU sigue bloqueando

El no bloqueo solo ayuda con el **I/O**. Un cálculo síncrono pesado (parsear un JSON enorme, criptografía, redimensionar imágenes, un bucle apretado) bloquea el event loop incluso dentro de una función `async`, porque el propio trabajo de CPU se ejecuta en el hilo de JS.

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

Descarga el trabajo ligado a CPU en **`worker_threads`**, un child process o una cola para que el event loop siga respondiendo:

```js
const { Worker } = require("node:worker_threads");
new Worker("./cpu-task.js"); // se ejecuta en un hilo separado
```

## Reglas prácticas

- Nunca llames a APIs `*Sync` dentro de un manejador de request en un servidor.
- Usa I/O asíncrono en todas partes del hot path.
- Saca el trabajo intensivo en CPU del hilo principal.
- Vigila el bloqueo accidental: `JSON.parse` grande, criptografía síncrona, regexes con backtracking catastrófico.

## Por qué es importante

El modelo de rendimiento de Node depende por completo de mantener libre el único hilo del event loop. Una sola llamada bloqueante perdida — un `readFileSync`, un hash síncrono, un regex lento — detiene **todas** las requests concurrentes, no solo la que la provocó. Entender qué bloquea y qué no es la diferencia entre un servidor que escala a miles de conexiones y uno que se congela bajo carga.

	Blocking	Non-blocking
Estilo de API	`*Sync` (`readFileSync`)	callback / Promise / `async`
Hilo	Retiene el event loop	Libera el event loop
Rendimiento	Una request a la vez	Muchas requests concurrentes
Úsalo cuando	Scripts de arranque/CLI	Servidores, manejadores de requests

Por qué Node es de un solo hilo y aun así no bloqueante

Bloqueante vs no bloqueante

La trampa: el trabajo ligado a CPU sigue bloqueando

Reglas prácticas

Por qué es importante

Preguntas relacionadas