Quelle est la différence entre les opérations bloquantes et non bloquantes dans Node.js ?

Question

IT Interview Practice · Accepted Answer

Les opérations **bloquantes** s'exécutent de façon synchrone et retiennent l'unique thread JavaScript jusqu'à leur fin — rien d'autre ne peut s'exécuter pendant ce temps. Les opérations **non bloquantes** lancent le travail, retournent immédiatement et livrent le résultat plus tard via un callback, une Promise ou un événement, de sorte que le thread reste libre pour faire autre chose.

## Pourquoi Node est mono-thread mais non bloquant

Votre JavaScript s'exécute sur **un seul** thread piloté par l'**event loop**. Les I/O (fichiers, réseau, DNS) sont délégués à **libuv**, qui utilise les mécanismes asynchrones de l'OS et un petit **thread pool** en coulisses. Pendant que ce travail se déroule hors du thread, l'event loop continue de traiter d'autres callbacks. Quand l'I/O se termine, son callback est mis en file et exécuté.

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

// Bloquant : tout le processus attend ici ; aucune autre requête n'est servie.
const data = fs.readFileSync("big.json");
console.log("done reading");

// Non bloquant : retourne immédiatement ; le callback s'exécute à la fin de l'I/O.
fs.readFile("big.json", (err, data) => {
  console.log("done reading");
});
console.log("this logs first");
```

## Bloquant vs non bloquant

| | Bloquant | Non bloquant |
|---|---|---|
| Style d'API | `*Sync` (`readFileSync`) | callback / Promise / `async` |
| Thread | Retient l'event loop | Libère l'event loop |
| Débit | Une requête à la fois | De nombreuses requêtes concurrentes |
| À utiliser pour | Scripts de démarrage/CLI | Serveurs, gestionnaires de requêtes |

## Le piège : le travail lié au CPU bloque quand même

Le non-blocage n'aide que pour les **I/O**. Un calcul synchrone lourd (parsing JSON d'un énorme payload, cryptographie, redimensionnement d'image, boucle serrée) bloque l'event loop même à l'intérieur d'une fonction `async`, car le travail CPU lui-même s'exécute sur le thread JS.

```js
// Bloque l'event loop pendant toute la boucle, malgré le "async".
async function hash(n) {
  let x = 0;
  for (let i = 0; i < n; i++) x += Math.sqrt(i); // lié au CPU, synchrone
  return x;
}
```

Déportez le travail lié au CPU vers **`worker_threads`**, un processus enfant ou une file d'attente pour que l'event loop reste réactif :

```js
const { Worker } = require("node:worker_threads");
new Worker("./cpu-task.js"); // s'exécute sur un thread séparé
```

## Règles empiriques

- N'appelez jamais d'API `*Sync` à l'intérieur d'un gestionnaire de requête sur un serveur.
- Utilisez de l'I/O asynchrone partout sur le chemin critique (hot path).
- Déplacez le travail lourd en CPU hors du thread principal.
- Méfiez-vous du blocage accidentel : gros `JSON.parse`, cryptographie synchrone, regex à backtracking catastrophique.

## Pourquoi c'est important

Le modèle de performance de Node dépend entièrement du maintien libre de l'unique thread de l'event loop. Un seul appel bloquant égaré — un `readFileSync`, un hachage synchrone, une regex lente — bloque **toutes** les requêtes concurrentes, pas seulement celle qui l'a déclenché. Comprendre ce qui bloque et ce qui ne bloque pas fait la différence entre un serveur qui monte en charge jusqu'à des milliers de connexions et un serveur qui se fige sous la charge.

	Bloquant	Non bloquant
Style d'API	`*Sync` (`readFileSync`)	callback / Promise / `async`
Thread	Retient l'event loop	Libère l'event loop
Débit	Une requête à la fois	De nombreuses requêtes concurrentes
À utiliser pour	Scripts de démarrage/CLI	Serveurs, gestionnaires de requêtes

Pourquoi Node est mono-thread mais non bloquant

Bloquant vs non bloquant

Le piège : le travail lié au CPU bloque quand même

Règles empiriques

Pourquoi c'est important

Questions connexes