Настоящий цикл, libuv и пул потоков

Оборот в нашем планировщике состоит из трёх фаз: сроки, опрос, проверка. У настоящего цикла их шесть. Хорошая новость в том, что три недостающие вашего кода почти не касаются, — но знать о них стоит хотя бы затем, чтобы не искать в них объяснение, когда порядок окажется не тем.

Модель взяла из шести фаз три — ровно те, между которыми приходится выбирать, когда пишешь «продолжить потом». Остальные три в обычной программе либо пусты, либо заняты делами, которых из JavaScript не видно. Поэтому вывод прошлых статей остаётся в силе целиком: внутри колбэка setImmediate идёт раньше таймера на ноль, потому что фаза проверки стоит сразу за опросом, а до фазы сроков надо дожить до следующего оборота.

Между колбэками фаз нет вовсе: там два перерыва — очередь process.nextTick и очередь микрозадач, разобранные отдельно. Путаница здесь стоит дорого: «фаза микрозадач» — выражение, которого в libuv нет, и человек, который его произносит, обычно ждёт от цикла того, чего тот не делает.

Имён фаз в вашем коде не встретить: это ветки внутри одной функции libuv. Полезны они не сами по себе, а как ответ на вопрос, между чем и чем выбирает планировщик.

Отдельного разговора стоят две вещи, потому что как раз в них живёт всё, чего в модели нет. Первая есть в таблице — это фаза опроса, единственное место, где процесс на самом деле ждёт. Второй в таблице нет вовсе: пул потоков — не фаза, а четыре отдельных потока, которые приносят свои ответы в ту же фазу опроса.

Что делает процесс, когда делать нечего? Вопрос не праздный: «цикл событий» звучит как while (true), а такой цикл сжёг бы ядро процессора на пустом месте. На деле в фазе опроса libuv зовёт системный вызов, который сам усыпляет процесс, пока не случится одно из двух: в каком-нибудь из дескрипторов появятся байты или истечёт отпущенный срок. Вызовы у всех свои — kqueue в macOS, epoll в Linux, порты завершения в Windows, — а договор один: разбуди, когда будет что делать, но не позже чем через столько-то миллисекунд.

Сколько он готов спать, libuv считает перед каждым заходом: до ближайшего срока таймера. А если в очереди фазы проверки уже что-то лежит, спать нельзя вовсе, и отпущенный срок равен нулю — работа есть, и она ждёт этого же оборота. Оба правила в модели уже записаны, той самой строкой, которая перед фазами двигает часы вперёд. Посмотрим на неё глазами. Прогноз: сколько оборотов сделает цикл, если всей работы у него — один immediate и один таймер на сто тиков?

// Сто тиков ожидания и одна работа в фазе проверки: во что это обойдётся циклу
loop.immediate(() => console.log(`проверка: тик ${loop.now}, оборот ${loop.turn}`));
loop.timeout(() => console.log(`срок: тик ${loop.now}, оборот ${loop.turn}`), 100);

loop.run();
console.log(`оборотов всего: ${loop.turn}`);

Сто тиков ожидания обошлись в один оборот. Цикл не пересчитывал срок сто раз — он один раз посмотрел на ближайший и перевёл часы. И обратите внимание на первый оборот: часы на нём остались на нуле, потому что работа в фазе проверки уже была и спать было нельзя. Вот она, та самая длительность оборота, о которой модель молчит: у неё оборот стоит один тик всегда, а в жизни — либо столько, сколько выполнялись колбэки, либо столько, сколько цикл проспал.

Теперь то же самое на настоящем процессе. process.cpuUsage возвращает время, которое процессу выдал процессор, и его можно сравнить с временем, которое просто прошло. Секунду подождём таймер, секунду посчитаем в главном потоке. Прогноз: во сколько раз разойдутся эти две доли?

// Что стоит процессу секунда ожидания и что — секунда счёта.
// process.cpuUsage считает время, которое процессу выдал процессор.
import { setTimeout as подождать } from 'node:timers/promises';

const доля = async (работа) => {
  const процессор = process.cpuUsage();
  const начало = process.hrtime.bigint();
  await работа();
  const прошло = Number(process.hrtime.bigint() - начало) / 1e6;
  const { user, system } = process.cpuUsage(процессор);
  return (user + system) / 1000 / прошло;
};

