Comment process.nextTick() affame silencieusement le cycle d’événements de Node.js

La plupart des ingénieurs backend comprennent que Node.js fonctionne grâce à un boucle d’événements à thread unique alimenté par libuv, et que les modèles asynchrones non bloquants sont ce qui permet à une API de rester rapide et réactive sous charge.

Pourtant, un danger subtil est intégré directement dans la bibliothèque standard : la distinction entre ce que l’on appelle communément des macro-tâches et des micro-tâches.

Dans les services qui gèrent des dizaines de milliers de requêtes par seconde, considérer process.nextTick() comme un raccourci inoffensif pour « exécuter ceci immédiatement après la fin de la fonction actuelle » peut paralyser l’ensemble du débit de votre application.

Ce mode de défaillance est connu sous le nom de famine I/O. Pour comprendre pourquoi il se produit, il faut examiner de près la manière dont V8 transfère l’exécution à libuv, et inversement.

1. Décortiquer les phases de la boucle d’événements de Node.js

Lorsqu’un processus Node.js démarre, l’environnement d’exécution lance le boucle d’événements libuv. Cette boucle est chargée de coordonner les compteurs temporels, les sockets réseau, les descripteurs de fichiers et les processus enfants, ce qu’elle fait en passant par six phases distinctes :

┌───────────────────────────┐
┌─>│          timers           │  setTimeout(), setInterval()
│  └─────────────┬─────────────┘
│  ┌─────────────┴─────────────┐
│  │     pending callbacks     │  System-level I/O callbacks
│  └─────────────┬─────────────┘
│  ┌─────────────┴─────────────┐
│  │        idle, prepare      │  Internal node operations
│  └─────────────┬─────────────┘
│  ┌─────────────┴─────────────┐
│  │           poll            │  Retrieve new I/O events, execute I/O callbacks
│  └─────────────┬─────────────┘
│  ┌─────────────┴─────────────┐
│  │           check           │  setImmediate() callbacks
│  └─────────────┬─────────────┘
│  ┌─────────────┴─────────────┐
└──┤      close callbacks      │  socket.on('close', ...)
   └───────────────────────────┘

La boucle progresse dans ces phases dans un ordre strict. Plus précisément, pendant la phase de sondage, l’environnement d’exécution est bloqué en attendant des connexions entrantes, vérifie le noyau du système d’exploitation pour détecter des données prêtes sur les sockets ouverts, et déclenche les fonctions de rappel JavaScript associées à ces activités.

2. Où se trouve réellement process.nextTick() ?

C’est ici que réside le détail qui prend la plupart des développeurs par surprise : process.nextTick() ne fait absolument pas partie de la boucle d’événements libuv.

C’est en réalité un mécanisme distinct, géré en interne par Node.js grâce à sa propre file d’attente dédiée aux microtâches. Une fois la pile d’appels V8 vide, le moteur est tenu de traiter entièrement toutes les microtâches en attente avant de restituer le contrôle à libuv.

Ce qui rend la situation encore plus complexe, c’est l’ordre de priorité existant au sein même de la couche des microtâches :

[ Active V8 Call Stack Finishes ]
               │
               ▼
┌──────────────────────────────────────┐
│       Microtask Queue 1              │
│       process.nextTick Queue         │ ◄── Emptied COMPLETELY first
└──────────────┬───────────────────────┘
               │
               ▼
┌──────────────────────────────────────┐
│       Microtask Queue 2              │
│       Promise / async-await Queue    │ ◄── Emptied second
└──────────────┬───────────────────────┘
               │
               ▼
[ Advance to Next libuv Event Loop Phase ]

Chaque callback enregistré via process.nextTick() s’exécute avant que V8 ne résolve les Promises standard, et bien avant que libuv n’ait l’occasion de passer aux timers, de vérifier les callbacks ou de surveiller le trafic réseau entrant.

3. L’anatomie de la famine du cycle d’événements

Puisque Node.js insiste pour vider toute la file d’attente process.nextTick avant de permettre au cycle de continuer, l’ajout continu de nouveaux appels de fonction dans cette file bloque en fait le cycle d’événements à un même endroit.

Prenons cet exemple de traitement par lots à titre d’illustration :

import http from "node:http";

// Mock worker performing continuous state reconciliation
function scheduleWork() {
  // Heavy in-memory computation
  performSanitization();
  // Recursively scheduling next iteration
  process.nextTick(scheduleWork);
}
// Kick off the background worker
scheduleWork();
// Spin up a standard HTTP API
const server = http.createServer((req, res) => {
  res.writeHead(200, { "Content-Type": "application/json" });
  res.end(JSON.stringify({ status: "healthy" }));
});
server.listen(3000, () => {
  console.log("Server listening on port 3000");
});

Ce qui se passe en arrière-plan :

• scheduleWork() exécute sa logique synchrone.
• Il ajoute une autre référence à lui-même dans la file d’attente process.nextTick.
• La pile d’appels V8 se vide, et Node.js vérifie la file des micro-tâches.
• Il découvre l’appel récemment ajouté à la file scheduleWork et le met immédiatement en exécution.
• Ce cycle se répète indéfiniment.

Résultat : le moteur d’exécution n’atteint jamais la phase de surveillance libuv. Bien que le noyau du système d’exploitation ait déjà attribué le port 3000 et reçoive des paquets TCP SYN, Node.js ne vérifie jamais réellement le socket. Les requêtes HTTP entrantes s’accumulent dans la file d’attente du noyau jusqu’à ce que les clients connectés expirent avec un 504 Gateway Timeout.

