Аллокация Buffer в Node.js: пулы и безопасность памяти¶

Источник: theNodeBook — Buffer Allocation Patterns

Аллокация Buffer в Node.js определяет, получите ли вы диапазон байт с нулевой инициализацией, из быстрого небезопасного пути или как копию уже существующих данных. Проблема обычно проявляется в коде, который утекает данными, создаёт слишком много короткоживущих буферов или платит за аллокацию больше ожидаемого. Практическое разделение такое: Buffer.alloc(), Buffer.allocUnsafe(), Buffer.from(), slab‑пулинг для части путей создания небольших буферов и отдельные backing store для крупных аллокаций.

Нулевая инициализация защищает границы данных и стоит CPU. Небезопасная аллокация убирает этот шаг и перекладывает ответственность на вызывающий код. Пулинг снижает churn нативных аллокаций для маленьких буферов. В продакшене обычно выбирают alloc() для секретов и внешнего ввода, а allocUnsafe() оставляют для путей, где каждый байт перезаписывается сразу после выделения.

Как работает аллокация Buffer в Node.js¶

Кратко — для нетерпеливых¶

Если вы уже понимаете, что такое Buffer, перейдём к практике. Допустим, сервис либо утекает секретами, либо тормозит из‑за того, как выделяются буферы. Как найти причину?

Есть три основных способа попасть в эту ловушку — у каждого свой сценарий катастрофы.

Buffer.alloc(size) — медленный, но безопасный вариант по умолчанию. Node запрашивает память и сразу записывает нули в каждый байт. Вы гарантированно не увидите старые чувствительные данные из других частей системы. Цена — zero‑filling. В плотном цикле на горячем пути это может стать главным CPU‑узким местом, закрепить сервис на 100% загрузки и обрушить throughput. Используйте по умолчанию и меняйте выбор только когда профайлер покажет, что именно эта строка — проблема.
Buffer.allocUnsafe(size) пропускает инициализацию памяти. Очень быстро: берётся кусок памяти «как есть». В «мусоре» могут оказаться фрагменты session token другого пользователя, учётные данные БД, PII или API‑ключи. Если не немедленно перезаписать каждый байт, вы активно утекаете данные — в лог, по сокету, в кэш. Скрытая уязвимость. Думать об этом стоит только когда доказано, что Buffer.alloc() слишком медленен, и есть функция, которая заполнит буфер целиком — например fs.readSync.
Buffer.from(source) перегружена. Поведение и профиль производительности сильно зависят от аргумента. Строка — трата CPU на кодирование. Массив чисел — поэлементное копирование. Другой Buffer — полная копия. Но для части базовой памяти вроде .buffer у ArrayBuffer может создаться view на ту же память, а не копия. Исходные данные меняются — «неизменяемый» буфер тихо портится. Buffer.from() легко приводит к тонким багам целостности данных, которые в продакшене почти невозможно отловить.

Итого: начинайте с alloc(). allocUnsafe() — только когда профайлер заставит и вы гарантируете полную немедленную перезапись. Трижды проверяйте, что передаёте в from() — удобство скрывает опасную сложность.

Вы утекли пароли в неинициализированной памяти¶

Конкретный сбой делает риск осязаемым.

Поздняя ночь, дедлайн, тестировщик из другого часового пояса заводит срочный тикет: пользователь скачал PDF счёта, файл повреждён. В «битых» данных — фрагмент, похожий на API‑ключ другого пользователя. Списываете на глюк клиента, вручную перегенерируете счёт, пытаетесь уснуть.

Не получается. Настораживает именно «API‑ключ».

Смотрите логи запроса. Ошибка не там, где ждали: downstream ругается на malformed request. В логированном payload исходящего запроса — каша. JSON со счётом начинается нормально, дальше мусор. И в мусоре явно: ...","line_items": [...], "total": 19.99}} ... bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9... — JWT из чужого запроса, вшитый в payload счёта.

Трассируете путь от генерации счёта до вызова API. HTML → PDF stream → буфер → отправка. Находите строку создания буфера:

const payloadBuffer = Buffer.allocUnsafe(estimatedSize);

Buffer.allocUnsafe. «Unsafe» здесь не «может бросить ошибку», а «содержит неинициализированную память». OS отдала адрес, который только что использовал другой обработчик — без очистки. Там ещё лежал JWT аутентифицированного запроса другого пользователя.

