Срез в Go: три слова, общий массив и рост запаса не по тому правилу, которое все помнят

Три слова

unsafe.Sizeof([]int{})   // 24 — указатель, длина, запас
unsafe.Sizeof([8]int{})  // 64 — а это массив, он хранит элементы

Массив — значение и копируется целиком. Срез — ссылка: 24 байта на любую длину.

Заголовок копируется, массив — нет

Первое следствие из трёх слов.

func grow(s []int) { s = append(s, 42) }   // снаружи не видно
func set(s []int)  { s[0] = 7 }            // видно

Функция получила копию трёх слов. Указатель тот же — запись проходит. Новая длина осталась в копии. Отсюда правило s = append(s, x).

Общий массив

Массив общий — осталось выяснить, докуда.

a := []int{1, 2, 3, 4, 5}
b := append(a[:2], 9)
// b = [1 2 9]
// a = [1 2 9 4 5]   <- затёрто

У a[:2] длина 2, а запас 5 — он считается до конца массива, а не до конца среза. append увидел свободную ячейку и записал в неё. Ошибки нет: он сделал ровно то, что обещано.

Тот же вызов при исчерпанном запасе выделит новый массив и ничего не тронет. По коду в точке вызова это не видно.

Как это чинить

b := a[:2:2]    // третий индекс ограничивает ЗАПАС: длина 2, запас 2
b = append(b, 9)
// a = [1 2 3 4 5]  — цел

Запаса нет — append обязан выделить свой массив. Так отдают наружу кусок своего буфера.

Рост запаса

Расхожее «вдвое до 1024, дальше в 1,25 раза» описывает рантайм до Go 1.18. Сейчас в runtime/slice.go стоит const threshold = 256, а формула после порога — newcap += (newcap + 3*threshold) >> 2.

Замеренные отношения для []int: 1,656 → 1,509 → 1,400 → 1,429 → 1,331 → 1,502. Не 1,25 и даже не монотонно — потому что результат формулы округляется вверх до ближайшего класса размера: аллокатор Go выдаёт блоки не любого размера, а из фиксированного набора (8, 16, 24, 32, 48, 64, … 2688), и набор задан в байтах.

Нагляднее всего на срезе структур по 40 байт: cap идёт 32 → 67 → 134 → 272, а дальше 544 → 1024 → 1638. Число 67 никто не заказывал: формула попросила 64 элемента, то есть 2560 байт, ближайший класс — 2688, в него влезает 67 штук по 40.

Что это стоит

Собрать []int из 10 000:

• без запаса — 19 выделений, 357 624 байта;
• make([]int, 0, N) — 1 выделение, 81 920 байт.

Полезных данных 80 000 байт. Остальное — промежуточные массивы.

Три способа заказать запас (make(…, 0, N), make(…, N), slices.Grow) между собой неразличимы. Важно, что запас заказан вообще.

Ещё две строки оттуда же:

• copy — 1 668 нс, ручной цикл — 6 163 на тех же данных;
• range по значению — 32 028 нс, по индексу — 6 206 (срез структур по 136 байт; на []int разницы нет).

Утечка через подсрез

срез из 10 байт от массива в 50 МБ:            в куче 50,1 МБ
после copy в свой массив и отказа от подсреза: в куче  0,1 МБ

Сборщик работает с массивом целиком. Возвращаете маленький кусок большого буфера — возвращайте копию (slices.Clone).

nil и пустой

var n []int      // n == nil,  json -> null
e := []int{}     // e != nil,  json -> []

Для len, range, append они неразличимы, и if s == nil почти всегда лишняя проверка — нужна if len(s) == 0. Разница вылезает в сериализации: клиент, ждущий массив, получит null.

Три слова

Описатель — это буквально структура из трёх полей, и её размер можно спросить у компилятора:

unsafe.Sizeof([]int{})   // 24 — указатель, длина, запас
unsafe.Sizeof("")        // 16 — у строки полей два
unsafe.Sizeof([8]int{})  // 64 — а это массив, он хранит элементы

Массив в Go — значение: [8]int занимает 64 байта и копируется целиком. Срез — ссылка: 24 байта, сколько бы элементов ни было за ними. Отсюда и следствие, которое спецификация тоже называет прямо:

Заголовок копируется, массив — нет

Первое следствие из трёх слов — и самое частое место, где на нём спотыкаются. Копируются именно три слова, а не массив за ними.