const ожидание = await доля(() => подождать(1000));
const счёт = await доля(async () => {
  const до = Date.now() + 1000;
  let сумма = 0;
  while (Date.now() < до) сумма += Math.sqrt(сумма + 1);
  return сумма;
});

console.log('секунда ожидания таймера:');
console.log(`  процессорного времени ушло меньше сотой доли ожидания: ${ожидание < 0.01 ? 'да' : 'нет'}`);
console.log('секунда счёта в главном потоке:');
console.log(`  процессорного времени ушло больше девяти десятых: ${счёт > 0.9 ? 'да' : 'нет'}`);

секунда ожидания таймера:
  процессорного времени ушло меньше сотой доли ожидания: да
секунда счёта в главном потоке:
  процессорного времени ушло больше девяти десятых: да

Разница не в разы, а на три порядка: на машине автора доля процессорного времени в секунде ожидания от захода к заходу выходила от одной до пяти десятитысячных — полмиллисекунды на всю секунду в самом дорогом заходе. Ждущий процесс не стоит почти ничего, и это не бережливость Node, а свойство системного вызова: пока он не вернулся, планировщик операционной системы процессу процессор просто не выдаёт.

Вторая вещь, которой в модели нет вовсе, — пул потоков. Модель знает только главный поток, и «работа, которая идёт не здесь» изображается в ней таймером. В libuv это настоящие потоки операционной системы, и по умолчанию их четыре на весь процесс. Что бывает, когда заданий больше, мы уже видели на модели сервера: быстрое чтение файла ответило последним, потому что оба потока держали хеши паролей. Теперь посчитаем волны.

Достроим планировщик пулом: сколько-то потоков, общая очередь и правило «освободился поток — возьми следующее». Работа идёт не в главном потоке, поэтому часы цикла она не двигает, а готовый результат приходит фазе опроса, как приходят байты из сокета. Восемь заданий по десять тиков, потоков четыре. Прогноз: на каких тиках задания окажутся готовы?

// Пул: несколько потоков и общая очередь. Работа идёт не в главном потоке,
// поэтому часы цикла она не двигает, а готовый результат приходит фазе опроса.
const ЗАДАНИЙ = 8;
const пул = { потоков: 4, занято: 0, очередь: [] };

const начать = (работа) => {
  пул.занято += 1;
  loop.timeout(() => {
    пул.занято -= 1;
    loop.io(работа.готово);
    if (пул.очередь.length > 0) начать(пул.очередь.shift());
  }, работа.тиков);
};

пул.submit = (тиков, готово) => {
  const работа = { тиков, готово };
  if (пул.занято < пул.потоков) начать(работа);
  else пул.очередь.push(работа);
};

const готовы = [];
for (let i = 1; i <= ЗАДАНИЙ; i += 1) пул.submit(10, () => готовы.push(loop.now));

loop.run();
console.log(`потоков в пуле ${пул.потоков}, заданий ${ЗАДАНИЙ}, каждое по 10 тиков`);
console.log(`тики готовности: ${готовы.join(' ')}`);

Две волны по четыре, и число в волне — это в точности размер пула. Восемь заданий по десять тиков заняли не десять тиков и не восемьдесят, а двадцать: пул не ускоряет каждое задание, он ограничивает, сколько их идёт разом. Пятому досталось не «чуть позже», а ровно вдвое позже: оно дождалось, пока первая волна сойдёт целиком.

На настоящем пуле волны ловить по времени бесполезно: задания одинаковой длины расползаются по ядрам и финишируют вразнобой. Зато прекрасно ловится сам факт ожидания. Займём пул четырьмя долгими заданиями и следом отправим пятое, крошечное — на тысячу итераций вместо четырёх миллионов, — а через полсекунды посмотрим, выполнилось ли оно. Один и тот же файл запускается дважды: с UV_THREADPOOL_SIZE=4 и с UV_THREADPOOL_SIZE=8. Прогноз: в каком из двух случаев крошечное задание успеет?

// Пул занимают четыре долгих задания, следом в очередь встаёт пятое — крошечное.
// Файл запускает сам себя дважды: с пулом на четыре потока и на восемь.
import { pbkdf2 } from 'node:crypto';
import { execFileSync } from 'node:child_process';

const размер = process.env.UV_THREADPOOL_SIZE;

