JS JavaScript · 30 вопросов · ~85 мин · ⏱ Таймер 25:00 · Сложный ·

Потоки и буферы Node.js

Профессиональный тест о Buffer, readable/writable streams, обратном давлении и pipeline. Нужно понимать границы UTF-8, режимы потока, событие drain, корректное завершение и последствия смешения разных способов потребления.

Отвечено: 0 из 30

⏱ --:--

💡 Инструкция: Выберите один ответ из пяти. В тесте 30 вопросов и 85 минут; код лучше читать построчно, не полагаясь на первое впечатление. После завершения откроются общий процент, 6 тематических шкал и объяснение каждого решения.

Вопрос 1 из 30

Почему Buffer.byteLength("🙂") не равен "🙂".length?

console.log("🙂".length);
console.log(Buffer.byteLength("🙂", "utf8"));

length считает UTF-16 units, а byteLength — байты UTF-8 Buffer.byteLength считает отдельные слова после декодирования строки Любой emoji занимает ровно один байт независимо от кодировки byteLength возвращает количество отображаемых символов строки Свойство length измеряет число кодовых точек UTF-32

Вопрос 2 из 30

Изменится ли исходный buffer после записи в subarray?

const source = Buffer.from([1,2,3]);
const view = source.subarray(0, 2);
view[0] = 9;
console.log(source);

Возникнет TypeError Только после await Да, subarray разделяет ту же память Изменение затронет источник, если Buffer был создан из строки без указания кодировки Нет, subarray всегда копия

Вопрос 3 из 30

Когда Buffer.allocUnsafe(1024) допустим?

function makeBuffer(source) {
  const buf = Buffer.allocUnsafe(1024);
  source.copy(buf, 0, 0, source.length);
  return buf; // опасно, если source короче 1024
}

Когда часть буфера можно прочитать до завершения его заполнения Когда требуется гарантированно заполненный нулями участок памяти Когда в буфере временно хранятся пароли и ключи доступа Всегда: allocUnsafe является полной заменой безопасного alloc Когда весь читаемый диапазон будет перезаписан до любого использования

Вопрос 4 из 30

Что произойдёт при Buffer.from("ff", "hex")?

TypeError Буфер с двумя байтами 102 Буфер с байтом 255 Пустой буфер Строка из двух символов

Вопрос 5 из 30

Почему buf.toString("utf8") на произвольной границе chunks может дать заменяющий символ?

toString изменяет исходный Buffer и поэтому портит следующий chunk Chunk может разрезать символ UTF-8; нужен потоковый декодер Node.js поддерживает в потоках только однобайтовую кодировку ASCII Граница каждого текстового chunk должна быть кратна десяти байтам Кодировка UTF-8 недоступна для метода Buffer.toString

Вопрос 6 из 30

Что означает push(null) в пользовательской Readable?

class Numbers extends Readable {
  _read() {
    if (this.n > 3) this.push(null);
    else this.push(String(this.n++));
  }
}

Добавить null как элемент Переключить objectMode Вызвать error Очистить internal buffer и продолжить Сигнализировать конец данных

Вопрос 7 из 30

Почему смешение on("data") и for await...of опасно?

stream.on("data", chunk => first(chunk));
for await (const chunk of stream) second(chunk);

Readable автоматически создаёт две независимые копии каждого chunk Оба потребителя влияют на режим чтения и могут неожиданно делить chunks Событие data недоступно, если источник выдаёт двоичные данные for await...of способен получать из потока только строки, но не Buffer Стандарт запрещает использовать оба способа на одном объекте

Вопрос 8 из 30

Что делает добавление data listener?

readable.on("data", chunk => consume(chunk));

Поток сразу закрывает связанный файловый дескриптор Readable переходит в flowing mode и начинает выдавать chunks сам Все Buffer автоматически преобразуются в строки base64 Добавление listener включает objectMode для последующих данных Источник приостанавливается до явного вызова readable.resume

Вопрос 9 из 30

Что даёт readable.setEncoding("utf8")?

После вызова Readable одновременно становится Writable Каждая строка автоматически разбирается как JSON-значение Поток выдаёт строки и собирает символы, разрезанные между chunks Источник файла заменяется новым потоком с текстовым содержимым Метод сжимает входные байты перед передачей обработчику

