Hvad er forskellen mellem blokerende og ikke-blokerende operationer i Node.js?

Question

IT Interview Practice · Accepted Answer

**Blokerende** operationer kører synkront og holder på den enkelte JavaScript-tråd, indtil de er færdige — imens kan intet andet køre. **Ikke-blokerende** operationer starter arbejdet, vender straks tilbage og leverer resultatet senere via en callback, en Promise eller en event, så tråden forbliver fri til andre ting.

## Hvorfor Node er enkelttrådet, men alligevel ikke-blokerende

Din JavaScript kører på **én** tråd drevet af **event loop'en**. I/O (filer, netværk, DNS) uddelegeres til **libuv**, som under motorhjelmen bruger OS'ets asynkrone faciliteter og en lille **thread pool**. Mens det arbejde foregår uden for tråden, fortsætter event loop'en med at behandle andre callbacks. Når I/O'en er færdig, sættes dens callback i kø og køres.

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

// Blocking: hele processen venter her; ingen anden request betjenes.
const data = fs.readFileSync("big.json");
console.log("done reading");

// Non-blocking: vender straks tilbage; callback'en kører, når I/O er færdig.
fs.readFile("big.json", (err, data) => {
  console.log("done reading");
});
console.log("this logs first");
```

## Blokerende vs ikke-blokerende

| | Blocking | Non-blocking |
|---|---|---|
| API-stil | `*Sync` (`readFileSync`) | callback / Promise / `async` |
| Tråd | Holder event loop'en | Frigør event loop'en |
| Gennemløb | Én request ad gangen | Mange samtidige requests |
| Brug når | Opstarts-/CLI-scripts | Servere, request-handlere |

## Fælden: CPU-bundet arbejde blokerer stadig

Ikke-blokering hjælper kun med **I/O**. En tung synkron beregning (JSON-parsing af en enorm payload, kryptografi, billedskalering, en tæt løkke) blokerer event loop'en selv inde i en `async`-funktion, fordi selve CPU-arbejdet kører på JS-tråden.

```js
// Blokerer event loop'en gennem hele løkken, selvom den er "async".
async function hash(n) {
  let x = 0;
  for (let i = 0; i < n; i++) x += Math.sqrt(i); // CPU-bundet, synkront
  return x;
}
```

Flyt CPU-bundet arbejde til **`worker_threads`**, en child process eller en kø, så event loop'en forbliver responsiv:

```js
const { Worker } = require("node:worker_threads");
new Worker("./cpu-task.js"); // kører på en separat tråd
```

## Tommelfingerregler

- Kald aldrig `*Sync`-API'er inde i en request-handler på en server.
- Brug asynkron I/O overalt på den varme sti (hot path).
- Flyt CPU-tungt arbejde væk fra hovedtråden.
- Hold øje med utilsigtet blokering: stor `JSON.parse`, synkron kryptografi, regexes med katastrofal backtracking.

## Hvorfor det betyder noget

Nodes ydelsesmodel afhænger fuldstændigt af at holde den enkelte event loop-tråd fri. Ét vildfarent blokerende kald — et `readFileSync`, en synkron hash, en langsom regex — får **hver eneste** samtidig request til at gå i stå, ikke kun den, der udløste det. At forstå hvad der blokerer, og hvad der ikke gør, er forskellen mellem en server, der skalerer til tusindvis af forbindelser, og en, der fryser under belastning.

	Blocking	Non-blocking
API-stil	`*Sync` (`readFileSync`)	callback / Promise / `async`
Tråd	Holder event loop'en	Frigør event loop'en
Gennemløb	Én request ad gangen	Mange samtidige requests
Brug når	Opstarts-/CLI-scripts	Servere, request-handlere

Hvorfor Node er enkelttrådet, men alligevel ikke-blokerende

Blokerende vs ikke-blokerende

Fælden: CPU-bundet arbejde blokerer stadig

Tommelfingerregler

Hvorfor det betyder noget

Relaterede spørgsmål