if (размер === undefined) {
  // размер пула читается один раз при его создании, поэтому менять его на ходу
  // нечем: каждому значению — свой процесс
  for (const потоков of ['4', '8']) {
    process.stdout.write(
      execFileSync(process.execPath, [import.meta.filename], { env: { ...process.env, UV_THREADPOOL_SIZE: потоков } }),
    );
  }
} else {
  let долгих = 0;
  let крошечное = false;
  let ударов = 0;

  for (let i = 1; i <= 4; i += 1) pbkdf2(`долгое ${i}`, 'соль', 4000000, 32, 'sha512', () => { долгих += 1; });
  pbkdf2('крошечное', 'соль', 1000, 32, 'sha512', () => { крошечное = true; });

  const сердце = setInterval(() => { ударов += 1; }, 10);
  setTimeout(() => {
    clearInterval(сердце);
    console.log(`UV_THREADPOOL_SIZE=${размер}: четыре долгих задания и крошечное пятым`);
    console.log(`  за полсекунды долгих завершилось: ${долгих}`);
    console.log(`  крошечное задание за это время выполнилось: ${крошечное ? 'да' : 'нет'}`);
    console.log(`  главный поток успел ударить больше тридцати раз: ${ударов > 30 ? 'да' : 'нет'}`);
  }, 500);
}

UV_THREADPOOL_SIZE=4: четыре долгих задания и крошечное пятым
  за полсекунды долгих завершилось: 0
  крошечное задание за это время выполнилось: нет
  главный поток успел ударить больше тридцати раз: да
UV_THREADPOOL_SIZE=8: четыре долгих задания и крошечное пятым
  за полсекунды долгих завершилось: 0
  крошечное задание за это время выполнилось: да
  главный поток успел ударить больше тридцати раз: да

При четырёх потоках крошечное задание за полсекунды не выполнилось — не потому, что оно долгое, а потому, что его не начинали: свободного потока не было. При восьми оно выполнилось сразу, и обратите внимание на вторую строку каждого блока: долгих за это время не завершилось ни одного ни там, ни там. Значит, разницу дал не темп работы, а наличие свободного потока. В этом весь пул: не «медленнее», а «не начато». Последняя же строка — про главный поток: он всё это время бил таймером как ни в чём не бывало, и четыре занятые работы ему не мешали.

Крошечное задание очередь не обгоняет: приоритетов в пуле нет. Пришёл позже — ждёшь, даже если работы на десятую долю миллисекунды.

// main.mjs
import { pbkdf2 } from 'node:crypto';
import { настройки } from './config.mjs';

// импорты пул не создают: загрузчик ES-модулей читает файлы синхронно
process.env.UV_THREADPOOL_SIZE = '8';

// а эта строка создаёт — и уже с восемью потоками
pbkdf2(пароль, настройки.соль, 600000, 32, 'sha512', готово);

Остался главный вопрос главы: почему файл читают потоком, а сокет — нет. Ответ прячется в договоре того самого системного вызова из фазы опроса. Он отвечает на вопрос «готов ли дескриптор», и для сокета вопрос осмысленный: байты либо пришли, либо нет. Для обычного файла на диске ответ всегда «готов» — и это чистая правда, файл никуда не едет, он лежит на месте. Вот только чтение после такого ответа честно упрётся в диск, и упрётся синхронно. Спрашивать у системы про файл бесполезно: ждать придётся всё равно, а ждать в фазе опроса нельзя — там ждёт сразу весь процесс. Остаётся отдать ожидание отдельному потоку.

Значит, граница проходит не между словами «ввод-вывод» и «счёт», а по тому, умеет ли система сообщить о готовности. Проверим, где она проходит на самом деле: займём пул теми же четырьмя долгими заданиями и попробуем разом всё — чтение файла и stat, сжатие, случайные байты, разрешение имени, соединение с собственным сервером и обычный таймер. Прогноз: что из этого встанет в очередь за хешами?

// Пул занят четырьмя долгими заданиями. Кто встанет в очередь за ними, а кто пойдёт мимо?
import { pbkdf2, randomBytes } from 'node:crypto';
import { readFile, stat } from 'node:fs';
import { lookup } from 'node:dns';
import { connect, createServer } from 'node:net';
import { gzip } from 'node:zlib';

for (let i = 1; i <= 4; i += 1) pbkdf2(`долгое ${i}`, 'соль', 4000000, 32, 'sha512', () => {});