4. process.nextTick() vs. setImmediate() : La différence pratique

Il est tentant de considérer process.nextTick() et setImmediate() comme des outils à peu près identiques, mais ils se situent aux extrémités opposées de l’ordre d’exécution du moteur d’exécution :

Fonctionnalité | process.nextTick() | setImmediate()

Où cela est mis en file d’attente — la file de micro-tâches de V8 par rapport à la phase de vérification libuv (une macro-tâche) Quand cela est exécuté — immédiatement après que la pile d’appels actuelle soit vide par rapport à la prochaine itération du boucle d’événements Compatibilité avec les opérations I/O ? — Non, la chaînage récursif peut paralyser complètement les opérations I/O par rapport à Oui, cela restitue le contrôle à la boucle Utilisation typique — normaliser le comportement des API et les paramétrages internes par rapport à diviser les tâches coûteuses en lots

5. Comment y remédier : multitâche coopérative via setImmediate()

Pour des charges de travail asynchrones qui mettent du temps à s’achever, vous avez besoin d’un modèle qui ne verrouille jamais le thread ni n’ignore les connexions entrantes. Ce modèle est communément appelé multitâche coopérative.

Plutôt que de parcourir tout le travail en même temps, vous planifiez chaque partie restante avec setImmediate(). Cela indique explicitement à Node.js de restituer le contrôle au cycle d’événements après chaque partie, permettant ainsi à la phase de surveillance de lire les paquets réseau en attente, de recevoir des réponses des pilotes de base de données et de traiter d’autres requêtes en attente avant de continuer.

/**
 * Processes an array in chunks while yielding the thread
 * back to libuv to prevent event loop starvation.
 */
function processLargeDataset(records, chunkSize = 100) {
  let index = 0;

function processChunk() {
    const end = Math.min(index + chunkSize, records.length);

    // Process current slice
    for (; index < end; index++) {
      transformRecord(records[index]);
    }
    if (index < records.length) {
      // Yield control: libuv can now poll I/O, timers, and accept HTTP traffic
      setImmediate(processChunk);
    } else {
      console.log("Batch processing completed safely.");
    }
  }
  // Initial trigger
  setImmediate(processChunk);
}

6. Cas d’usage légitimes pour process.nextTick()

Tout cela ne signifie pas pour autant que process.nextTick() soit une API défectueuse — c’est simplement une primitive de bas niveau qui doit être utilisée avec prudence. En fait, les mécanismes internes de Node dépendent d’elle pour deux tâches importantes.

A. Éviter le problème « Zalgo »

Si vous écrivez une fonction qui prend un callback, ce dernier doit toujours s’exécuter de manière synchrone ou asynchrone — jamais en fonction des conditions de exécution. Un timing incohérent de ce type provoque des conditions de concurrence subtiles et difficiles à reproduire dans le code appelant.

import { readFile } from "node:fs";

const cache = new Map();
function getCachedConfig(filePath, callback) {
  if (cache.has(filePath)) {
    // Bad: callback(null, cache.get(filePath)); -> Sync execution!

    // Good: Ensures the caller's following lines run first, maintaining async contracts
    process.nextTick(() => {
      callback(null, cache.get(filePath));
    });
    return;
  }
  readFile(filePath, "utf-8", (err, data) => {
    if (err) return callback(err);
    cache.set(filePath, data);
    callback(null, data);
  });
}

B. Émettre des événements en toute sécurité depuis un constructeur

Si une classe qui étend EventEmitter émet un événement depuis son propre constructeur, cela pose un problème : le code qui instancie cet objet n’a pas encore eu l’occasion de enregistrer de listeners, donc l’événement sera simplement perdu.

import { EventEmitter } from "node:events";

class DatabaseConnection extends EventEmitter {
  constructor(connectionString) {
    super();
    this.connect(connectionString);
    // Defer the event until the consumer finishes binding .on('connected', ...)
    process.nextTick(() => {
      this.emit("connected", { ready: true });
    });
  }
  connect(str) {
    // Socket setup logic...
  }
}
// Consumer code:
const db = new DatabaseConnection("postgres://localhost:5432");
db.on("connected", (status) => {
  // Listener is bound BEFORE the nextTick callback fires!
  console.log("Database initialized safely:", status);
});

Directives pour les systèmes de production

• Ne permettez pas à une microtâche de se réplanifier elle-même. Une fonction qui continue d’appeler process.nextTick() sur elle-même ne permettra jamais au cycle d’avancer.

Préférez setImmediate() pour la répartition du travail. Si l’itération sur une collection prend plus de quelques millisecondes, divisez-la en parties et utilisez setImmediate() pour gérer les transitions entre elles.

Réservez process.nextTick() aux tâches nécessitant de la cohérence. Restrez son utilisation à des cas précis, tels que l’émission sécurisée d’événements pendant la construction ou le fait de s’assurer que les callbacks basés sur des valeurs mémorisées se résolvent au même moment qu’un callback sans mémoire.

Surveillez en permanence les retards du cycle d’événements. Quel que soit l’outil APM que vous utilisez — Datadog, New Relic, OpenTelemetry — suivez la métrique nodejs.eventloop.delay. Une augmentation continue est un signe précoce fort indiquant qu’un élément bloque de manière synchrone ou que le cycle des microtâches entrave le fonctionnement du système.