Node.js Event Loop Performance JavaScript Backend Asynchronous Programming

Як process.nextTick() тихо призводить до зупинки циклу подій Node.js

Рекурсивні виклики process.nextTick() ніколи не дозволяють libuv перейти до фази опитування, тому цикл подій Node.js залишається без дій. Як це виявити та виправити за допомогою setImmediate().

Видавець: REACTAPP.TOPДодано на сайт 22 вер. 2026 р.7 хв читання1723 слів

Джерела: Why `process.nextTick()` Can Starve Your Node.js Event Loop

Більшість інженерів, які працюють з бекендом, розуміють, що Node.js працює за допомогою однопотокового циклу подій, який запускається за рахунок libuv, і що саме неблокуючі асинхронні патерни забезпечують швидку та реактивну роботу API під навантаженням.

Проте у стандартній бібліотеці існує прихована небезпека: розмежування на те, що зазвичай називають макрозавданнями та мікрозавданнями.

У сервісах, які обробляють десятки тисяч запитів на секунду, використання process.nextTick() як безневинного способу для виконання коду „відразу після завершення поточної функції“ може призвести до повного зупинення продуктивності всього додатку.

Цей спосіб збою відомий як I/O starvation. Щоб зрозуміти, чому це відбувається, потрібно уважно подивитися, як V8 передає керування виконанням libuv, і навпаки.

1. Розбір етапів циклу подій Node.js

Коли запускається процес Node.js, середовище виконання ініціює цикл подій libuv. Цей цикл відповідає за координацію таймерів, мережевих сокетів, описників файлів та дочірніх процесів, роблячи це шляхом проходження через шість окремих фаз:

┌───────────────────────────┐
┌─>│          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', ...)
   └───────────────────────────┘

Цикл проходить через ці фази у суворій послідовності. Саме під час фази опитування середовище виконання блокується у очікуванні вхідних з’єднань, перевіряє ядро ОС на наявність даних у відкритих сокетах та запускає функції-відповіді JavaScript, пов’язані з цією діяльністю.

2. Де насправді знаходиться `process.nextTick()`?

Ось деталь, яка здивовує більшість розробників: process.nextTick() зовсім не є частиною циклу подій libuv.

Насправді це окремий механізм, який обробляється Node.js внутрішньо за допомогою своєї спеціалізованої черги мікрозавдань. Як тільки стек викликів V8 спорожнюється, двигун зобов’язаний повністю виконати всі залишені мікрозавдання, перш ніж повернути керування libuv.

Що робить ситуацію ще складнішою, — це порядок пріоритетів у самому шарі мікрозавдань:

[ 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 ]

Кожен калебек, зареєстрований через process.nextTick(), виконується раніше, ніж V8 вирішить будь-які стандартні обіцянки, і значно раніше, ніж libuv матиме можливість перейти до таймерів, перевірки калебеків чи відстеження надходження мережевого трафіку.

3. Анатомія проблеми голодування циклу подій

Оскільки Node.js наполягає на спорожненні всього чергування process.nextTick перед тим, як дозволити циклу продовжуватися, постійне додавання нових функцій-викликів у цю чергу фактично заморожує цикл подій на одному місці.

Візьмемо цей приклад пакетної обробки як ілюстрацію:

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");
});

Що відбувається насправді:

scheduleWork() виконує свою синхронну логіку.
Він додає ще один посилання на себе до чергування process.nextTick.
Стек викликів V8 спорожнюється, і Node.js перевіряє чергу мікрозавдань.
Він знаходить нещодавно додану до черги функцію scheduleWork та виконує її негайно.
Цей цикл повторюється без кінця.

Результат: час виконання ніколи не доходить до фази опитування libuv. Хоча ядро ОС вже прив’язало порт 3000 та отримує пакети TCP SYN, Node.js насправді ніколи не перевіряє цей сокет. Надходження HTTP-запитів накопичуються у черзі ядра, поки клієнти, що підключаються, не вичекають таймауту з кодом 504 Gateway Timeout.

4. `process.nextTick()` проти `setImmediate()`: практична різниця

Хочеться вважати process.nextTick() та setImmediate() приблизно однаковими інструментами, але вони знаходяться на протилежних кінцях порядку виконання часу виконання:

Функція | process.nextTick() | setImmediate()

Де відбувається чергування — мікрозавдання V8 проти фази перевірки libuv (макрозавдання) Коли відбувається виконання — одразу після того, як поточна стек-структура викликів спорожніла, проти наступного проходу циклу подій Чи добре поєднується з введенням/виведенням? — Ні, рекурсивне поєднання може повністю заблокувати роботу з введенням/виведенням, проти Так, це повертає керування назад у цикл Типове використання — нормалізація поведінки API та внутрішньої налаштування, проти розділення витратних операцій на пакети

5. Вирішення проблеми: кооперативне багатозадачне виконання за допомогою `setImmediate()`

Для асинхронних завдань, які вимагають часу для виконання, потрібен підхід, який ніколи не блокує поток та не ігнорує вхідні з’єднання. Цей підхід зазвичай називається кооперативним багатозадачним виконанням.

Замість того, щоб обробляти все одночасно, ви плануєте кожен залишковий фрагмент роботи за допомогою setImmediate(). Це прямо вказує Node.js повернути керування назад до циклу подій після кожного фрагмента, що дає можливість на етапі опитування прочитати очікуючі мережеві пакети, отримати відповіді від драйверів баз даних та обробити інші запити, що залишилися, перш ніж продовжувати.

/**
 * 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. Законні сценарії використання `process.nextTick()`

Усе це не означає, що process.nextTick() — це несправна API; це просто примітив низького рівня, який потрібно використовувати обережно. Насправді внутрішня структура Node.js покладається на нього для виконання двох важливих завдань.

A. Уникнення проблеми „Zalgo“

Якщо ви пишете функцію, яка приймає калебек, цей калебек має виконуватися завжди синхронно або завжди асинхронно — ніколи не по-різному залежно від умов виконання. Така непослідовність у часі спричиняє тонкі, важко відтворювані ситуації конкуренції в коді, який їх викликає.

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. Безпечне відправлення подій з конструктора

Якщо клас, який успадковується від EventEmitter, відправляє подію зсередини свого власного конструктора, виникає проблема: код, який створює цей об’єкт, ще не мав можливості зареєструвати жодних слухачів, тож подія просто загубиться.

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);
});

1. Розбір етапів циклу подій Node.js

2. Де насправді знаходиться process.nextTick()?

3. Анатомія проблеми голодування циклу подій

Що відбувається насправді:

4. process.nextTick() проти setImmediate(): практична різниця