Mi a különbség a blokkoló és nem blokkoló műveletek között a Node.js-ben?

Question

IT Interview Practice · Accepted Answer

**Blokkoló** műveletek szinkron módon futnak, és lefoglalják az egyetlen JavaScript szálat, amíg be nem fejeződnek — közben semmi más nem futhat. A **nem blokkoló** műveletek elindítják a munkát, azonnal visszatérnek, és az eredményt később szolgáltatják egy callback, Promise vagy esemény révén, így a szál szabad marad más feladatokra.

## Miért egyszálú a Node, mégis nem blokkoló

A JavaScriptod **egy** szálon fut, amelyet az **event loop** vezérel. Az I/O-t (fájlok, hálózat, DNS) a **libuv** végzi, amely az operációs rendszer aszinkron eszközeit és a háttérben egy kis **thread pool**-t használ. Amíg az a munka a szálon kívül zajlik, az event loop tovább dolgozza fel a többi callbacket. Amikor az I/O befejeződik, a callbackje sorba kerül és lefut.

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

// Blokkoló: az egész folyamat itt vár; egyetlen más kérés sem kerül kiszolgálásra.
const data = fs.readFileSync("big.json");
console.log("done reading");

// Nem blokkoló: azonnal visszatér; a callback akkor fut, amikor az I/O befejeződik.
fs.readFile("big.json", (err, data) => {
  console.log("done reading");
});
console.log("this logs first");
```

## Blokkoló vs nem blokkoló

| | Blocking | Non-blocking |
|---|---|---|
| API stílus | `*Sync` (`readFileSync`) | callback / Promise / `async` |
| Szál | Lefoglalja az event loopot | Felszabadítja az event loopot |
| Áteresztőképesség | Egyszerre egy kérés | Sok egyidejű kérés |
| Használat | Indító/CLI szkriptek | Szerverek, kéréskezelők |

## A csapda: a CPU-igényes munka továbbra is blokkol

A nem blokkoló csak az **I/O** esetén segít. Egy nehéz szinkron számítás (egy hatalmas payload JSON-elemzése, kriptográfia, képméretezés, szoros ciklus) még egy `async` függvényen belül is blokkolja az event loopot, mert maga a CPU-munka a JS szálon fut.

```js
// Blokkolja az event loopot a teljes cikluson át, annak ellenére, hogy "async".
async function hash(n) {
  let x = 0;
  for (let i = 0; i < n; i++) x += Math.sqrt(i); // CPU-igényes, szinkron
  return x;
}
```

Told át a CPU-igényes munkát **`worker_threads`**-be, egy child processbe vagy egy queue-ba, hogy az event loop reszponzív maradjon:

```js
const { Worker } = require("node:worker_threads");
new Worker("./cpu-task.js"); // külön szálon fut
```

## Ökölszabályok

- Soha ne hívj `*Sync` API-kat egy szerver kéréskezelőjén belül.
- Használj aszinkron I/O-t mindenhol a forró útvonalon (hot path).
- Told át a CPU-igényes munkát a fő szálról.
- Figyelj a véletlen blokkolásra: nagy `JSON.parse`, szinkron kriptográfia, katasztrofális visszalépéses (backtracking) regexek.

## Miért fontos

A Node teljesítménymodellje teljes mértékben azon múlik, hogy az egyetlen event-loop szál szabad maradjon. Egyetlen eltévedt blokkoló hívás — egy `readFileSync`, egy szinkron hash, egy lassú regex — **minden** egyidejű kérést megakaszt, nem csak azt, amelyik kiváltotta. Annak megértése, hogy mi blokkol és mi nem, a különbség egy több ezer kapcsolatra skálázódó szerver és egy terhelés alatt lefagyó szerver között.

	Blocking	Non-blocking
API stílus	`*Sync` (`readFileSync`)	callback / Promise / `async`
Szál	Lefoglalja az event loopot	Felszabadítja az event loopot
Áteresztőképesség	Egyszerre egy kérés	Sok egyidejű kérés
Használat	Indító/CLI szkriptek	Szerverek, kéréskezelők

Miért egyszálú a Node, mégis nem blokkoló

Blokkoló vs nem blokkoló

A csapda: a CPU-igényes munka továbbra is blokkol

Ökölszabályok

Miért fontos

Kapcsolódó kérdések