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

Если при append текущей вместимости среза недостаточно, Go выделяет новый backing array, копирует в него элементы и продолжает работу с ним. Старый массив становится недоступным после потери ссылок и впоследствии может быть освобождён сборщиком мусора. Поэтому неконтролируемый рост среза увеличивает число аллокаций, объём копирования и нагрузку на GC.

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

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

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

Когда места в backing array не хватает, реализация увеличивает его вместимость и переносит данные. Конкретная стратегия роста является деталью реализации и не должна рассматриваться как гарантированный постоянный коэффициент.

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

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

Неверная оценка последствий приводит к росту CPU из-за копирования, дополнительным пикам потребления памяти и появлению временных старых массивов, которые GC должен обнаружить и обработать. При больших элементах стоимость копирования особенно заметна; если элементы содержат указатели, работа GC с такими массивами тоже может быть существенной.

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

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

Если capacity недостаточно, создаётся другой массив с большей вместимостью. Элементы старого массива копируются в новый, а возвращённый срез начинает ссылаться на новый массив. Старый массив не освобождается немедленно: он становится кандидатом на сборку только после того, как из программы исчезнут все ссылки на него.

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

package main

import "fmt"

func main() {
    values := make([]int, 0, 1000)
    for i := 0; i < 1000; i++ {
        values = append(values, i)
    }
    fmt.Println(len(values), cap(values))
}

Здесь capacity заранее рассчитана на ожидаемое число элементов, поэтому обычный путь заполнения не требует промежуточных расширений backing array. Сам вызов make всё равно выделяет память под зарезервированный массив, даже если фактически будут использованы не все элементы.

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

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

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

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

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

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

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

Всегда ли append выделяет новый массив при достижении текущей длины?

Нет. Длина и вместимость — разные характеристики. Если len меньше cap, добавление может использовать уже выделенное место. Новая аллокация нужна только тогда, когда требуемая длина превышает доступную capacity; при этом сам append может вернуть срез с другой backing array, поэтому результат append следует использовать как возвращаемое значение.
Гарантирует ли заданная capacity отсутствие любых дальнейших аллокаций?

Нет. Она предотвращает расширения только пока фактическая длина не превышает зарезервированный предел. Если рост продолжается, произойдёт очередное расширение. Кроме того, другие операции программы могут отдельно выделять память, поэтому одна предварительная аллокация не гарантирует отсутствие аллокаций во всей операции.
Почему чрезмерное предварительное резервирование может ухудшить производительность, даже если оно уменьшает число расширений?

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