estimatedSize посчитан неверно — с запасом. Валидные данные счёта записаны в начало, хвост буфера не перезаписан. Отправлен и залогирован весь буфер: ваши данные плюс чужие секреты.

Поиск по логам на bearer и password — десятки совпадений. Утечки фрагментов секретов месяцами, с момента «оптимизации производительности». Каждый allocUnsafe без полной записи — недетерминированная утечка. Сегодня она проявилась. Это не баг, а полноценный инцидент безопасности из одной непонятой строки.

Архитектура памяти Buffer¶

Прежде чем разбирать инцидент, — как Node.js вообще работает с памятью. Обычно вспоминают heap V8: объекты, строки, функции, GC.

Buffer — особый случай. Бинарные данные, часто большие объёмы. Засовывать мегабайты в heap V8 неэффективно и давит на GC. V8 заточен под множество мелких связанных JS‑объектов, а не монолитные бинарные blob.

Node.js делает иначе. Экземпляр Buffer в JavaScript — небольшой объект на heap V8, указатель/handle. Сами байты лежат вне heap V8 — в off‑heap памяти, которую Node запрашивает у OS через C++ core.

При const buf = Buffer.alloc(1000):

C++‑сторона Node просит у OS 1000 байт.
OS находит свободный блок и отдаёт адрес.
C++ оборачивает этот адрес.
В JavaScript создаётся маленький объект Buffer с length и внутренней ссылкой на off‑heap адрес.

Разделение важно для производительности. В JS вы передаёте маленький объект heap, а не гигантский blob. Биндинги fs, net и др. работают с off‑heap напрямую, без постоянного копирования между мирами JS и C++.

Проверка:

// Выделяем 50 МБ off-heap.
const bigBuffer = Buffer.alloc(50 * 1024 * 1024);

console.log(process.memoryUsage());

Пример вывода:

{
    "rss": 39845888,
    "heapTotal": 5341184,
    "heapUsed": 3638280,
    "external": 53790468,
    "arrayBuffers": 52439315
}

Сравните heapUsed и external: heap ~3,64 МБ, external ~53 МБ — off‑heap в действии.

Отсюда и опасность allocUnsafe. Память под объекты V8 при создании обнуляется. Off‑heap у Node ближе к «железу». При allocUnsafe Node отдаёт указатель без очистки. Аллокатор при освобождении часто не затирает байты — только помечает блок доступным. Вы получаете то, что было до этого. Это архитектурная основа рисков безопасности.

Когда программа освобождает память, аллокатор нередко выдаёт тот же блок снова без обнуления. Небезопасные пути Buffer могут получить такие переиспользованные байты; маленькие pooled‑аллокации могут сидеть в неинициализированном slab. OS обнуляет память при маппинге в другой процесс, но не обязана чистить память при переработке внутри вашего процесса.

`Buffer.alloc()`¶

Buffer.alloc(size) — функция на 99% случаев. Безопасный default: предсказуемо и защищённо. Два шага:

Allocation — запрос off‑heap блока размера size.
Zero-filling — запись 0x00 в каждый байт.

Буфер чистый: без хвостов прошлых операций, секретов и мусора.

const buf = Buffer.alloc(10);

console.log(buf);
// <Buffer 00 00 00 00 00 00 00 00 00 00>

Сколько ни запускайте — всегда нули. Можно писать данные, зная исходное состояние.

Цена — zero-filling: внизу memset(0). Для мелких буферов это шум. Для крупных или тысяч аллокаций в цикле — узкое место.

Загадочный скачок CPU¶

Сервис обработки изображений: resize, сохранение. Недели всё ок. На пике — алерты CPU 95–100%, latency взлетает, таймауты.

CPU‑профиль. Ожидаете sharp — а hottest path внутри Node.js, из одного места в коде:

function processChunk(chunk) {
    const workBuffer = Buffer.alloc(chunk.length);
    chunk.copy(workBuffer);
    // ... watermark ...
}

Тысячи чанков в секунду — тысячи zero-filled буферов. CPU пишет нули; обработка изображения голодает.

Компромисс Buffer.alloc(): безопасность за CPU. В типичном веб‑API сеть и БД затмят аллокацию. В стриминге, real-time и нашем image‑сервисе — может стать главным bottleneck.