const ИМЕНА = ['fs.readFile', 'fs.stat', 'zlib.gzip', 'crypto.randomBytes', 'dns.lookup', 'net.connect', 'setTimeout'];
const выполнилось = new Set();
const отметить = (имя) => () => выполнилось.add(имя);

readFile(import.meta.filename, отметить('fs.readFile'));
stat(import.meta.dirname, отметить('fs.stat'));
gzip(Buffer.alloc(64), отметить('zlib.gzip'));
randomBytes(32, отметить('crypto.randomBytes'));
lookup('localhost', отметить('dns.lookup'));
setTimeout(отметить('setTimeout'), 100);

const сервер = createServer((сокет) => сокет.end());
сервер.listen(0, '127.0.0.1', () => {
  const сокет = connect(сервер.address().port, '127.0.0.1', отметить('net.connect'));
  сокет.on('close', () => сервер.close());
});

setTimeout(() => {
  console.log('пул занят четырьмя долгими заданиями; за полсекунды выполнилось:');
  for (const имя of ИМЕНА) console.log(`  ${имя}: ${выполнилось.has(имя) ? 'да' : 'нет'}`);
}, 500);

пул занят четырьмя долгими заданиями; за полсекунды выполнилось:
  fs.readFile: нет
  fs.stat: нет
  zlib.gzip: нет
  crypto.randomBytes: нет
  dns.lookup: нет
  net.connect: да
  setTimeout: да

Пять операций из семи встали в очередь за хешами, и среди них две неожиданные. zlib.gzip и crypto.randomBytes — не ожидание вовсе, а счёт, и в пул они попали именно поэтому: считать в главном потоке им нельзя, а отдать работу больше некуда. А dns.lookup в списке ждущих — та самая ловушка, из-за которой пул кончается в самом неожиданном месте.

Про dns.lookup стоит сказать отдельно: это единственная сетевая по смыслу операция в левой колонке. Имя в адрес она превращает не сама, а системным вызовом getaddrinfo, и он синхронный — значит, нужен поток. Родственница dns.resolve ходит за тем же ответом по сети своими силами и в пул не попадает. Разница проявляется ровно тогда, когда её меньше всего ждёшь: сотня входов с pbkdf2 занимает пул, и вместе с чтением файлов встают все исходящие запросы по именам — хотя сеть при этом свободна.

Синхронных двойников в пуле нет: readFileSync и pbkdf2Sync считают в главном потоке и занимают именно его. Пул — это про асинхронные версии, и только про них.

Что делать, зависит от того, чем именно занят пул. Если счётом — его место не в пуле, а в отдельном потоке: пул и воркеры — разные вещи, и пул, в отличие от воркера, у вас один на весь процесс вместе со всеми чтениями файлов. Если настоящим диском — поднимают размер пула, но не выше числа ядер. А самое частое лекарство обыкновенное: не звать дорогой хеш чаще, чем нужно, — стоимость pbkdf2 назначаете вы сами, и что именно она покупает, разбирает глава про вход.

Осталось вернуть долг. Статья про фазы честно предупредила: есть место, где модель отвечает твёрдо, а Node не отвечает вовсе, — это setTimeout на ноль и setImmediate, назначенные на верхнем уровне главного модуля, до первого оборота цикла. Модель говорит: immediate первым. Node говорит: как повезёт.

Механика простая, и она вся в договоре о таймерах. Ноль — это не «сейчас», а «не раньше чем», и Node поднимает его до одной миллисекунды. Своё представление о времени цикл обновляет один раз за оборот, перед фазой сроков. Дальше решает арифметика: если от момента, когда таймер завели, до этого обновления прошла целая миллисекунда, срок уже наступил — и фаза сроков выполнит таймер прежде, чем дело дойдёт до фазы проверки. Не прошла — первым будет immediate. А сколько миллисекунд уйдёт на остаток запуска, не знает никто: это зависит от машины, от загрузки диска и от того, что ещё успел сделать ваш файл.

Почему такой опыт не записывают одним прогоном, сказано там же: череда одинаковых строк подряд выглядела бы как правило, а не как удачная серия. Поэтому прогон считает сам. Он четыреста восемьдесят раз запускает один и тот же файл из двух строк и печатает не проценты, а три утверждения, которые от процентов не зависят. Прогноз: какие из трёх окажутся верными?

