Care este diferența dintre operațiile blocante și cele neblocante în Node.js?

Question

IT Interview Practice · Accepted Answer

Operațiile **blocante** (blocking) rulează sincron și rețin singurul fir JavaScript până se termină — între timp nimic altceva nu poate rula. Operațiile **neblocante** (non-blocking) pornesc lucrul, revin imediat și livrează rezultatul mai târziu printr-un callback, un Promise sau un eveniment, așa că firul rămâne liber să facă altceva.

## De ce Node este single-thread și totuși neblocant

JavaScript-ul tău rulează pe **un singur** fir condus de **event loop**. I/O (fișiere, rețea, DNS) este delegat către **libuv**, care folosește facilitățile asincrone ale sistemului de operare și un mic **pool de fire** (thread pool) în spate. În timp ce acea muncă se petrece în afara firului, event loop-ul continuă să proceseze alte callback-uri. Când I/O se termină, callback-ul său este pus în coadă și rulat.

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

// Blocking: întregul proces așteaptă aici; nicio altă cerere nu este servită.
const data = fs.readFileSync("big.json");
console.log("done reading");

// Non-blocking: revine imediat; callback-ul rulează când I/O se termină.
fs.readFile("big.json", (err, data) => {
  console.log("done reading");
});
console.log("this logs first");
```

## Blocant vs neblocant

| | Blocant | Neblocant |
|---|---|---|
| Stil de API | `*Sync` (`readFileSync`) | callback / Promise / `async` |
| Fir | Reține event loop-ul | Eliberează event loop-ul |
| Debit | O cerere pe rând | Multe cereri concurente |
| Când folosești | Scripturi de pornire/CLI | Servere, handlere de cereri |

## Capcana: munca legată de CPU tot blochează

Neblocarea ajută doar la **I/O**. Un calcul sincron greu (parsarea unui payload JSON uriaș, criptografie, redimensionare de imagini, o buclă strânsă) blochează event loop-ul chiar și în interiorul unei funcții `async`, deoarece munca de CPU în sine rulează pe firul JS.

```js
// Blochează event loop-ul pe toată durata buclei, deși e „async".
async function hash(n) {
  let x = 0;
  for (let i = 0; i < n; i++) x += Math.sqrt(i); // legat de CPU, sincron
  return x;
}
```

Mută munca legată de CPU în **`worker_threads`**, un proces copil sau o coadă, astfel încât event loop-ul să rămână responsiv:

```js
const { Worker } = require("node:worker_threads");
new Worker("./cpu-task.js"); // rulează pe un fir separat
```

## Reguli practice

- Nu apela niciodată API-uri `*Sync` în interiorul unui handler de cerere pe un server.
- Folosește I/O asincron peste tot pe calea critică (hot path).
- Mută munca grea de CPU în afara firului principal.
- Fii atent la blocări accidentale: `JSON.parse` mare, criptografie sincronă, regex-uri cu backtracking catastrofal.

## De ce contează

Modelul de performanță al Node depinde în totalitate de menținerea liberă a singurului fir al event loop-ului. Un singur apel blocant rătăcit — un `readFileSync`, un hash sincron, un regex lent — oprește **fiecare** cerere concurentă, nu doar pe cea care l-a declanșat. A înțelege ce blochează și ce nu este diferența dintre un server care se scalează la mii de conexiuni și unul care îngheață sub încărcare.

	Blocant	Neblocant
Stil de API	`*Sync` (`readFileSync`)	callback / Promise / `async`
Fir	Reține event loop-ul	Eliberează event loop-ul
Debit	O cerere pe rând	Multe cereri concurente
Când folosești	Scripturi de pornire/CLI	Servere, handlere de cereri

De ce Node este single-thread și totuși neblocant

Blocant vs neblocant

Capcana: munca legată de CPU tot blochează

Reguli practice

De ce contează

Întrebări conexe