func grow(s []int) { s = append(s, 42) }   // снаружи не видно
func set(s []int)  { s[0] = 7 }            // снаружи видно

Функция получила копию из трёх слов. Указатель в копии тот же, поэтому запись в существующий элемент проходит в общий массив. А новая длина осталась в копии и умерла вместе с ней.

Причём элемент записан: если у среза был запас, 42 лежит в массиве, просто за пределами длины. Вызовите grow для s := make([]int, 3, 8) — и s[:cap(s)][3] покажет там 42, хотя len(s) по-прежнему 3. Именно поэтому правило звучит как s = append(s, x), а не «не забудьте указатель»: указатель тут ни при чём, дело в длине.

Запас считается до конца массива

Итак, массив общий. Осталось выяснить, докуда именно он общий, — и вот здесь находится место, о которое спотыкаются чаще всего.

b := a[:2] даёт длину 2 — это очевидно. Но запас у b равен 5, а не 2:

То есть запас считается до конца массива, а не до конца среза: cap(a) равен 5, low равен нулю. Между длиной 2 и запасом 5 остаются три ячейки, которые для b свободны, а для a — заняты. Дальше остаётся прочитать, что делает append:

Слово «иначе» здесь и есть вся история:

a := []int{1, 2, 3, 4, 5}
b := append(a[:2], 9)
// b = [1 2 9]
// a = [1 2 9 4 5]   <- третий элемент затёрт

Ошибки не произошло. append сделал ровно то, что обещано: увидел свободную ячейку и записал в неё.

Самое неприятное — что тот же вызов ведёт себя иначе, когда запаса нет.

c := []int{1, 2}
d := append(c, 9)   // запаса нет -> новый массив, c не тронут

Один и тот же append: в первом случае два среза делят массив, во втором — нет. По коду в точке вызова это не видно, потому что зависит не от кода, а от того, каким срез был получен.

Как отдать кусок и не бояться

Для этого есть трёхиндексная форма. Спецификация про неё говорит коротко:

b := a[:2:2]   // длина 2, запас 2
b = append(b, 9)
// a = [1 2 3 4 5]  — не тронут

Третий индекс ограничивает запас, а не длину. Запаса нет — append обязан выделить новый массив.

Это единственный способ отдать наружу кусок своего буфера, ничего не копируя: не попросить не дописывать, а сделать дописывание в ваш массив физически невозможным. Копия — второй способ, и она защищает от большего; чем именно эти два отличаются, разобрано в следующем разделе.

Clip и Clone: что из них от чего защищает

Трёхиндексную форму не обязательно писать руками: в стандартной библиотеке она лежит под именем slices.Clip, а рядом с ней — slices.Clone. Обе функции коротки настолько, что их тела и есть ответ:

// Clip removes unused capacity from the slice, returning s[:len(s):len(s)].
func Clip[S ~[]E, E any](s S) S {
	return s[:len(s):len(s)]
}
 
// Clone returns a copy of the slice.
func Clone[S ~[]E, E any](s S) S {
	if s == nil {
		return nil
	}
	return append(S{}, s...)
}

Clip — это ровно выражение из предыдущего раздела и ни одного копирования. Clone — это append в пустой срез, то есть копирование всегда. Отсюда различие, которое путают чаще всего (bench/goslice/clip.go):

Clip(head) и buf делят: ТОТ ЖЕ массив   <- Clip НЕ копирует
Clone(head) и buf делят: другой массив  <- Clone копирует сразу

Clip защищает от одного и только одного: append больше не залезет в чужой хвост.

buf ПОСЛЕ append(head,99) len=5 cap=5 [1 2 3 99 5]
buf ПОСЛЕ append(Clip(head),99) len=5 cap=5 [1 2 3 4 5]

В первой строке append затёр чужой элемент, во второй массив цел: Clip заставил append выделить свой.

От записи по индексу он не защищает вовсе — массив-то тот же:

buf после clipped[0]=777 len=5 cap=5 [777 2 3 4 5]
buf после cloned[0]=777  len=5 cap=5 [1 2 3 4 5]

И — это прямо про раздел ниже, где маленький срез держит большой массив, — Clip не отпускает массив. Срез длины 3 от массива в 1 048 576 элементов после Clip имеет запас 3, а массив держит целиком: указатель остался тем же. Против удержания памяти работает Clone, и только он.

