Was ist der Unterschied zwischen blockierenden und nicht-blockierenden Operationen in Node.js?

Question

IT Interview Practice · Accepted Answer

**Blockierende** Operationen laufen synchron und halten den einzigen JavaScript-Thread, bis sie fertig sind — währenddessen kann nichts anderes laufen. **Nicht-blockierende** Operationen starten die Arbeit, kehren sofort zurück und liefern das Ergebnis später über einen Callback, ein Promise oder ein Event, sodass der Thread frei bleibt, um anderes zu tun.

## Warum Node einthreadig und dennoch nicht-blockierend ist

Dein JavaScript läuft auf **einem** Thread, der von der **Event Loop** gesteuert wird. I/O (Dateien, Netzwerk, DNS) wird an **libuv** delegiert, das unter der Haube die asynchronen Mechanismen des Betriebssystems und einen kleinen **Thread Pool** nutzt. Während diese Arbeit außerhalb des Threads geschieht, verarbeitet die Event Loop weiter andere Callbacks. Wenn die I/O abgeschlossen ist, wird ihr Callback in die Warteschlange gestellt und ausgeführt.

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

// Blocking: Der gesamte Prozess wartet hier; kein anderer Request wird bedient.
const data = fs.readFileSync("big.json");
console.log("done reading");

// Non-blocking: kehrt sofort zurück; der Callback läuft, wenn die I/O fertig ist.
fs.readFile("big.json", (err, data) => {
  console.log("done reading");
});
console.log("this logs first");
```

## Blockierend vs. nicht-blockierend

| | Blocking | Non-blocking |
|---|---|---|
| API-Stil | `*Sync` (`readFileSync`) | callback / Promise / `async` |
| Thread | Hält die Event Loop | Gibt die Event Loop frei |
| Durchsatz | Ein Request nach dem anderen | Viele gleichzeitige Requests |
| Verwenden bei | Startup-/CLI-Skripte | Server, Request-Handler |

## Die Falle: CPU-gebundene Arbeit blockiert trotzdem

Nicht-Blockieren hilft nur bei **I/O**. Eine schwere synchrone Berechnung (JSON-Parsing einer riesigen Payload, Kryptografie, Bildskalierung, eine enge Schleife) blockiert die Event Loop selbst innerhalb einer `async`-Funktion, weil die CPU-Arbeit selbst auf dem JS-Thread läuft.

```js
// Blockiert die Event Loop während der gesamten Schleife, obwohl "async".
async function hash(n) {
  let x = 0;
  for (let i = 0; i < n; i++) x += Math.sqrt(i); // CPU-gebunden, synchron
  return x;
}
```

Lagere CPU-gebundene Arbeit in **`worker_threads`**, einen Child Process oder eine Queue aus, damit die Event Loop reaktionsfähig bleibt:

```js
const { Worker } = require("node:worker_threads");
new Worker("./cpu-task.js"); // läuft auf einem separaten Thread
```

## Faustregeln

- Rufe niemals `*Sync`-APIs innerhalb eines Request-Handlers auf einem Server auf.
- Verwende asynchrone I/O überall im Hot Path.
- Verlagere CPU-intensive Arbeit vom Haupt-Thread weg.
- Achte auf versehentliches Blockieren: großes `JSON.parse`, synchrone Kryptografie, Regexes mit katastrophalem Backtracking.

## Warum es wichtig ist

Das Performance-Modell von Node hängt vollständig davon ab, den einzigen Event-Loop-Thread frei zu halten. Ein einziger verirrter blockierender Aufruf — ein `readFileSync`, ein synchroner Hash, ein langsames Regex — legt **jeden** gleichzeitigen Request lahm, nicht nur den, der ihn ausgelöst hat. Zu verstehen, was blockiert und was nicht, ist der Unterschied zwischen einem Server, der auf Tausende Verbindungen skaliert, und einem, der unter Last einfriert.

	Blocking	Non-blocking
API-Stil	`*Sync` (`readFileSync`)	callback / Promise / `async`
Thread	Hält die Event Loop	Gibt die Event Loop frei
Durchsatz	Ein Request nach dem anderen	Viele gleichzeitige Requests
Verwenden bei	Startup-/CLI-Skripte	Server, Request-Handler

Warum Node einthreadig und dennoch nicht-blockierend ist

Blockierend vs. nicht-blockierend

Die Falle: CPU-gebundene Arbeit blockiert trotzdem

Faustregeln

Warum es wichtig ist

Ähnliche Fragen