Краткий ответ

Для среза с большой вместимостью Go обычно сразу создаёт backing array, даже если его длина равна нулю. Поэтому память резервируется под cap, а не под len; фактическое добавление нескольких элементов не отменяет стоимости уже созданного буфера.

Исключения связаны с оптимизациями компилятора, нулевым размером элемента и особенностями виртуальной памяти. Поэтому точный физический объём RSS может отличаться от логического размера аллокации, но большая вместимость всё равно увеличивает требования к памяти процесса и может влиять на GC.

Исторический контекст

Срезы отделяют логическое количество элементов от выделенного хранилища. Параметр len показывает доступную часть данных, а cap позволяет заранее подготовить место для роста и уменьшить число перераспределений при последовательном append.

Такой подход решает проблему частых аллокаций и копирований при наращивании коллекции. Компромисс состоит в том, что завышенная оценка будущего размера превращает оптимизацию числа аллокаций в избыточное потребление памяти.

Постановка проблемы

Нулевая длина часто ошибочно воспринимается как отсутствие затрат. Если вместимость велика, backing array уже существует; последующие записи используют его, не создавая новую память до исчерпания capacity.

Неверно выбранная вместимость особенно опасна в обработчиках запросов, кэшах и очередях. При большом числе одновременно живущих срезов это приводит к высокому heap-прожиточному минимуму, более раннему запуску GC и риску резкого роста RSS.

Подробное решение

При создании среза Go хранит указатель на backing array, длину и вместимость. Для обычного элемента ненулевого размера запрос вместимости N означает подготовку хранилища примерно под N * sizeof(T) с учётом выравнивания и внутренних накладных расходов.

package main

import "runtime"

func build() []byte {
    b := make([]byte, 0, 1_000_000)
    b = append(b, 1, 2, 3)
    return b
}

func main() {
    b := build()
    runtime.KeepAlive(b)
}

В примере len равен 3, но backing array рассчитан примерно на миллион байт. Возврат среза делает буфер живым для вызывающего кода, поэтому его память нельзя считать временной только из-за маленькой длины.

Выделение может быть выполнено на стеке, если escape analysis докажет, что срез и его backing array не покидают область действия. Если срез возвращается, сохраняется в долгоживущем объекте или передаётся туда, где компилятор не может доказать безопасность, backing array обычно оказывается в куче. Это не меняет различие между len и cap, но влияет на стоимость конкретной аллокации.

Физическое выделение также не всегда немедленно равно росту RSS на весь объём: операционная система может лениво отображать страницы. Однако виртуальное адресное пространство, размер heap Go и будущая работа сборщика всё равно могут увеличиться. Для элементов-указателей backing array содержит указательные слоты; сборщик учитывает объект целиком, а не только диапазон до len, поэтому большая неиспользуемая capacity может увеличивать объём сканируемой памяти.

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

Ситуация из практики

В HTTP-сервисе каждый запрос создавал срез с capacity около миллиона элементов, хотя почти все запросы возвращали несколько сотен. В профиле памяти было видно много одновременно живущих backing array, а после увеличения параллелизма выросли heap и частота GC.

Рассматривались три варианта. Полностью убрать предварительное резервирование было просто, но увеличивало копирования для редких больших ответов. Всегда оставлять большую capacity хорошо работало для крупных ответов, но создавало высокий минимум памяти. Выбранным решением стало использовать небольшую базовую capacity, отдельно ограничивать максимальный размер и применять специальный путь для действительно больших результатов.

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

Что кандидаты часто упускают

Достаточно ли len == 0, чтобы backing array не был выделен?

Нет. make с нулевой длиной и положительной capacity обычно создаёт backing array под указанную вместимость для элементов ненулевого размера. len лишь запрещает обращение к элементам за границами текущего логического диапазона; он не отменяет уже подготовленное хранилище.

При нулевой capacity backing array для практических целей отсутствует, и первый append должен организовать место. Для типов нулевого размера объём данных не растёт пропорционально capacity, потому что такие элементы не занимают байты, поэтому это отдельное исключение из интуитивного правила.

Учитывает ли GC только элементы до len?

Нет, полагаться на это нельзя. Если backing array выделен, он достижим через указатель среза, а информация о расположении указателей задаётся типом объекта. Для массива элементов-указателей сборщик обычно сканирует соответствующие слоты всего выделенного объекта, включая область за текущей длиной.

Записи за len недоступны корректным обычным операциям среза и при создании обычно нулевые, но сама большая capacity всё равно может увеличивать объём памяти, который нужно просматривать. Поэтому чрезмерная capacity особенно нежелательна для срезов структур с указательными полями.

Гарантирует ли большая capacity размещение backing array в куче?

Нет. Решение о стеке или куче принимает escape analysis, а не значение capacity само по себе. Если срез целиком локален и компилятор может доказать отсутствие выхода из функции, небольшая или даже заметная аллокация может быть размещена на стеке либо оптимизирована.

Если срез возвращается, сохраняется в куче или передаётся через непрозрачный для анализа путь, backing array обычно становится heap-объектом. На практике это проверяют по диагностике компилятора и профилю, а не выводят только из текста make.