Ποια είναι η διαφορά μεταξύ blocking και non-blocking λειτουργιών στο Node.js;

Question

IT Interview Practice · Accepted Answer

Οι **blocking** λειτουργίες εκτελούνται σύγχρονα και κρατούν το μοναδικό νήμα της JavaScript μέχρι να τελειώσουν — στο μεταξύ τίποτα άλλο δεν μπορεί να τρέξει. Οι **non-blocking** λειτουργίες ξεκινούν τη δουλειά, επιστρέφουν αμέσως και παραδίδουν το αποτέλεσμα αργότερα μέσω callback, Promise ή event, ώστε το νήμα να παραμένει ελεύθερο για άλλα πράγματα.

## Γιατί το Node είναι μονονηματικό αλλά παρόλα αυτά non-blocking

Η JavaScript σου τρέχει σε **ένα** νήμα που οδηγείται από το **event loop**. Το I/O (αρχεία, δίκτυο, DNS) ανατίθεται στο **libuv**, το οποίο χρησιμοποιεί τις ασύγχρονες δυνατότητες του λειτουργικού συστήματος και ένα μικρό **thread pool** από κάτω. Ενώ αυτή η δουλειά γίνεται εκτός νήματος, το event loop συνεχίζει να επεξεργάζεται άλλα callbacks. Όταν ολοκληρωθεί το I/O, το callback του μπαίνει στην ουρά και εκτελείται.

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

// Blocking: όλη η διεργασία περιμένει εδώ· κανένα άλλο request δεν εξυπηρετείται.
const data = fs.readFileSync("big.json");
console.log("done reading");

// Non-blocking: επιστρέφει αμέσως· το callback τρέχει όταν τελειώσει το I/O.
fs.readFile("big.json", (err, data) => {
  console.log("done reading");
});
console.log("this logs first");
```

## Blocking vs non-blocking

| | Blocking | Non-blocking |
|---|---|---|
| Στυλ API | `*Sync` (`readFileSync`) | callback / Promise / `async` |
| Νήμα | Κρατά το event loop | Απελευθερώνει το event loop |
| Ρυθμαπόδοση | Ένα request τη φορά | Πολλά ταυτόχρονα requests |
| Χρήση όταν | Scripts εκκίνησης/CLI | Servers, request handlers |

## Η παγίδα: η δουλειά που δεσμεύει CPU εξακολουθεί να μπλοκάρει

Το non-blocking βοηθά μόνο με το **I/O**. Ένας βαρύς σύγχρονος υπολογισμός (JSON parsing τεράστιου payload, κρυπτογραφία, αλλαγή μεγέθους εικόνας, ένας σφιχτός βρόχος) μπλοκάρει το event loop ακόμη και μέσα σε μια `async` συνάρτηση, επειδή η ίδια η δουλειά της CPU τρέχει στο νήμα της JS.

```js
// Μπλοκάρει το event loop για όλον τον βρόχο, παρότι είναι "async".
async function hash(n) {
  let x = 0;
  for (let i = 0; i < n; i++) x += Math.sqrt(i); // δεσμεύει CPU, σύγχρονο
  return x;
}
```

Μετέφερε τη δουλειά που δεσμεύει CPU σε **`worker_threads`**, σε ένα child process ή σε μια ουρά, ώστε το event loop να παραμένει αποκρίσιμο:

```js
const { Worker } = require("node:worker_threads");
new Worker("./cpu-task.js"); // τρέχει σε ξεχωριστό νήμα
```

## Πρακτικοί κανόνες

- Μην καλείς ποτέ `*Sync` APIs μέσα σε έναν request handler σε server.
- Χρησιμοποίησε ασύγχρονο I/O παντού στο hot path.
- Μετέφερε τη βαριά για CPU δουλειά εκτός του κύριου νήματος.
- Πρόσεχε το ακούσιο μπλοκάρισμα: μεγάλο `JSON.parse`, σύγχρονη κρυπτογραφία, regexes με καταστροφικό backtracking.

## Γιατί έχει σημασία

Το μοντέλο απόδοσης του Node εξαρτάται εξ ολοκλήρου από το να διατηρείται ελεύθερο το μοναδικό νήμα του event loop. Μία και μόνο αδέσποτη blocking κλήση — ένα `readFileSync`, ένα σύγχρονο hash, ένα αργό regex — παγώνει **κάθε** ταυτόχρονο request, όχι μόνο εκείνο που το προκάλεσε. Το να κατανοείς τι μπλοκάρει και τι όχι είναι η διαφορά ανάμεσα σε έναν server που κλιμακώνεται σε χιλιάδες συνδέσεις και σε έναν που παγώνει υπό φορτίο.

	Blocking	Non-blocking
Στυλ API	`*Sync` (`readFileSync`)	callback / Promise / `async`
Νήμα	Κρατά το event loop	Απελευθερώνει το event loop
Ρυθμαπόδοση	Ένα request τη φορά	Πολλά ταυτόχρονα requests
Χρήση όταν	Scripts εκκίνησης/CLI	Servers, request handlers

Γιατί το Node είναι μονονηματικό αλλά παρόλα αυτά non-blocking

Blocking vs non-blocking

Η παγίδα: η δουλειά που δεσμεύει CPU εξακολουθεί να μπλοκάρει

Πρακτικοί κανόνες

Γιατί έχει σημασία

Σχετικές ερωτήσεις