Вопрос 10 из 30

Зачем objectMode?

Чтобы поток автоматически сериализовал объекты в JSON Чтобы единицей очереди был объект, а не число его байтов Чтобы передавать DOM-узлы между Node.js и браузером Чтобы поток сам накапливал объекты сверх highWaterMark до завершения источника Чтобы каждый поступивший Buffer становился неизменяемым

Вопрос 11 из 30

Что означает writable.write(chunk) === false?

if (!destination.write(chunk)) {
  await once(destination, "drain");
}

Writable окончательно закрыт и больше не примет данные Chunk принят, но производителю надо дождаться события drain Записанный chunk был отброшен и должен быть создан заново Метод уже выбросил исключение, которое следует перехватить Тот же chunk нужно немедленно повторно передать в write

Вопрос 12 из 30

Почему этот цикл может раздувать память?

for (const chunk of chunks) {
  writable.write(chunk);
}
writable.end();

readFile возвращает Promise, который накапливается после каждой записи Цикл игнорирует false от write и быстрее заполняет внутреннюю очередь Цикл держит ссылки на уже записанные chunks до вызова end Node.js запрещает передавать Buffer в write внутри обычного цикла write блокирует поток, пока каждый байт физически не попадёт на диск

Вопрос 13 из 30

Является ли highWaterMark строгим максимальным объёмом памяти?

const writable = createWriteStream(path, { highWaterMark: 64 * 1024 });

Значение всегда равно полному размеру обрабатываемого файла Параметр применяется исключительно к HTTP-потокам Да, запись сверх highWaterMark технически невозможна Нет, это порог для сигнала; вызывающий код всё ещё может накопить больше После достижения порога сборщик мусора перестаёт работать

Вопрос 14 из 30

Как pipe обычно помогает с backpressure?

readable.pipe(transform).pipe(writable);

Каждая стадия pipe автоматически переносится в отдельный Worker pipe ставит readable на паузу при переполнении и продолжает после drain Механизм бесконечно увеличивает highWaterMark принимающего потока pipe удаляет chunks, которые writable не успевает принять Перед началом записи pipe всегда читает источник целиком в память

Вопрос 15 из 30

Что такое backpressure в objectMode?

Очередь ограничивается количеством объектов, а не обязательно байтами В objectMode запрещено передавать массивы и экземпляры классов Это проверка длины JSON-строки перед передачей объекта Каждый объект автоматически сжимается перед записью Так называется отмена любого объекта, помещённого в очередь

Вопрос 16 из 30

Почему pipeline предпочтительнее цепочки a.pipe(b).pipe(c) для критического кода?

import { pipeline } from "node:stream/promises";
await pipeline(source, gunzip, parser, destination);

Обычный pipe не передаёт chunks между последовательными стадиями pipeline поддерживает только один поток без преобразований pipeline согласует ошибки, завершение и уничтожение всей цепочки Использование pipeline отключает механизм backpressure Каждая стадия pipeline выполняется отдельным системным процессом

Вопрос 17 из 30

Что неверно в _transform?

class Converter extends Transform {
  _transform(chunk, encoding, callback) {
    this.push(convert(chunk));
    callback();
    callback();
  }
}

Callback вызывается дважды Chunk должен быть строкой Encoding всегда null Push запрещён Transform не может бросать

Вопрос 18 из 30

Как передать преобразованный chunk без this.push?

class Uppercase extends Transform {
  _transform(chunk, encoding, callback) {
    const output = chunk.toString().toUpperCase();
    // Как передать output дальше без this.push?
  }
}

return output this.write(output) resolve(output) callback(null, output) callback(output)

Вопрос 19 из 30

Как отменить pipeline по внешнему решению?

Передать null в Writable как специальный сигнал отмены Передать AbortSignal в поддерживаемый API и вызвать abort Изменить highWaterMark уже работающих потоков после запуска Всегда завершать весь процесс через process.exit при отмене Удалить ссылку source и рассчитывать на немедленную сборку мусора

Вопрос 20 из 30

Какой поток выполняет и чтение, и запись, преобразуя chunks?

Writable Transform/Duplex с логикой преобразования Buffer EventEmitter без методов Readable

Вопрос 21 из 30

Почему процесс падает на error у одиночного stream?

const stream = createReadStream("missing.txt");
stream.on("data", consume);