// Один и тот же файл запускается много раз: что сработает первым в главном модуле —
// setTimeout(0) или setImmediate.
import { execFile } from 'node:child_process';
import { promisify } from 'node:util';

const запустить = promisify(execFile);
const ЗАПУСКОВ = 480;
const ПАРАЛЛЕЛЬНО = 8;
const итоги = [];

for (let с = 0; с < ЗАПУСКОВ; с += ПАРАЛЛЕЛЬНО) {
  const пачка = Array.from({ length: Math.min(ПАРАЛЛЕЛЬНО, ЗАПУСКОВ - с) }, () =>
    запустить(process.execPath, ['race-one.mjs'], { cwd: import.meta.dirname }));
  for (const { stdout } of await Promise.all(пачка)) итоги.push(stdout.trim());
}

const таймером = итоги.filter((с) => с === 'таймер').length;
console.log(`запусков одного и того же файла: ${ЗАПУСКОВ}`);
console.log(`  setImmediate был первым больше чем в трёх четвертях запусков: ${таймером < ЗАПУСКОВ / 4 ? 'да' : 'нет'}`);
console.log(`  хотя бы раз первым оказался таймер: ${таймером > 0 ? 'да' : 'нет'}`);
console.log(`  порядок был одним и тем же во всех запусках: ${таймером === 0 || таймером === ЗАПУСКОВ ? 'да' : 'нет'}`);

запусков одного и того же файла: 480
  setImmediate был первым больше чем в трёх четвертях запусков: да
  хотя бы раз первым оказался таймер: да
  порядок был одним и тем же во всех запусках: нет

Монета падает на setImmediate гораздо чаще — но падает и на другую сторону. На машине автора 22.09.2026 таймер оказывался первым от двух до четырёх десятков раз из 480 — примерно в четырёх-восьми случаях на сотню; замеры 21.09.2026 и 29.09.2026, четыре и восемь заходов той же длины, дали ту же вилку, причём загруженность машины на долю не влияла. Числа от захода к заходу разные, вывод один: «почти всегда» договором не бывает. Код, который опирается на этот порядок, — это код, который падает на чужой машине примерно раз в двадцать запусков, а на вашей не падает никогда.

Лечится это не перестановкой строк, а уходом со старта. Внутри любого колбэка ввода-вывода тот же вопрос имеет твёрдый ответ: immediate первым, всегда, потому что фаза проверки идёт сразу за опросом, — это доказано прогоном в статье про фазы. Поэтому «сделай после старта, но до всякого ввода-вывода» пишут одним setImmediate вокруг всего, а не двумя соседними назначениями, про которые предполагается, что они сработают в нужном порядке.

Проверить, опираетесь ли вы на жребий, просто: если ответ на вопрос «а что здесь раньше» зависит от того, на каком уровне файла стоят две строки, — опираетесь.

Глава кончается там же, где началась, — тремя вопросами к любой модели: синхронна ли она, замкнут ли её мир и названы ли упрощения. Первые два наш планировщик прошёл, а список умолчаний мы там же и составили — но тогда это были обещания на слово. Теперь под каждым пунктом есть измерение, а в списке прибавилось главное: пула в модели нет вовсе. Вот он целиком, и у каждой строки появился ответ, можно ли на модель в этом месте опираться, — чтобы дальше по части ею пользоваться, не гадая.

Последняя строка выделяется: обычно модель проще жизни, а здесь она строже. Такое случается с любой моделью, у которой мир замкнут: в ней нет места для «сколько-то миллисекунд ушло на запуск», и она отвечает там, где ответа нет. Заметить это можно было только сверкой с настоящим node, и это главный довод за то, чтобы каждую модель сверять, а не только строить.

Пользоваться планировщиком дальше можно и нужно, но с оговоркой, которая теперь звучит точно: он отвечает на вопрос «что за чем внутри колбэка» и не отвечает ни на «сколько это стоит», ни на «что будет на старте». Первое закрывает измерение, второе — привычка не назначать порядок на верхнем уровне файла.

Глава про цикл на этом закрыта, а вместе с ней — и разговор о том, кто выполняет колбэк. Следующая начинается с вопроса, который мы обходили молча: колбэк сокета не знает, кому нужны пришедшие байты, и раздаёт их излучатель событий — его мы тоже соберём сами.