Wat is het verschil tussen blocking en non-blocking bewerkingen in Node.js?

Question

IT Interview Practice · Accepted Answer

**Blocking** bewerkingen draaien synchroon en houden de enige JavaScript-thread bezet totdat ze klaar zijn — ondertussen kan er niets anders draaien. **Non-blocking** bewerkingen starten het werk, keren onmiddellijk terug en leveren het resultaat later via een callback, Promise of event, zodat de thread vrij blijft om andere dingen te doen.

## Waarom Node single-threaded is maar toch non-blocking

Jouw JavaScript draait op **één** thread aangedreven door de **event loop**. I/O (bestanden, netwerk, DNS) wordt gedelegeerd aan **libuv**, dat onder de motorkap de async-voorzieningen van het OS en een kleine **thread pool** gebruikt. Terwijl dat werk buiten de thread gebeurt, blijft de event loop andere callbacks verwerken. Wanneer de I/O klaar is, wordt de callback in de wachtrij gezet en uitgevoerd.

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

// Blocking: het hele proces wacht hier; geen enkele andere request wordt bediend.
const data = fs.readFileSync("big.json");
console.log("done reading");

// Non-blocking: keert onmiddellijk terug; de callback draait wanneer de I/O klaar is.
fs.readFile("big.json", (err, data) => {
  console.log("done reading");
});
console.log("this logs first");
```

## Blocking versus non-blocking

| | Blocking | Non-blocking |
|---|---|---|
| API-stijl | `*Sync` (`readFileSync`) | callback / Promise / `async` |
| Thread | Houdt de event loop bezet | Maakt de event loop vrij |
| Doorvoer | Eén request tegelijk | Veel gelijktijdige requests |
| Gebruik bij | Startup-/CLI-scripts | Servers, request handlers |

## De valkuil: CPU-gebonden werk blokkeert nog steeds

Non-blocking helpt alleen bij **I/O**. Een zware synchrone berekening (JSON parsen van een enorme payload, crypto, afbeeldingen verkleinen, een strakke loop) blokkeert de event loop zelfs binnen een `async`-functie, omdat het CPU-werk zelf op de JS-thread draait.

```js
// Blokkeert de event loop gedurende de hele loop, ondanks dat het "async" is.
async function hash(n) {
  let x = 0;
  for (let i = 0; i < n; i++) x += Math.sqrt(i); // CPU-gebonden, synchroon
  return x;
}
```

Verplaats CPU-gebonden werk naar **`worker_threads`**, een child process of een wachtrij, zodat de event loop responsief blijft:

```js
const { Worker } = require("node:worker_threads");
new Worker("./cpu-task.js"); // draait op een aparte thread
```

## Vuistregels

- Roep nooit `*Sync`-API's aan binnen een request handler op een server.
- Gebruik overal async I/O in het hot path.
- Verplaats CPU-intensief werk weg van de main thread.
- Let op onbedoelde blocking: grote `JSON.parse`, synchrone crypto, regexes met catastrofale backtracking.

## Waarom het belangrijk is

Het prestatiemodel van Node hangt volledig af van het vrij houden van de enige event-loop-thread. Eén verdwaalde blocking-aanroep — een `readFileSync`, een synchrone hash, een trage regex — legt **elke** gelijktijdige request stil, niet alleen degene die het veroorzaakte. Begrijpen wat wel en niet blokkeert, is het verschil tussen een server die schaalt naar duizenden verbindingen en een die vastloopt onder belasting.

	Blocking	Non-blocking
API-stijl	`*Sync` (`readFileSync`)	callback / Promise / `async`
Thread	Houdt de event loop bezet	Maakt de event loop vrij
Doorvoer	Eén request tegelijk	Veel gelijktijdige requests
Gebruik bij	Startup-/CLI-scripts	Servers, request handlers

Waarom Node single-threaded is maar toch non-blocking

Blocking versus non-blocking

De valkuil: CPU-gebonden werk blokkeert nog steeds

Vuistregels

Waarom het belangrijk is

Gerelateerde vragen