Необработанное событие error считается исключительной ситуацией После события close поток больше не способен отправить error В Node.js нельзя использовать try/catch вокруг операций потока Необработанный error завершает процесс с успешным кодом 0 Каждый Stream выполняется в Worker и не связан с EventEmitter

Вопрос 22 из 30

Чем end у Readable отличается от finish у Writable?

readable.on("end", onReadComplete);
writable.on("finish", onWriteComplete);

Оба события обязательно означают закрытие файлового дескриптора end завершает чтение, finish подтверждает передачу всех записей Оба события означают одно и то же состояние любой стороны потока finish сообщает, что источник больше не выдаёт данные, а end — что приёмник всё записал end подтверждает закрытие ресурса чтения, а finish — отсутствие ошибок записи

Вопрос 23 из 30

Что означает ERR_STREAM_PREMATURE_CLOSE?

try {
  await pipeline(source, transform, destination);
} catch (error) {
  console.error(error.code, error.cause);
}

Все стадии завершились штатно и освободили свои ресурсы Источник передал пустой JSON-документ вместо объекта Поток получил имя неизвестной текстовой кодировки Одна из стадий закрылась раньше ожидаемого завершения протокола Размер Buffer оказался меньше настроенного highWaterMark

Вопрос 24 из 30

Как проверить backpressure в тесте?

Использовать пустой файл, который завершается до появления давления Увеличить лимит памяти, чтобы очередь гарантированно не заполнилась Создать медленный Writable с малым буфером и управляемым callback Подключить только быстрый PassThrough без замедляющего потребителя Отключить assertions и наблюдать объём процесса вручную

Вопрос 25 из 30

Почему событие close не доказывает успешную обработку всех данных?

Ресурс мог закрыться после ошибки; нужны finish/end или результат pipeline Close означает успешный HTTP-ответ независимо от вида потока Событие close всегда возникает до создания объекта Stream В современных потоках Node.js событие close отсутствует Close обязательно отправляется дважды: до и после finish

Вопрос 26 из 30

Почему data += chunk может стать дорогим на большом тексте?

let data = "";
for await (const chunk of readable) {
  data += chunk;
}

Любой chunk в текстовом потоке автоматически является числом Оператор + выполняет отдельный сетевой запрос для каждой части V8 не позволяет создавать строки размером больше одного килобайта Строки изменяются на месте, поэтому старое значение сохраняется целиком Конкатенация копирует растущие строки и уничтожает потоковый выигрыш

Вопрос 27 из 30

Когда readFile разумнее stream?

Для файла в несколько гигабайт при жёстком ограничении памяти Когда требуется согласовать скорость источника с сетевым получателем Никогда: потоковая обработка всегда проще и быстрее readFile Для бесконечного источника, который никогда не завершает чтение Когда файл заведомо мал, нужен целиком и важнее простой lifecycle

Вопрос 28 из 30

Как выбрать highWaterMark?

createReadStream(path, { highWaterMark: measuredChunkSize });

Измерить пропускную способность, задержку и память на реальной нагрузке Задавать максимально допустимое число независимо от потребителя Всегда использовать один байт, чтобы очередь не росла Выбрать значение, равное полному размеру доступного диска Устанавливать случайный порог при каждом запуске приложения

Вопрос 29 из 30

Почему слишком мелкие chunks снижают throughput?

На тот же объём приходится больше вызовов, событий и системных операций Разбиение на маленькие части неизбежно изменяет содержимое данных Buffer не поддерживает значения меньше установленного размера Механизм backpressure перестаёт работать при небольших буферах Из-за маленьких chunks поток становится полностью синхронным

Вопрос 30 из 30

Что важно при fan-out одного потока к двум медленным потребителям?

pipe самостоятельно хранит неограниченную очередь для каждого выхода Дублирование данных между двумя потребителями не требует памяти Закрытие одного потребителя никогда не затрагивает общий источник На работу fan-out влияет только скорость более быстрого потребителя Нужны правила backpressure и ошибок: медленный выход влияет на источник

Ответьте на все 30 вопросов, чтобы получить результат

🔗 Встроить тест на свой сайт (iframe) ▼

Скопируйте код и вставьте в любое место на вашем сайте:

Также доступна прямая ссылка на embed-страницу