Пишете CPU/data‑интенсивное на Node.js — остановитесь. Есть инструменты под задачу. Node отлично для I/O и event-driven нагрузки; тяжёлые вычисления — Rust, Go, C++ или отдельный сервис. Не обязаны всё делать на одном языке.

Разработчик «оптимизирует» на Buffer.allocUnsafe() — и меняет проблему производительности на катастрофу безопасности.

`Buffer.allocUnsafe()`¶

Именно эта функция чаще всего ведёт в беду. Buffer.allocUnsafe(size) запрашивает память, как alloc, но без zero-filling. Сырой сегмент — быстрее, меньше работы.

Насколько быстрее — цифры ниже; на больших размерах разница может быть на порядок. «Умная» оптимизация → инциденты вроде истории с JWT.

Два параллельных запроса:

Запрос A (пользователь 1):

function handleUpdate(req, res) {
    const userSession = {
        userId: 123,
        role: 'admin',
        token: '...',
    };
    const sessionBuffer = Buffer.from(
        JSON.stringify(userSession)
    );
    // ...
}

Запрос B (пользователь 2):

function handleReport(req, res) {
    const reportBuffer = Buffer.allocUnsafe(1024);

    const reportData = generateReportData(); // 500 байт
    reportData.copy(reportBuffer, 0);

    // 524 байта не инициализированы!
    res.send(reportBuffer);
}

Если B сразу после A переиспользует тот же слот памяти, отчёт пользователю 2: 500 байт данных + 524 байта хвоста — возможно, admin token пользователя 1.

Когда allocUnsafe допустим? Одно правило: сразу после аллокации вы гарантированно перезапишете каждый байт от 0 до size - 1.

Чтение файла:

const fs = require('node:fs');

const fd = fs.openSync('script.js', 'r');
const size = fs.fstatSync(fd).size;

// БЕЗОПАСНО: fs.readSync заполнит буфер целиком.
const buf = Buffer.allocUnsafe(size);
const bytesRead = fs.readSync(fd, buf, 0, size, 0);

Если пугает переиспользование через пул, можно allocUnsafeSlow() — не использует внутренний pool.

readSync заполняет буфер с диска от начала до конца; окно экспозиции неинициализированных данных минимально. Валидный и быстрый allocUnsafe.

Любая логика — if, цикл с ранним выходом, ошибка — между allocUnsafe и полной перезаписью создаёт уязвимость. Не «если», а «когда» это взорвётся.

`Buffer.from()`¶

На первый взгляд — самая удобная фабрика: строка, массив, другой Buffer, ArrayBuffer. Удобство — сила и ловушка. В отличие от alloc/allocUnsafe, речь о интерпретации и копировании данных — с тонкими последствиями для производительности и целостности.

`Buffer.from(string, [encoding])`¶

const buf = Buffer.from('hello world', 'utf8');
// <Buffer 68 65 6c 6c 6f 20 77 6f 72 6c 64>

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

`Buffer.from(buffer)`¶

Полная копия:

const buf1 = Buffer.from('learn_node');
const buf2 = Buffer.from(buf1);

buf2[0] = 0x6e;

console.log(buf1.toString()); // learn_node
console.log(buf2.toString()); // nearn_node

Безопасно и предсказуемо; копирование больших буферов — дорого.

`Buffer.from(array)`¶

const buf = Buffer.from([0x48, 0x69, 0x21]);

Удобно для констант; для больших массивов — медленно (обход JS‑массива).

`Buffer.from(arrayBuffer)` — самый коварный¶

Buffer.from(arrayBuffer) может создать view на ту же память, а не копию.

Сервис загрузки файлов:

const arrayBuffer = getUploadAsArrayBuffer();

// Может НЕ быть копией — общая память с arrayBuffer!
const headerBuffer = Buffer.from(arrayBuffer, 0, 16);

sanitizeFileInMemory(arrayBuffer);

Сначала заголовок читается как JPEG. Параллельно sanitizeFileInMemory меняет arrayBuffer — и headerBuffer тихо портится. Нет ошибок, только «иногда не работает». Дни на погоню за race condition, а корень — copy vs shared view.

Последовательность:

Проверка заголовка PNG, запуск async (права в БД).
Пока ждём БД, event loop берёт sanitizeFileInMemory(arrayBuffer).
Санитайзер затирает байт 10 — headerBuffer видит другие данные.
Запрос к БД завершился — чтение размеров из испорченного заголовка.

