Jaka jest różnica między operacjami blokującymi a nieblokującymi w Node.js?

Question

IT Interview Practice · Accepted Answer

Operacje **blokujące** (blocking) działają synchronicznie i zajmują jedyny wątek JavaScript aż do zakończenia — w międzyczasie nic innego nie może się wykonać. Operacje **nieblokujące** (non-blocking) rozpoczynają pracę, natychmiast zwracają sterowanie i dostarczają wynik później przez callback, Promise lub zdarzenie, więc wątek pozostaje wolny do wykonywania innych rzeczy.

## Dlaczego Node jest jednowątkowy, a mimo to nieblokujący

Twój JavaScript działa na **jednym** wątku napędzanym przez **pętlę zdarzeń** (event loop). I/O (pliki, sieć, DNS) jest delegowane do **libuv**, które pod spodem korzysta z asynchronicznych mechanizmów systemu operacyjnego i niewielkiej **puli wątków** (thread pool). Podczas gdy ta praca odbywa się poza wątkiem, pętla zdarzeń dalej przetwarza inne callbacki. Gdy I/O się kończy, jego callback trafia do kolejki i zostaje uruchomiony.

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

// Blocking: cały proces czeka tutaj; żadne inne żądanie nie jest obsługiwane.
const data = fs.readFileSync("big.json");
console.log("done reading");

// Non-blocking: zwraca natychmiast; callback uruchamia się, gdy I/O się zakończy.
fs.readFile("big.json", (err, data) => {
  console.log("done reading");
});
console.log("this logs first");
```

## Blokujące vs nieblokujące

| | Blokujące | Nieblokujące |
|---|---|---|
| Styl API | `*Sync` (`readFileSync`) | callback / Promise / `async` |
| Wątek | Zajmuje pętlę zdarzeń | Zwalnia pętlę zdarzeń |
| Przepustowość | Jedno żądanie naraz | Wiele współbieżnych żądań |
| Kiedy używać | Skrypty startowe/CLI | Serwery, obsługa żądań |

## Pułapka: praca obciążająca CPU nadal blokuje

Nieblokowanie pomaga tylko przy **I/O**. Ciężkie synchroniczne obliczenia (parsowanie ogromnego payloadu JSON, kryptografia, zmiana rozmiaru obrazu, ciasna pętla) blokują pętlę zdarzeń nawet wewnątrz funkcji `async`, ponieważ sama praca CPU wykonuje się na wątku JS.

```js
// Blokuje pętlę zdarzeń przez całą pętlę, mimo że jest „async".
async function hash(n) {
  let x = 0;
  for (let i = 0; i < n; i++) x += Math.sqrt(i); // obciąża CPU, synchroniczne
  return x;
}
```

Przenieś pracę obciążającą CPU do **`worker_threads`**, procesu potomnego lub kolejki, aby pętla zdarzeń pozostała responsywna:

```js
const { Worker } = require("node:worker_threads");
new Worker("./cpu-task.js"); // działa na osobnym wątku
```

## Zasady praktyczne

- Nigdy nie wywołuj API `*Sync` wewnątrz obsługi żądania na serwerze.
- Używaj asynchronicznego I/O wszędzie na ścieżce krytycznej (hot path).
- Przenieś pracę mocno obciążającą CPU poza główny wątek.
- Uważaj na przypadkowe blokowanie: duże `JSON.parse`, synchroniczna kryptografia, regexy z katastrofalnym nawrotem (backtracking).

## Dlaczego to ważne

Model wydajności Node opiera się całkowicie na utrzymywaniu wolnego wątku pętli zdarzeń. Jedno błąkające się wywołanie blokujące — `readFileSync`, synchroniczny hash, wolny regex — zatrzymuje **każde** współbieżne żądanie, nie tylko to, które je wywołało. Zrozumienie, co blokuje, a co nie, to różnica między serwerem skalującym się do tysięcy połączeń a takim, który zamiera pod obciążeniem.

	Blokujące	Nieblokujące
Styl API	`*Sync` (`readFileSync`)	callback / Promise / `async`
Wątek	Zajmuje pętlę zdarzeń	Zwalnia pętlę zdarzeń
Przepustowość	Jedno żądanie naraz	Wiele współbieżnych żądań
Kiedy używać	Skrypty startowe/CLI	Serwery, obsługa żądań

Dlaczego Node jest jednowątkowy, a mimo to nieblokujący

Blokujące vs nieblokujące

Pułapka: praca obciążająca CPU nadal blokuje

Zasady praktyczne

Dlaczego to ważne

Powiązane pytania