Що таке libuv і як він забезпечує асинхронний ввід/вивід у Node.js?

Node.js~5 хв читання

libuv - це крос-платформна C-бібліотека, яка дає Node.js event loop, пул потоків і асинхронні I/O-інтерфейси, загортаючи OS-механізми epoll на Linux, kqueue на macOS і IOCP на Windows в один уніфікований API.

Теорія

TL;DR

libuv знаходиться між JS-кодом Node.js і ОС, приховуючи різниці між платформами за одним API
Event loop опитує OS handles щодо завершення I/O без виділення потоку на кожен запит
Блокуючі операції (файловий I/O, DNS, crypto) йдуть у пул потоків - за замовчуванням 4 потоки
Мережевий I/O (TCP, UDP) минає пул потоків і використовує OS async polling напряму
Повільні відповіді під навантаженням crypto або файловим I/O - першим перевіряй UV_THREADPOOL_SIZE

Швидкий приклад

javascript

const fs = require('fs'); // fs використовує libuv під капотом

fs.readFile('data.txt', (err, data) => {
  if (err) throw err;
  console.log('Файл прочитано:', data.length, 'байт'); // спрацює після завершення I/O
});

console.log('Це виконується першим'); // event loop продовжує роботу одразу
// Виведення:
// Це виконується першим
// Файл прочитано: 1048576 байт

fs.readFile передає роботу у пул потоків libuv і одразу повертається. Callback спрацьовує пізніше, коли ОС закінчує читання. JS-потік ніколи не чекає.

Як libuv вписується в Node.js

JS-модулі Node.js (fs, net, crypto) викликають C++ bindings, які викликають функції libuv. Event loop libuv (uv_run) далі або реєструє операцію в OS poller для мережевого I/O, або кладе її в пул потоків для блокуючих операцій.

Node.js (JS / V8)
     |
C++ Bindings
     |
libuv event loop (uv_run)
     |                  |
OS pollers          Thread pool
epoll / kqueue      (4 потоки за замовчуванням)
IOCP (Windows)      fs, dns, crypto, zlib

JS-потік циклічно перевіряє, чи є завершена робота, і відправляє callbacks. Він не сидить в очікуванні диску чи мережі.

Пул потоків vs OS polling

Не всі async-операції йдуть одним шляхом. Розуміння цієї різниці пояснює більшість несподіванок у продуктивності Node.js.

OS polling (без потоків):

TCP/UDP сокети: http.get, net.connect, net.createServer
Pipes, signals, таймери

Пул потоків (4 потоки за замовчуванням):

Файлова система: fs.readFile, fs.writeFile, fs.stat
Crypto: crypto.pbkdf2, crypto.scrypt
DNS: dns.lookup (але не dns.resolve)
Стиснення: zlib.gzip, zlib.deflate

Мережевий I/O проходить через epoll/kqueue/IOCP без виділення потоку на з'єднання. Саме тому Node.js обслуговує тисячі одночасних HTTP-з'єднань в одному потоці. Про те, як callbacks проходять через фази, детальніше у статті як працює event loop в Node.js.

Фази event loop

Event loop libuv виконується фазами при кожній ітерації. З режимом UV_RUN_DEFAULT цикл такий:

Timers - запускає callbacks setTimeout і setInterval, чий час настав
Pending callbacks - I/O callbacks, відкладені з попередньої ітерації
Idle / Prepare - для внутрішнього використання libuv
Poll - блокується в очікуванні I/O-подій; відправляє готові I/O callbacks
Check - виконує callbacks setImmediate
Close callbacks - cleanup для закритих handles: socket.destroy() тощо

Фаза poll - місце, де loop насправді зупиняється. Якщо є активні I/O-операції, loop чекає тут до сигналу ОС або наближення таймера. setImmediate виконується у фазі check, тому завжди спрацьовує після I/O callbacks тієї ж ітерації.

Handles і requests

libuv використовує дві внутрішні абстракції, які варто знати на senior-рівні.

Handles - довгоживучі об'єкти: TCP-сервер, таймер, watcher файлів. Вони зберігаються між ітераціями loop і тримають процес живим.