Классическая гонка на shared memory; при отладке тайминг меняется — баг исчезает.

Правило: внешний ArrayBuffer, нужна стабильность — явная копия через Buffer.alloc() и .copy(), а не надежда на Buffer.from():

const arrayBuffer = getUploadAsArrayBuffer();

const headerBuffer = Buffer.alloc(16);
const sourceView = Buffer.from(arrayBuffer, 0, 16);
sourceView.copy(headerBuffer);

sanitizeFileInMemory(arrayBuffer); // headerBuffer уже изолирован

Пулинг Buffer и порог 4 КБ¶

allocUnsafe отдаёт память со «старыми» байтами — обычно из вашего процесса: прошлый Buffer, нативная аллокация, строка, crypto, парсер, addon.

Плюс внутренний Buffer pool. По умолчанию Buffer.poolSize = 8192 байт. Node держит slab и режет его для быстрого создания части маленьких буферов. Быстрый pooled‑путь — до половины пула: при default ~4096 байт (в доках — половина Buffer.poolSize).

Buffer.allocUnsafe(100) берёт 100 байт из slab. То же для мелких Buffer.from(string), Buffer.from(array), результатов Buffer.concat(). Buffer.alloc() — безопасный путь: инициализированная память, без внутреннего пула.

Важно:

Buffer.alloc(100) и Buffer.allocUnsafe(100).fill(0) на уровне JS оба «нулевые», но пути разные. alloc(100) создаёт инициализированное хранилище напрямую. allocUnsafe(100).fill(0) может сначала взять slice из пула, потом залить нули — pool‑поведение уже зафиксировано.

const a = Buffer.alloc(100);
const b = Buffer.allocUnsafe(100);

console.log(a.buffer.byteLength); // 100
console.log(b.buffer.byteLength); // обычно 8192 — view в общий slab

Пул прост: offset в текущем slab, view с текущей позиции, выравнивание, новый slab при нехватке места. Это не free-list: когда 100‑байтовый Buffer становится unreachable, те же 100 байт в slab не сразу помечаются свободными.

Slab — неинициализированная память; новый slab может прийти из переиспользованных регионов процесса. Маленький Buffer удерживает весь slab. Пулинг снижает churn, но мелкие буферы делят один большой ArrayBuffer.

Связь с безопасностью — утечка JWT с правильным путём:

Запрос 1: буфер сессии в slab или отдельном backing store.
Запрос завершён, объект unreachable; байты не затираются GC.
Запрос 2: Buffer.allocUnsafe(500).
Node отдаёт диапазон из slab или свежего backing store со старым содержимым.
Записана только часть — хвост отдаёт прежние байты.

Утечка: чтение/отправка диапазона до того, как вы владеете содержимым каждого байта.

Buffer.poolSize менять в продакшене почти никогда не стоит — привязка к низкоуровневой детали, GC, аллокатору.

Скучное правило: мелкий unsafe быстр, потому что Node не плодит backing store; unsafe, потому что байты отдаются до очистки. Buffer.alloc() покупает инициализацию. Пул — для быстрых путей, не для safe default.

Замеры производительности¶

Разница между alloc и allocUnsafe — не шёпот, а обрыв. Бенчмарк: 10 000 аллокаций заданного размера (код в духе examples/buffer-allocation-patterns/benchmark.js у автора оригинала).

const { performance } = require('node:perf_hooks');

const ITERATIONS = 10000;

function benchmark(name, size, allocFn) {
    const start = performance.now();
    for (let i = 0; i < ITERATIONS; i++) {
        allocFn(size);
    }
    const end = performance.now();
    console.log(
        `- ${name}(${size}) x ${ITERATIONS}: ${(
            end - start
        ).toFixed(2)}ms`
    );
}

console.log('--- Benchmarking Buffer Allocation ---');
console.log(
    `(Iterations: ${ITERATIONS}, Node.js: ${process.version})`
);

console.log('\nScenario 1: Small Allocations (100 bytes)');
benchmark('Buffer.alloc', 100, (s) => Buffer.alloc(s));
benchmark('Buffer.allocUnsafe', 100, (s) =>
    Buffer.allocUnsafe(s)
);

