Vad är skillnaden mellan blockerande och icke-blockerande operationer i Node.js?

Question

IT Interview Practice · Accepted Answer

**Blockerande** operationer körs synkront och håller den enda JavaScript-tråden tills de är klara — inget annat kan köras under tiden. **Icke-blockerande** operationer startar arbetet, returnerar omedelbart och levererar resultatet senare via en callback, ett Promise eller ett event, så tråden förblir fri att göra annat.

## Varför Node är enkeltrådad men ändå icke-blockerande

Din JavaScript körs på **en** tråd som drivs av **event loop**. I/O (filer, nätverk, DNS) delegeras till **libuv**, som under huven använder operativsystemets asynkrona funktioner och en liten **thread pool**. Medan det arbetet sker utanför tråden fortsätter event loop att bearbeta andra callbacks. När I/O är klar köas dess callback och körs.

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

// Blockerande: hela processen väntar här; ingen annan request betjänas.
const data = fs.readFileSync("big.json");
console.log("done reading");

// Icke-blockerande: returnerar omedelbart; callbacken körs när I/O är klar.
fs.readFile("big.json", (err, data) => {
  console.log("done reading");
});
console.log("this logs first");
```

## Blockerande kontra icke-blockerande

| | Blockerande | Icke-blockerande |
|---|---|---|
| API-stil | `*Sync` (`readFileSync`) | callback / Promise / `async` |
| Tråd | Håller event loop | Frigör event loop |
| Genomströmning | En request i taget | Många samtidiga requests |
| Använd vid | Uppstart/CLI-skript | Servrar, request-hanterare |

## Fällan: CPU-bundet arbete blockerar ändå

Icke-blockerande hjälper bara med **I/O**. En tung synkron beräkning (JSON-parsning av en enorm payload, kryptografi, bildomskalning, en tät loop) blockerar event loop även inuti en `async`-funktion, eftersom själva CPU-arbetet körs på JS-tråden.

```js
// Blockerar event loop under hela loopen, trots att den är "async".
async function hash(n) {
  let x = 0;
  for (let i = 0; i < n; i++) x += Math.sqrt(i); // CPU-bundet, synkront
  return x;
}
```

Flytta CPU-bundet arbete till **`worker_threads`**, en child process eller en kö så att event loop förblir responsiv:

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

## Tumregler

- Anropa aldrig `*Sync`-API:er inuti en request-hanterare på en server.
- Använd asynkron I/O överallt i den heta vägen (hot path).
- Flytta CPU-tungt arbete bort från huvudtråden.
- Se upp för oavsiktlig blockering: stor `JSON.parse`, synkron kryptografi, regex med katastrofal backtracking.

## Varför det är viktigt

Nodes prestandamodell hänger helt på att den enda event loop-tråden hålls fri. Ett enda vilset blockerande anrop — en `readFileSync`, en synkron hash, en långsam regex — stoppar **varje** samtidig request, inte bara den som utlöste det. Att förstå vad som blockerar och vad som inte gör det är skillnaden mellan en server som skalar till tusentals anslutningar och en som fryser under belastning.

	Blockerande	Icke-blockerande
API-stil	`*Sync` (`readFileSync`)	callback / Promise / `async`
Tråd	Håller event loop	Frigör event loop
Genomströmning	En request i taget	Många samtidiga requests
Använd vid	Uppstart/CLI-skript	Servrar, request-hanterare

Varför Node är enkeltrådad men ändå icke-blockerande

Blockerande kontra icke-blockerande

Fällan: CPU-bundet arbete blockerar ändå

Tumregler

Varför det är viktigt

Relaterade frågor