Requests - одноразові операції: читання файлу, запис у сокет, DNS-запит. Завершуються один раз і зникають.

javascript

const net = require('net');
const server = net.createServer(() => {}); // Handle - живе до server.close()
server.listen(3000);

const fs = require('fs');
fs.readFile('./config.json', cb); // Request - одноразовий, не тримає процес живим

Коли дебажиш "чому скрипт завис" - виклич process._getActiveHandles(). TCP-сервер або забутий таймер одразу видно. Детальніше про цей патерн у lifecycle процесу Node.js.

Типові помилки

Sync crypto в обробниках запитів

javascript

// Блокує всі інші запити на ~300мс
app.post('/login', (req, res) => {
  const hash = crypto.pbkdf2Sync(req.body.password, salt, 100000, 512, 'sha512');
  // Поки виконується цей рядок, жодні інші запити не обробляються
  res.send('ok');
});

pbkdf2Sync тримає JS-потік до завершення. При 10 паралельних логінах вони обробляються послідовно. Використовуй async-варіант, який іде в пул потоків:

javascript

crypto.pbkdf2(req.body.password, salt, 100000, 512, 'sha512', (err, hash) => {
  res.send('ok');
});

Ігнорування виснаження пулу потоків

Чотири потоки здаються достатніми, поки не запустиш хешування паролів під навантаженням. Кожен виклик pbkdf2 займає 200-300мс. При дефолтному пулі 5-й паралельний запит чекає в черзі за першими чотирма. Я бачив, як це додавало дві секунди до p99 latency на сервісі, який виглядав цілком здоровим. Підвищуй UV_THREADPOOL_SIZE до старту процесу:

javascript

// Через env variable перед запуском node:
// UV_THREADPOOL_SIZE=32 node server.js

// Або на самому початку entry file, до будь-яких require()
process.env.UV_THREADPOOL_SIZE = '32';

Встановлення UV_THREADPOOL_SIZE занадто пізно

javascript

// НЕПРАВИЛЬНО - пул може бути вже ініціалізований
setTimeout(() => {
  process.env.UV_THREADPOOL_SIZE = '64';
}, 0);

Пул ініціалізується при першому використанні. Будь-який require модулів crypto, dns або fs до встановлення змінної фіксує дефолтні 4 потоки.

Пошук проблем event loop у V8

Коли API "рандомно зависає", розробники зазвичай дивляться на garbage collection або V8. Але V8 виконує JavaScript, а libuv керує event loop - це різні речі. Реальна причина зазвичай одна з: насичений пул потоків затримує callbacks, тривала sync-операція блокує JS-потік, або handle тримає loop від завершення. Профілюй через clinic.js або 0x. Додай console.log(process.hrtime.bigint()) біля підозрілих callbacks - одразу видно, де зникає час.

Де зустрічається в продакшені

Маршрути Express.js з fs.readFile або res.sendFile: читання диску через пул потоків libuv, TCP-відповідь через OS polling
Next.js використовує chokidar для hot module replacement; chokidar обгортає file watcher handles libuv
node-redis передає TCP-дані через handles libuv без пулу потоків
Виклики AWS SDK до S3 або DynamoDB - мережевий I/O, обробляється OS polling напряму
Масштабне хешування паролів через crypto.pbkdf2 на рівні продакшн-логінів вимагає підняття UV_THREADPOOL_SIZE

Follow-up питання

Q: Що відбувається з операціями пулу потоків, коли всі 4 потоки зайняті?
A: Нові запити ставляться в чергу всередині libuv і чекають, поки звільниться потік. Затримка зростає пропорційно глибині черги. 5-й паралельний виклик pbkdf2 займає приблизно в 2 рази більше часу ніж перші чотири.

Q: Чому мережевий I/O не використовує пул потоків?
A: TCP і UDP нативно асинхронні на рівні ОС. epoll, kqueue і IOCP підтримують polling тисяч сокетів без блокування потоку. libuv реєструє сокет у OS poller і отримує сповіщення, коли приходять дані. Потоки для цього не потрібні.

