Что происходит при синхронном чтении файла в Node.js?

Node.js построен вокруг однопоточного event loop, который обрабатывает асинхронные операции через неблокирующие системные вызовы. Синхронные функции вроде fs.readFileSync ломают эту модель: они выполняются прямо в главном потоке и не возвращают управление, пока операция не завершится.

Что происходит внутри

• Вызов fs.readFileSync уходит в libuv, который выполняет блокирующий системный вызов read().
• Пока ядро читает файл, поток JavaScript занят и не может выполнять другой код.
• Event loop стоит на месте: таймеры, сетевые события и микрозадачи не обрабатываются.
• После чтения функция возвращает Buffer или строку, и выполнение продолжается.

Пример

const fs = require('fs');

console.log('start');
const data = fs.readFileSync('big.txt', 'utf8'); // блокирует поток
console.log('file length:', data.length);
console.log('end');

// Пока файл читается, ни один setTimeout или HTTP-запрос не выполнится
setTimeout(() => console.log('timer'), 0);

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

Когда это допустимо

• При старте приложения: чтение конфигов, загрузка схем, инициализация.
• В CLI-скриптах и одноразовых утилитах, где конкурентность не важна.
• В тестах и сборках, где важнее простота, чем пропускная способность.

В серверном коде предпочтительнее асинхронные версии: fs.promises.readFile или fs.readFile с колбэком. Они делегируют работу пулу потоков libuv, а главный поток продолжает обрабатывать event loop.

Итог: синхронное чтение блокирует event loop и подходит только для старта или скриптов; в высоконагруженных приложениях используйте асинхронные API, чтобы сохранить конкурентность.