Hva er forskjellen mellom blocking og non-blocking operasjoner i Node.js?

Question

IT Interview Practice · Accepted Answer

**Blocking**-operasjoner kjører synkront og holder den ene JavaScript-tråden opptatt til de er ferdige — ingenting annet kan kjøre i mellomtiden. **Non-blocking**-operasjoner starter arbeidet, returnerer umiddelbart og leverer resultatet senere via en callback, Promise eller event, slik at tråden holdes ledig til å gjøre andre ting.

## Hvorfor Node er single-threaded, men likevel non-blocking

JavaScript-en din kjører på **én** tråd drevet av **event loop**-en. I/O (filer, nettverk, DNS) delegeres til **libuv**, som under panseret bruker OS-ets async-funksjoner og en liten **thread pool**. Mens det arbeidet skjer utenfor tråden, fortsetter event loop-en å behandle andre callbacks. Når I/O-en er ferdig, legges callback-en i kø og kjøres.

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

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

// Non-blocking: returnerer umiddelbart; callback-en kjører når I/O-en er ferdig.
fs.readFile("big.json", (err, data) => {
  console.log("done reading");
});
console.log("this logs first");
```

## Blocking kontra non-blocking

| | Blocking | Non-blocking |
|---|---|---|
| API-stil | `*Sync` (`readFileSync`) | callback / Promise / `async` |
| Tråd | Holder event loop-en | Frigjør event loop-en |
| Gjennomstrømning | Én request om gangen | Mange samtidige requests |
| Bruk når | Oppstarts-/CLI-skript | Servere, request handlers |

## Fellen: CPU-bundet arbeid blokkerer fortsatt

Non-blocking hjelper bare med **I/O**. En tung synkron beregning (JSON-parsing av en enorm payload, crypto, bildeskalering, en tett løkke) blokkerer event loop-en selv inne i en `async`-funksjon, fordi selve CPU-arbeidet kjører på JS-tråden.

```js
// Blokkerer event loop-en hele løkken gjennom, til tross for at 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;
}
```

Flytt CPU-bundet arbeid til **`worker_threads`**, en child process eller en kø, slik at event loop-en holder seg responsiv:

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

## Tommelfingerregler

- Kall aldri `*Sync`-API-er inne i en request handler på en server.
- Bruk async I/O overalt i hot path-en.
- Flytt CPU-tungt arbeid vekk fra hovedtråden.
- Se opp for utilsiktet blocking: stor `JSON.parse`, synkron crypto, regexer med katastrofal backtracking.

## Hvorfor det er viktig

Nodes ytelsesmodell avhenger fullstendig av å holde den ene event loop-tråden ledig. Ett bortkommet blocking-kall — en `readFileSync`, en synkron hash, en treg regex — stanser **hver eneste** samtidig request, ikke bare den som utløste det. Å forstå hva som blokkerer og hva som ikke gjør det, er forskjellen på en server som skalerer til tusenvis av tilkoblinger og en som fryser under belastning.

	Blocking	Non-blocking
API-stil	`*Sync` (`readFileSync`)	callback / Promise / `async`
Tråd	Holder event loop-en	Frigjør event loop-en
Gjennomstrømning	Én request om gangen	Mange samtidige requests
Bruk når	Oppstarts-/CLI-skript	Servere, request handlers

Hvorfor Node er single-threaded, men likevel non-blocking

Blocking kontra non-blocking

Fellen: CPU-bundet arbeid blokkerer fortsatt

Tommelfingerregler

Hvorfor det er viktig

Relaterte spørsmål