console.log(
    '\nScenario 2: Medium Allocations (10KB, non-pooled)'
);
const mediumSize = 10 * 1024;
benchmark('Buffer.alloc', mediumSize, (s) =>
    Buffer.alloc(s)
);
benchmark('Buffer.allocUnsafe', mediumSize, (s) =>
    Buffer.allocUnsafe(s)
);

console.log(
    '\nScenario 3: Large Allocations (1MB, non-pooled)'
);
const largeSize = 1024 * 1024;
benchmark('Buffer.alloc', largeSize, (s) =>
    Buffer.alloc(s)
);
benchmark('Buffer.allocUnsafe', largeSize, (s) =>
    Buffer.allocUnsafe(s)
);

console.log('\n--- Benchmarking Buffer.from ---');

const largeString = 'a'.repeat(largeSize);
const existingLargeBuffer = Buffer.alloc(largeSize);

let start = performance.now();
Buffer.from(largeString, 'utf8');
let end = performance.now();
console.log(
    `- Buffer.from(1MB string): ${(end - start).toFixed(
        2
    )}ms`
);

start = performance.now();
Buffer.from(existingLargeBuffer);
end = performance.now();
console.log(
    `- Buffer.from(1MB buffer, copy): ${(
        end - start
    ).toFixed(2)}ms`
);

Сценарий 1 — мелкие аллокации (100 байт)¶

- Buffer.alloc(100) x 10000: 3.11ms
- Buffer.allocUnsafe(100) x 10000: 1.23ms

allocUnsafe ~в 2,5 раза быстрее: slice из пула vs инициализированные байты вне пула.

Сценарий 2 — средние (10 КБ)¶

Выше pooled fast path — отдельные backing store:

- Buffer.alloc(10240) x 10000: 9.65ms
- Buffer.allocUnsafe(10240) x 10000: 12.84ms

Здесь allocUnsafe медленнее (~1,3×): overhead malloc и прочее на этой системе.

Сценарий 3 — крупные (1 МБ)¶

- Buffer.alloc(1048576) x 10000: 1151.15ms
- Buffer.allocUnsafe(1048576) x 10000: 988.47ms

allocUnsafe ~1,2× быстрее — но 1151 ms на одни аллокации из‑за zero-fill — огромная цена в latency запроса.

Когда профайлер показывает 80% CPU в Buffer.alloc(), ускорение 1,2× соблазняет. Платите не CPU, а риском безопасности.

Производительность `Buffer.from()`¶

- Buffer.from(1MB string): 1.42ms
- Buffer.from(1MB buffer, copy): 0.24ms

Строка — UTF‑8 + копия. Копия существующего буфера — оптимизированный memcpy.

Модель решений: мелкий размер — разница часто шум; крупный — думать; горячий путь с тысячами вызовов — считать. Единственный надёжный способ — профиль под реальной нагрузкой.

Безопасность и векторы атак¶

Помимо утечки через allocUnsafe — более широкий ландшафт.

Прямое раскрытие информации¶

Ответ, файл, лог с данными другого пользователя или системы:

session tokens, API keys, JWT
пароли, хэши, соли в transit
credentials БД
PII
ключи шифрования
фрагменты TLS‑сертификатов и private keys

Уязвимость: Buffer.allocUnsafe(size) и логика, не перезаписавшая весь буфер — неверный размер, ранний return, try...catch с частично заполненным буфером в логе.

Утечка криптоматериала¶

Ключи, nonce, plaintext/ciphertext в буферах. Обычный unsafe для JSON может содержать байты от прошлой crypto‑работы. Повторные триггеры — сбор фрагментов со временем.

DoS через `Buffer.from()`¶

const body = JSON.parse(req.body);
const dataBuffer = Buffer.from(body.data, 'base64');

Маленький payload → огромный буфер после decode. Лимит длины строки до Buffer.from().

Timing attacks¶

В crypto‑контексте время alloc() растёт с размером (zero-fill); pooled allocUnsafe — быстрее. Теоретически — утечка длины секрета по времени ответа.

На практике шум (планировщик OS, сеть, contention) делает это edge case для crypto‑кода, не для типичных HTTP‑handler'ов. Но вектор существует.

Защита: данные из allocUnsafe — недоверенные, пока не перезаписали сами. Code review: «докажите полную перезапись на всех путях до чтения/отправки?» Нет — Buffer.alloc().

