Какой capacity будет у неинициализированного слайса после вставки одного элемента?

Отличный и довольно коварный вопрос, который проверяет понимание внутренней механики слайсов в Go.

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

После вставки одного элемента в неинициализированный слайс (равный nil), его capacity (ёмкость) будет равна 1.

Подробное объяснение

1. Что такое неинициализированный слайс?

Неинициализированный слайс — это переменная типа []T, которой не было присвоено значение с помощью литерала слайса ([]int{1, 2}), функции make() или среза от существующего массива/слайса. Его нулевое значение — nil.

var s []int // s == nil, len(s) == 0, cap(s) == 0
fmt.Println(s == nil) // true

2. Механика операции append

Встроенная функция append — это ключевой игрок. Она спроектирована для работы с nil-слайсами "из коробки". Логика её работы при добавлении элемента включает проверку, достаточно ли в текущем подлежащем массиве (underlying array) места.

• Если cap >= len + newElements, элемент добавляется в существующий массив, len увеличивается, cap остаётся прежним.
• Если места недостаточно (cap < len + newElements), происходит аллокация нового массива, копирование туда старых элементов и добавление новых. Размер нового массива определяется внутренним алгоритмом роста.

3. Алгоритм роста и случай с nil-слайсом

Точный алгоритм роста может незначительно меняться между версиями Go, но его логика для случая с нулевой ёмкостью (cap == 0) закреплена. Когда append вызывается для nil-слайса (или любого слайса с cap == 0), он аллоцирует новый массив.

Правило для первого выделения памяти:

1. Если требуемая ёмкость (len + numNewElements) больше текущей ёмкости, запускается алгоритм роста.
2. Для слайса с cap == 0 (наш случай), новая ёмкость вычисляется как максимум между требуемой ёмкостью и числом, зависящим от размера элемента. В современных версиях Go (1.18+) это значение — минимум 8 для типов размером меньше байта, иначе — требуемая ёмкость, округлённая вверх до степени двойки для мелких слайсов, но с важным нюансом для самого первого добавления.

Ключевой нюанс: Для nil-слайса или пустого слайса, созданного через make([]T, 0), при добавлении ровно одного элемента ёмкость нового массива будет установлена ровно в 1, если только это не очень крупный элемент. Это сделано для оптимизации памяти и избежания избыточного выделения.

4. Практическая демонстрация

package main

import "fmt"

func main() {
    var nilSlice []int // Неинициализированный, nil слайс
    fmt.Printf("До append: len=%d, cap=%d, is nil=%v\n", len(nilSlice), cap(nilSlice), nilSlice == nil)

    nilSlice = append(nilSlice, 42) // Вставка одного элемента

    fmt.Printf("После append одного элемента: len=%d, cap=%d, is nil=%v\n", len(nilSlice), cap(nilSlice), nilSlice == nil)
    fmt.Println("Содержимое:", nilSlice)

    // Для сравнения: поведение с более чем одним элементом
    var anotherNilSlice []int
    anotherNilSlice = append(anotherNilSlice, 1, 2, 3, 4) // Вставка 4 элементов
    fmt.Printf("\nПосле append 4-х элементов в nil слайс: len=%d, cap=%d\n", len(anotherNilSlice), cap(anotherNilSlice))
    // Здесь capacity, скорее всего, будет 4 (ровно столько, сколько нужно).
    // При дальнейших добавлениях начнёт работать стандартный алгоритм роста (удвоение или 1.25x).
}

Вывод этой программы будет примерно таким:

До append: len=0, cap=0, is nil=true
После append одного элемента: len=1, cap=1, is nil=false
Содержимое: [42]

После append 4-х элементов в nil слайс: len=4, cap=4

Итог и важные следствия

1. capacity станет равным 1 после append первого элемента к nil-слайсу. Это поведение гарантировано для эффективности.
2. Слайс перестаёт быть nil. Теперь это валидный слайс, указывающий на аллоцированный массив из одного элемента.
3. Если вы заранее знаете, что слайс будет содержать N элементов, всегда эффективнее инициализировать его через make([]T, 0, N) с нужной capacity. Это предотвратит множественные переаллокации при последующих вызовах append.
4. append — это единственный корректный способ "инициализировать" nil-слайс данными. Попытка присвоить элемент по индексу s[0] = 1 вызовет панику.

Понимание этой механики критически важно для написания производительного Go-кода, так как частые переаллокации из-за непредсказуемого роста capacity могут стать узким местом.