Q: В якому порядку виконуються фази event loop?
A: Timers, pending callbacks, idle/prepare, poll, check, close callbacks. Фаза poll блокується в очікуванні I/O. setImmediate виконується у фазі check, тому завжди спрацьовує після I/O callbacks тієї ж poll-ітерації.

Q: Як дебажити event loop, який не завершується?
A: Виклич process._getActiveHandles() і process._getActiveRequests() - побачиш, що тримає його живим. Типово це забутий таймер або відкритий TCP-сокет. У продакшені clinic.js дає flamegraph використання event loop по фазах.

Q (senior): Яка різниця між UV_RUN_DEFAULT, UV_RUN_ONCE і UV_RUN_NOWAIT?
A: UV_RUN_DEFAULT запускає loop до тих пір, поки не залишиться активних handles або requests, блокуючись у poll за потреби. UV_RUN_ONCE виконує одну ітерацію і блокується у poll максимум один раз. UV_RUN_NOWAIT виконує одну ітерацію, але не блокується у poll навіть якщо немає готових подій. Node використовує UV_RUN_DEFAULT. Вбудовування libuv в Electron або шар сумісності Deno іноді вимагає UV_RUN_NOWAIT, щоб не стопорити хост-loop.

Приклади

Базовий: порядок виконання при неблокуючому I/O

javascript

const fs = require('fs');

console.log('1: до readFile');

fs.readFile('./package.json', 'utf8', (err, data) => {
  if (err) throw err;
  console.log('3: розмір файлу:', data.length, 'символів');
});

console.log('2: після виклику readFile');

// Виведення:
// 1: до readFile
// 2: після виклику readFile
// 3: розмір файлу: 432 символи

readFile реєструє request у libuv і повертається без очікування. JS-потік доходить до рядка 2 до того, як диск прочитано. Коли ОС сигналізує про завершення, libuv ставить callback в чергу і event loop його виконує. Цей порядок - основа всіх async-патернів у Node.js.

Середній: виснаження пулу потоків в HTTP-сервері

javascript

const crypto = require('crypto');
const http = require('http');

// UV_THREADPOOL_SIZE = 4 за замовчуванням
// 5 паралельних викликів pbkdf2 на запит насичують пул

const server = http.createServer((req, res) => {
  const start = Date.now();
  let count = 0;

  for (let i = 0; i < 5; i++) {
    crypto.pbkdf2('secret', 'salt', 100000, 512, 'sha512', () => {
      count++;
      if (count === 5) {
        res.end(`Зайняло ${Date.now() - start}мс`);
      }
    });
  }
});

server.listen(3000);
// Перші 4 виклики pbkdf2 виконуються паралельно в 4 потоках
// 5-й чекає в черзі - загальний час приблизно подвоюється
// Рішення: UV_THREADPOOL_SIZE=8 node server.js

Звернись до цього endpoint і побачиш стрибок часу на 5-му завданні. Подвоєння розміру пулу вдвічі скорочує очікування. Це найпоширеніша продакшн-проблема, безпосередньо пов'язана з пулом потоків libuv.

Просунутий: lifecycle handles і час завершення процесу

javascript

const net = require('net');
const fs = require('fs');

// Handle тримає процес живим
const server = net.createServer(() => {});
server.listen(4000);

// Request сам по собі не тримає процес живим
fs.readFile('./data.txt', () => {
  console.log('файл прочитано');
});

// Без server.close() процес ніколи не завершиться:
// TCP handle досі активний у event loop libuv
setTimeout(() => {
  server.close(() => {
    console.log('сервер закрито - процес може завершитись');
  });
}, 2000);

console.log('активних handles:', process._getActiveHandles().length); // 2: сервер + таймер

libuv тримає uv_run активним поки є активні handles. Читання файлу - це request, не handle, тому воно не блокує вихід. TCP-сервер - це handle. Закрий його і loop завершиться. Розуміння різниці між handles і requests економить години при дебагінгу "чому мій скрипт завис після завершення роботи."

Коротка відповідь

Для співбесіди

Premium

Коротка відповідь допоможе вам впевнено відповідати на цю тему під час співбесіди.

Дочитали статтю?