Мелкие pooled allocUnsafe() — почти O(1) slice. При исчерпании пула — новый slab/OS, рост стоимости. allocUnsafeSlow() пул не использует. «Константное» время — для pooled/small; при новом slab поведение меняется.

Фрагментация памяти и давление на GC¶

Если вы постоянно боретесь с allocUnsafe() ради производительности, крутите тяжёлую бинарную обработку или CPU‑bound пайплайны — возможно, не тот инструмент. Node силён в тысячах concurrent I/O и оркестрации. CPU‑bound работа блокирует единственный event loop.

Видео, real-time image, сжатие, crypto на больших данных — Rust, Go, C++: контроль памяти, настоящий параллелизм, меньше пауз GC. Тяжёлое — в native addon или WASM; Node — HTTP и бизнес‑логика. Пользователям не важен «весь стек на JS» — важны скорость и надёжность.

Каждый Buffer — маленький объект на heap V8 плюс off-heap данные. Тысячи буферов в секунду — churn для GC.

Давление на сборщик мусора¶

Типичный антипаттерн стримингового парсера:

let internalBuffer = Buffer.alloc(0);

function handleData(chunk) {
    internalBuffer = Buffer.concat([internalBuffer, chunk]);
}

Buffer.concat каждый раз: новый буфер, копия обоих, выброс старого. 100 чанков → 100 аллокаций и 99 копий. Лучше один большой буфер и указатель (отдельная тема) — но стратегия аллокации важна не меньше функции.

Фрагментация памяти¶

Хуже для буферов выше pooled path (~4 КБ для API с пулом) и для любого размера при Buffer.alloc() (инициализированный путь).

Упрощённая картина:

A: 1 МБ
B: 2 МБ
C: 1 МБ → [A][B][C]
Освободили B → [A][пусто 2МБ][C]

2 МБ свободно, но запрос на 3 МБ не влезает contiguous — фрагментация. rss растёт при стабильных heapUsed + external.

Частый Buffer.alloc(largeSize) — драйвер фрагментации. Пулинг — защита для мелких аллокаций.

При росте rss без роста активной памяти — арены: несколько огромных буферов на старте и ручное управление внутри них.

Платформы и поведение аллокатора¶

Node абстрагирует OS, но malloc/jemalloc/glibc/musl влияют на performance и содержимое unsafe‑буферов.

На dev macOS вы можете не увидеть секретов; в Alpine Linux в контейнере — другое. Не экстраполируйте тесты в прод.

Относительное «alloc медленнее, unsafe быстрее» держится; абсолютные цифры — нет. Node на jemalloc vs glibc — микрооптимизация, на гипермасштабе заметна.

Пул Node (8 КБ slab) поверх системного аллокатора; эффективность slab стабильна, запросы slab к OS — по‑разному.

Вывод: здоровый паранойя. Контракт allocUnsafe — неинициализированная память, вы отвечаете за очистку — на всех платформах, даже если «призраки» в памяти различаются.

Framework решений для продакшена¶

Чеклист при наборе Buffer.:

По умолчанию — `Buffer.alloc()`¶

Вопрос: выделяете буфер?
Ответ: Buffer.alloc(size).

Без микрооптимизаций. Correctness и security. Сеть, диск, БД, бизнес‑логика на порядки медленнее zero-fill. allocUnsafe здесь — преждевременная оптимизация с риском.

Доказательства¶

Не отходите от шага 1 без доказательства bottleneck.

Доказательство: CPU profile (0x, встроенный профайлер Node, APM), где заметное время в Buffer.alloc() на конкретной строке.

Без профиля — дальше нельзя. «Кажется быстрее» — не аргумент.

Если `alloc()` доказанно узкое место — `allocUnsafe()`¶

Вопрос: сразу после Buffer.allocUnsafe(size) следующие операции безусловно и полностью перезапишут байты 0…size-1?

«Безусловно» — без веток/циклов/try...catch, оставляющих часть буфера читаемой раньше.

Хорошо: fs.readSync на полный размер; buf.fill() сразу после аллокации.
Плохо: цикл пишет 500 из 1024 байт; try...catch с логом частично заполненного буфера.

Не выполняете условие — allocUnsafe не решение; пересмотрите алгоритм, стримы, один work buffer.

`Buffer.from()`¶