Правило, которое стоит унести: Clip — про append, Clone — про собственность. nil при этом переживает обе: у Clone под это отведена отдельная ветка с пометкой авторов Preserve nilness in case it matters (сохранить nil-ность на случай, если это важно).

Общий массив — это общая память

До сих пор общий массив разбирался в одной горутине. Стоит добавить вторую — и тот же самый факт перестаёт быть неожиданным результатом и становится гонкой данных.

Всё, что выше сказано про общий массив, в однопоточной программе даёт неожиданный результат. В многопоточной — гонку данных, причём ни один индекс при этом не выглядит подозрительно. Два случая, и оба ломаются на пустом месте (bench/goslice/race_shared.go):

• buf[0:4] и buf[2:6] — диапазоны перехлёстываются, a[2] и b[0] — это одна и та же ячейка;
• два среза len=1 cap=8 от одного массива — оба append пишут в buf[1], то есть в общий запас.

Второй злее: общего индекса в коде нет вовсе, общее — ровно то, чего в исходнике не видно.

Детектор находит оба и называет обе стороны. Адреса и номера горутин от запуска к запуску меняются, порядок двух строф — тоже; неизменны строки исходника:

WARNING: DATA RACE
Write at 0x00c0000a6010 by goroutine 8:
  main.overlap.func2()
      .../racesrc/main.go:73
Previous write at 0x00c0000a6010 by goroutine 7:
  main.overlap.func1()
      .../racesrc/main.go:67

Код возврата при этом 66, а не 1 или 2 — отдельное значение, заданное именно под гонку:

Мьютекс здесь — не лечение, а полумера. В первом случае он гонку уберёт. Во втором под замком останется потерянная запись: два append по очереди положат своё в один и тот же buf[1], и второй затрёт первый — детектор замолчит, а данные пропадут. Лечит нарезка: развести диапазоны (buf[0:4] и buf[4:8]) или отобрать запас через slices.Clip, чтобы каждый append выделил своё. На обоих починенных вариантах детектор молчит.

Молчание, впрочем, не доказательство:

Рост запаса

Про запас до сих пор говорилось только то, что он есть и докуда тянется. Теперь — откуда он берётся.

Расхожее правило здесь неверно дважды — и в пороге, и в множителе.

Расхожая формулировка — «вдвое до 1024 элементов, дальше в 1,25 раза». Она описывает рантайм до Go 1.18. Сейчас в runtime/slice.go стоит:

if newLen > doublecap {
	return newLen
}
 
const threshold = 256
if oldCap < threshold {
	return doublecap
}
for {
	newcap += (newcap + 3*threshold) >> 2
	...
}

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

Порог — 256, и сравнивается он с запасом, а не с длиной. Так его и меняли:

Но и «1,25» неверно — даже как описание нынешней формулы. Замеренные отношения для []int идут 1,656 → 1,509 → 1,400 → 1,429 → 1,331 → 1,502: не 1,25 и даже не монотонно. Причин две, и обе видны в исходнике.

Первая — сама формула. newcap += (newcap + 3*256) >> 2 — это не умножение на 1,25, а прибавление четверти плюс 192. К 1,25 отношение приближается только на больших значениях; на 512 оно даёт 1,625.

Вторая — округление. Аллокатор Go не выдаёт блоки произвольного размера: у него фиксированный набор — 8, 16, 24, 32, 48, 64, … 2048, 2304, 2688, — и запрос округляется вверх до ближайшего из них. Такой размер и называют классом размера. Результат формулы идёт в roundupsize, который округляет объём в байтах до ближайшего класса. Автор изменения предупредил об этом прямо в том же сообщении коммита:

То есть правило, сформулированное в элементах, не может быть точным в принципе: рантайм считает в байтах. Лучше всего это видно на срезе структур по 40 байт: cap идёт 32 → 67 → 134 → 272 → 544 → 1024 → 1638. Число 67 никто не заказывал: формула запросила 64 элемента, то есть 2560 байт; ближайший класс — 2688; в него влезает 67 элементов по 40 байт.

А у []int8 запас начинается не с 1, а с 8: меньше восьми байт аллокатор просто не выдаёт.

Что этот рост стоит

Собрать []int из 10 000 элементов:

• без запаса — 159 964 нс, 357 624 байта, 19 выделений;
• make([]int, 0, N) — 40 542 нс, 81 920 байт, 1 выделение.

