L'event loop exécute votre JavaScript sur un thread unique, donc tout ce qui est synchrone et prend du temps le bloque — et pendant le blocage, Node ne sert aucune autre requête, timer ou callback. Le blocage est presque toujours du travail CPU-bound ou une API *Sync, jamais de l'I/O asynchrone correctement awaité.
*Sync) — fs.readFileSync, fs.writeFileSync, child_process.execSync, zlib.gzipSync. Elles attendent sur place au lieu de déléguer à libuv.map/sort/filter sur de grands tableaux, calcul matriciel, traitement d'image/vidéo, parsing/sérialisation de structures énormes.JSON.parse / JSON.stringify — synchrones et en O(n) ; une charge de plusieurs Mo gèle l'event loop pendant tout le parsing.crypto.pbkdf2Sync, bcrypt en mode sync, hachage de gros buffers sur le thread principal.while (true), récursion non bornée, for sur des millions d'éléments avec du travail par élément.// Tout ceci bloque l'event loop — aucune autre requête n'est servie pendant ce temps :
const data = fs.readFileSync("big.json"); // I/O synchrone
const obj = JSON.parse(hugeString); // gros parsing
const hash = crypto.pbkdf2Sync(pw, salt, 1e6, 64, "sha512"); // crypto synchrone
for (let i = 0; i < 1e9; i++) { /* CPU */ } // boucle serrée
Envelopper du travail CPU dans une fonction
asyncn'aide pas —asyncne rend la main qu'auawait; le corps synchrone s'exécute quand même jusqu'au bout sur le thread de l'event loop.
perf_hooks.monitorEventLoopDelay() ou des bibliothèques comme blocked-at ; une latence croissante signifie que quelque chose accapare le thread.node --prof, clinic doctor/clinic flame, le profil CPU de Chrome DevTools pour trouver la frame synchrone chaude.*Sync (fs.promises.readFile, crypto.pbkdf2, zlib.gzip).worker_threads, un processus enfant, ou une file/un service externe.setImmediate/await pour que l'event loop puisse respirer entre les lots.const { Worker } = require("node:worker_threads");
// Déchargez le hachage coûteux pour que l'event loop reste réactif.
const worker = new Worker("./hash-worker.js", { workerData: { pw, salt } });
Dans Node, un seul appel bloquant punit tous les clients concurrents, pas seulement la requête qui l'a causé — la latence explose, les health checks expirent et le processus a l'air « figé » sous charge. Les recruteurs posent cette question pour voir si vous savez nommer les bloqueurs concrets (*Sync, gros JSON.parse, crypto synchrone, ReDoS, boucles CPU), les détecter avec l'outillage de latence de l'event loop, et les corriger en passant en asynchrone ou en déchargeant vers des worker threads. C'est la panne de performance Node la plus courante en production.
Une bibliothèque de questions d'entretien IT avec des réponses détaillées — du Junior au Senior.
Faire un don