Mitä eroa on estävillä (blocking) ja ei-estävillä (non-blocking) operaatioilla Node.js:ssä?

Question

IT Interview Practice · Accepted Answer

**Estävät (blocking)** operaatiot suoritetaan synkronisesti ja pitävät yksittäistä JavaScript-säiettä varattuna, kunnes ne valmistuvat — sillä välin mikään muu ei voi suoriutua. **Ei-estävät (non-blocking)** operaatiot käynnistävät työn, palaavat välittömästi ja toimittavat tuloksen myöhemmin callbackin, Promisen tai tapahtuman kautta, joten säie pysyy vapaana tekemään muita asioita.

## Miksi Node on yksisäikeinen mutta silti ei-estävä

JavaScript-koodisi suoritetaan **yhdellä** säikeellä, jota ohjaa **event loop**. I/O (tiedostot, verkko, DNS) delegoidaan **libuv**:lle, joka käyttää käyttöjärjestelmän asynkronisia toimintoja ja pientä **thread poolia** konepellin alla. Kun tuo työ tapahtuu säikeen ulkopuolella, event loop jatkaa muiden callbackien käsittelyä. Kun I/O valmistuu, sen callback laitetaan jonoon ja suoritetaan.

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

// Estävä: koko prosessi odottaa tässä; mitään muuta pyyntöä ei palvella.
const data = fs.readFileSync("big.json");
console.log("done reading");

// Ei-estävä: palaa välittömästi; callback suoritetaan kun I/O valmistuu.
fs.readFile("big.json", (err, data) => {
  console.log("done reading");
});
console.log("this logs first");
```

## Estävä vs ei-estävä

| | Estävä | Ei-estävä |
|---|---|---|
| API-tyyli | `*Sync` (`readFileSync`) | callback / Promise / `async` |
| Säie | Pitää event loopin varattuna | Vapauttaa event loopin |
| Läpäisykyky | Yksi pyyntö kerrallaan | Monta samanaikaista pyyntöä |
| Käytä kun | Käynnistys-/CLI-skriptit | Palvelimet, pyyntökäsittelijät |

## Ansa: CPU-sidonnainen työ estää silti

Ei-estävyys auttaa vain **I/O**:n kanssa. Raskas synkroninen laskenta (valtavan payloadin JSON-jäsennys, kryptografia, kuvan koon muutos, tiukka silmukka) estää event loopin jopa `async`-funktion sisällä, koska itse CPU-työ suoritetaan JS-säikeellä.

```js
// Estää event loopin koko silmukan ajan, vaikka on merkitty "async".
async function hash(n) {
  let x = 0;
  for (let i = 0; i < n; i++) x += Math.sqrt(i); // CPU-sidonnainen, synkroninen
  return x;
}
```

Siirrä CPU-sidonnainen työ **`worker_threads`**-moduulille, lapsiprosessille tai jonolle, jotta event loop pysyy responsiivisena:

```js
const { Worker } = require("node:worker_threads");
new Worker("./cpu-task.js"); // suoritetaan erillisellä säikeellä
```

## Nyrkkisäännöt

- Älä koskaan kutsu `*Sync`-rajapintoja palvelimen pyyntökäsittelijän sisällä.
- Käytä asynkronista I/O:ta kaikkialla kuumalla polulla (hot path).
- Siirrä CPU-raskas työ pois pääsäikeeltä.
- Varo tahatonta estämistä: suuri `JSON.parse`, synkroninen kryptografia, katastrofaalisella peruutuksella (backtracking) toimivat säännölliset lausekkeet.

## Miksi se on tärkeää

Noden suorituskykymalli riippuu täysin siitä, että yksittäinen event loop -säie pidetään vapaana. Yksi harhautunut estävä kutsu — `readFileSync`, synkroninen hash, hidas säännöllinen lauseke — pysäyttää **jokaisen** samanaikaisen pyynnön, ei vain sen, joka sen laukaisi. Sen ymmärtäminen, mikä estää ja mikä ei, on ero palvelimen, joka skaalautuu tuhansiin yhteyksiin, ja sellaisen välillä, joka jäätyy kuormituksen alla.

	Estävä	Ei-estävä
API-tyyli	`*Sync` (`readFileSync`)	callback / Promise / `async`
Säie	Pitää event loopin varattuna	Vapauttaa event loopin
Läpäisykyky	Yksi pyyntö kerrallaan	Monta samanaikaista pyyntöä
Käytä kun	Käynnistys-/CLI-skriptit	Palvelimet, pyyntökäsittelijät

Miksi Node on yksisäikeinen mutta silti ei-estävä

Estävä vs ei-estävä

Ansa: CPU-sidonnainen työ estää silti

Nyrkkisäännöt

Miksi se on tärkeää

Aiheeseen liittyvät kysymykset