Полезных данных здесь 80 000 байт. Всё, что сверх, — промежуточные массивы, которые пришлось выделить, скопировать и выбросить.

Обратите внимание, чего в этих числах нет: разницы между тремя способами заказать запас. make([]T, 0, N) с append, make([]T, N) с записью по индексу и slices.Grow дают одно и то же с точностью до разброса прогонов. Выбирать между ними по скорости не из чего — важно, что запас заказан вообще.

Ещё две строки из тех же замеров. Выделений в них нет ни одного — а разница есть:

• copy против ручного цикла — 1 668 нс против 6 163 на тех же 10 000 элементах. copy и append(dst[:0], src...) сводятся к одному и тому же memmove, а цикл копирует по восемь байт с проверкой границ.
• range по значению против range по индексу — 32 028 нс против 6 206 на срезе структур по 136 байт. Выделений нет ни там, ни там: вся пятикратная разница — копирование 136 байт на каждой итерации ради восьми нужных. На срезе []int этой разницы не существует.

Маленький срез держит большой массив

Сборщик мусора работает с массивом целиком. Пока жив хоть один срез, жив весь массив под ним:

срез из 10 байт от массива в 50 МБ:            в куче 50,1 МБ
после copy в свой массив и отказа от подсреза: в куче  0,1 МБ

Вторая строка требует обоих действий: копия сама по себе ничего не освобождает, пока жив подсрез, — а он и держит массив.

Это не оптимизация, а разница между работающим сервисом и утечкой. Функция вида «найти нужный кусок в прочитанном файле» возвращает подсрез — и держит весь файл, пока результат жив.

Официальное введение называет это прямо и предлагает то же лечение: вернуть копию, а не подсрез. slices.Clone делает это одной строкой.

nil и пустой

var n []int      // len 0, cap 0, n == nil,  указатель 0x0
e := []int{}     // len 0, cap 0, e != nil,  указатель ненулевой

У пустого среза указатель ненулевой, но памяти под него не выделено: он показывает на общий для всей программы нулевой объект.

Для len, range, append и copy они неразличимы — append к nil-срезу работает, диапазон по нему делает ноль итераций. Поэтому проверка if s == nil почти всегда лишняя, нужна if len(s) == 0.

Разница вылезает ровно в одном месте — в сериализации:

json.Marshal(n)   // null
json.Marshal(e)   // []

Клиент, который ждёт массив, получает null. Это единственная практическая причина различать их — и она про API, а не про Go.

Что стоит проверять в своём коде

• Возвращаете подсрез чужого буфера — ограничьте запас третьим индексом или верните копию.
• Знаете размер заранее — закажите запас. Не ради наносекунд, а ради выделений: их станет одно вместо девятнадцати.
• Держите маленький кусок большого массива — скопируйте его, иначе большой массив жив.
• Проходите диапазоном по срезу крупных структур — берите индекс, а не значение.
• Отдаёте срез в JSON — решите, null там уместен или [].
• Раздаёте куски одного массива в горутины — разведите диапазоны или отберите запас: общий массив под -race находится, а глазами нет.

Как воспроизвести числа

Времени не меряют вовсе три скрипта. bench/goslice/grow.go печатает адреса, длины, запас и размеры кучи. bench/goslice/clip.go сравнивает Clip и Clone по адресам массивов. bench/goslice/race_shared.go собирает под -race программу-спутник bench/goslice/racesrc/main.go — она и есть подопытный код — и печатает дословный ответ детектора. Все три запускаются из корня репозитория.

Замер цены — bench/goslice/cost_test.go, четыре блока. Это отдельный модуль Go, поэтому go test запускается из него:

go run bench/goslice/grow.go
go run bench/goslice/clip.go
go run bench/goslice/race_shared.go
cd bench/goslice
go test -run '^$' -bench . -benchmem .

Запускать с -benchmem, иначе не будет видно главного столбца.

Опубликованный прогон: go1.24.7 linux/amd64, Intel Xeon 2,80 ГГц, август 2026 года. Времена зависят от машины, а столбцы B/op и allocs/op — нет: они от прогона к прогону не менялись вовсе. Числа роста в grow.go считаются по шагам роста, а не по счётчику кучи, и потому воспроизводятся до байта; сверочный счёт по runtime.MemStats печатается рядом и как раз плавает — на то он и сверочный.