Qual è la differenza tra operazioni blocking e non-blocking in Node.js?

Question

IT Interview Practice · Accepted Answer

Le operazioni **blocking** vengono eseguite in modo sincrono e tengono occupato l'unico thread JavaScript finché non terminano — nel frattempo nient'altro può girare. Le operazioni **non-blocking** avviano il lavoro, ritornano immediatamente e consegnano il risultato più tardi tramite una callback, una Promise o un evento, così il thread resta libero di fare altro.

## Perché Node è single-threaded ma non-blocking

Il tuo JavaScript gira su **un** thread guidato dall'**event loop**. L'I/O (file, rete, DNS) è delegato a **libuv**, che sotto il cofano usa le funzionalità async del sistema operativo e un piccolo **thread pool**. Mentre quel lavoro avviene fuori dal thread, l'event loop continua a processare altre callback. Quando l'I/O si completa, la sua callback viene messa in coda ed eseguita.

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

// Blocking: l'intero processo aspetta qui; nessun'altra richiesta viene servita.
const data = fs.readFileSync("big.json");
console.log("done reading");

// Non-blocking: ritorna subito; la callback gira quando l'I/O finisce.
fs.readFile("big.json", (err, data) => {
  console.log("done reading");
});
console.log("this logs first");
```

## Blocking vs non-blocking

| | Blocking | Non-blocking |
|---|---|---|
| Stile API | `*Sync` (`readFileSync`) | callback / Promise / `async` |
| Thread | Occupa l'event loop | Libera l'event loop |
| Throughput | Una richiesta alla volta | Molte richieste concorrenti |
| Usare quando | Script di avvio/CLI | Server, gestori di richieste |

## La trappola: il lavoro CPU-bound blocca comunque

Il non-blocking aiuta solo con l'**I/O**. Un calcolo sincrono pesante (parsing JSON di un payload enorme, crittografia, ridimensionamento di immagini, un ciclo serrato) blocca l'event loop anche dentro una funzione `async`, perché il lavoro sulla CPU gira sul thread JS.

```js
// Blocca l'event loop per l'intero ciclo, nonostante sia "async".
async function hash(n) {
  let x = 0;
  for (let i = 0; i < n; i++) x += Math.sqrt(i); // CPU-bound, sincrono
  return x;
}
```

Sposta il lavoro CPU-bound su **`worker_threads`**, un child process o una queue affinché l'event loop resti reattivo:

```js
const { Worker } = require("node:worker_threads");
new Worker("./cpu-task.js"); // gira su un thread separato
```

## Regole pratiche

- Non chiamare mai API `*Sync` dentro un gestore di richieste su un server.
- Usa I/O async ovunque nel percorso caldo (hot path).
- Sposta il lavoro CPU-intensivo fuori dal thread principale.
- Attenzione ai blocking accidentali: `JSON.parse` grandi, crittografia sincrona, regex con catastrophic backtracking.

## Perché è importante

Il modello di prestazioni di Node dipende interamente dal mantenere libero l'unico thread dell'event loop. Una sola chiamata blocking fuori posto — un `readFileSync`, un hash sincrono, una regex lenta — blocca **ogni** richiesta concorrente, non solo quella che l'ha innescata. Capire cosa blocca e cosa no è la differenza tra un server che scala a migliaia di connessioni e uno che si congela sotto carico.

	Blocking	Non-blocking
Stile API	`*Sync` (`readFileSync`)	callback / Promise / `async`
Thread	Occupa l'event loop	Libera l'event loop
Throughput	Una richiesta alla volta	Molte richieste concorrenti
Usare quando	Script di avvio/CLI	Server, gestori di richieste

Perché Node è single-threaded ma non-blocking

Blocking vs non-blocking

La trappola: il lavoro CPU-bound blocca comunque

Regole pratiche

Perché è importante

Domande correlate