Строка, массив, другой Buffer — обычно Buffer.from(), с учётом копирования/транскодирования.
Чужой ArrayBuffer — осторожно; стабильная копия: Buffer.alloc() + .copy(). Не полагайтесь на копию по умолчанию.

Миграция и безопасные defaults¶

Аудит:

new Buffer() — удалить везде. Поведение смешивало unsafe и from. Deprecation warning в runtime.
Buffer.allocUnsafe — для каждого вхождения framework выше.

Миграции:

// ДО — утечка неинициализированной памяти
const unsafeBuf = new Buffer(1024);

// ПОСЛЕ
const safeBuf = Buffer.alloc(1024);

allocUnsafe → alloc, если безопасность не доказана. Цена — performance; альтернатива — меньше аллокаций, не unsafe.

const oldWay = new Buffer('hello', 'utf8');
const newWay = Buffer.from('hello', 'utf8');

ESLint: node/no-deprecated-api для new Buffer(). Кастомное правило на allocUnsafe + eslint-disable-next-line только с обоснованием в комментарии.

Шпаргалка best practices¶

По умолчанию всегда Buffer.alloc().
allocUnsafe только с CPU profile, где bottleneck — alloc.
allocUnsafe — немедленная синхронная полная перезапись всего буфера.
Удалить все new Buffer().
Подозрительно относиться к Buffer.from(ArrayBuffer) — явная копия через alloc + copy.
Линтить опасные паттерны.
Избегать «болтливых» аллокаций на hot path (Buffer.concat в цикле).
Комментировать оправданный unsafe со ссылкой на профайлер.

// allocUnsafe оправдан: ~30% CPU на Buffer.alloc под нагрузкой.
// Буфер полностью перезаписывается fs.readSync.
const buf = Buffer.allocUnsafe(fileSize);
fs.readSync(fd, buf, 0, fileSize, 0);

Заключение¶

Выбор между alloc, allocUnsafe и from — контракт функции и потребности кода с сильным уклоном в безопасность. Скорость allocUnsafe соблазнительна; цена ошибки — утечка данных.

У вас есть архитектура памяти, замеры и framework. Профилируйте, жёстко ревьюьте unsafe, по умолчанию — safe path.

Связанное чтение¶

Предыдущая: What Is a Buffer in Node.js
Далее: Node.js Buffer Operations

Аллокация Buffer в Node.js: пулы и безопасность памяти¶

Как работает аллокация Buffer в Node.js¶

Кратко — для нетерпеливых¶

Вы утекли пароли в неинициализированной памяти¶

Архитектура памяти Buffer¶

Buffer.alloc()¶

Загадочный скачок CPU¶

Buffer.allocUnsafe()¶

Buffer.from()¶

Buffer.from(string, [encoding])¶

Buffer.from(buffer)¶

Buffer.from(array)¶

Buffer.from(arrayBuffer) — самый коварный¶

Пулинг Buffer и порог 4 КБ¶

Замеры производительности¶

Сценарий 1 — мелкие аллокации (100 байт)¶

Сценарий 2 — средние (10 КБ)¶

Сценарий 3 — крупные (1 МБ)¶

Производительность Buffer.from()¶

Безопасность и векторы атак¶

Прямое раскрытие информации¶

Утечка криптоматериала¶

DoS через Buffer.from()¶

Timing attacks¶

Фрагментация памяти и давление на GC¶

Давление на сборщик мусора¶

Фрагментация памяти¶

Платформы и поведение аллокатора¶

Framework решений для продакшена¶

По умолчанию — Buffer.alloc()¶

Доказательства¶

Если alloc() доказанно узкое место — allocUnsafe()¶

Buffer.from()¶

Миграция и безопасные defaults¶

Шпаргалка best practices¶

Заключение¶

Связанное чтение¶

Комментарии

`Buffer.alloc()`¶

`Buffer.allocUnsafe()`¶

`Buffer.from()`¶

`Buffer.from(string, [encoding])`¶

`Buffer.from(buffer)`¶

`Buffer.from(array)`¶

`Buffer.from(arrayBuffer)` — самый коварный¶

Производительность `Buffer.from()`¶

DoS через `Buffer.from()`¶

По умолчанию — `Buffer.alloc()`¶

Если `alloc()` доказанно узкое место — `allocUnsafe()`¶

`Buffer.from()`¶