Стек

У каждой горутины свой стек (стартует с 2 КБ в Go 1.4+ и растёт удвоением до maxstacksize, по умолчанию 1 ГБ на 64-битных). Память под кадр функции резервируется в прологе одним вычитанием из указателя стека, освобождается в эпилоге одним сложением. Списков свободных блоков, поиска подходящего размера и блокировок здесь нет: стек не разделяется между горутинами. Данные кадра почти наверняка горячие в L1: адреса, к которым только что обращались.

Куча

Куча одна на процесс и устроена как TCMalloc. Путь аллокации: mcache (локальный кэш текущего P, без блокировок) → mcentral (общий на размерный класс, наборы спанов в нём lock-free) → mheap (страницы, глобальный лок) → mmap у ОС. Объекты раскладываются по 67 размерным классам до 32 КБ, всё крупнее идёт как large object напрямую из mheap (под него отведён нулевой класс, поэтому в исходниках NumSizeClasses = 68). Плюс tiny-аллокатор: несколько объектов меньше 16 байт без указателей упаковываются в один блок. Свежая деталь на добивку: с Go 1.27 мелкие аллокации (до 80 байт) идут через процедуры, специализированные по размерному классу на этапе компиляции, и это экономит до 30 % на самом горячем пути аллокатора.

Что где оказывается

• Всегда на стеке: аргументы, возвращаемые значения (часто вообще в регистрах благодаря register ABI с Go 1.17) и локальные переменные, если компилятор доказал их «неутечку». Параметр, чей адрес убегает, компилятор переносит в кучу, как и локальную переменную.
• Всегда в куче: глобальные переменные (технически они в сегменте данных, но сканируются как корни), всё, на что ссылаются из кучи, всё непрозрачного размера, кроме мелочи: с Go 1.25 слайс переменного размера до 32 байт остаётся на стеке.
• Решает компилятор: всё остальное, этим и занимается escape analysis. При этом new() и &T{} не гарантируют кучу, а литерал структуры не гарантирует стек.

Почему «дешевле» - по пунктам

1. Выделение: одна арифметическая операция против mallocgc с поиском размерного класса, проверкой кэша и (иногда) с уходом в mcentral. С Go 1.27 этот разрыв немного сократился: для объектов до 80 байт компилятор подставляет процедуру, специализированную под конкретный размерный класс, и мелкая аллокация дешевеет до 30 % (ценой ~60 КБ размера бинаря).
2. Освобождение: бесплатно и мгновенно, против отложенной работы sweeper-а.
3. Работа GC: стек сканируется один раз за цикл целиком, объекты в куче обходятся по графу.
4. Локальность: кадры лежат подряд, объекты в куче разбросаны, отсюда больше промахов кэша.

Формально компилятор строит граф «кто на кого может ссылаться»: вершины - переменные и аллокации, рёбра - присваивания с весом derefs (число разыменований минус взятий адреса). Затем ищет пути, по которым адрес попадает в кучу или переживает свою переменную. Для каждой функции получается сводка по параметрам, которая уезжает в export data пакета, поэтому анализ работает и через границы пакетов. Отсюда строки вида leaking param: name в выводе -m.

Правила побега (в порядке частоты)

1. Возврат указателя на локальную переменную, например return &User{}. Ссылка по определению живёт дольше кадра.
2. Запись указателя в объект, который сам в куче: global = &x, s = append(s, &x), obj.F = &x. Рантайм держит инвариант: из кучи нельзя ссылаться на стек, иначе перемещение стека всё сломает.
3. Упаковка в интерфейс: fmt.Println(x), var a any = x. Интерфейс хранит указатель на данные, а метод вызывается непрозрачно, значит, компилятор обязан считать, что данные утекают. Исключение бывает, когда компилятор девиртуализует вызов и видит тело.
4. Захват замыканием, которое переживает функцию, как в go func(){ use(x) }() или return func(){...}. Объект-замыкание уезжает в кучу; мелкие неизменяемые переменные копируются в него, а те, что замыкание меняет, переезжают в кучу отдельно.
5. Отправка в канал (ch <- &x): читатель сидит на другом стеке.
6. Неизвестный на компиляции размер: make([]byte, n) с переменной n, make(map[K]V, n). В кадре нельзя зарезервировать «сколько-нибудь», поэтому на стеке есть только запас на мелкий случай: 32 байта у слайса (с Go 1.25), одна группа на 8 элементов у мапы.
7. Слишком большой объект. У компилятора есть лимиты: 128 КБ (до Go 1.24 было 10 МБ) для явных локальных переменных и 64 КБ для неявных аллокаций (new, &T{}, литералы, make с константой).
8. Непрозрачный вызов через переменную-функцию или интерфейс: тела не видно, поэтому считаем, что параметры утекают. Рекурсия к этому не относится: рекурсивные функции компилятор анализирует вместе и видит их тела, так что параметры вполне могут не утекать.

func a() *int   { x := 1; return &x }        // moved to heap: x
func b()        { x := 1; sink = &x }        // moved to heap: x
func c(v int)   { fmt.Println(v) }            // v escapes to heap (интерфейс)
func d() func() { x := 1; return func(){ x++ } } // moved to heap: x + func literal escapes to heap
func e(n int)   { _ = make([]byte, n) }       // does not escape: до 32 байт на стеке (Go 1.25+), больше - куча
func f()        { _ = make([]byte, 4096) }    // does not escape: константа, влезает в кадр
func g(p *T)    { p.X = 1 }                   // p does not escape: только читаем/пишем поля

// go build -gcflags="-m -l", вывод go1.27 дословно:
//   ./m.go:9:19: moved to heap: x
//   ./m.go:10:19: moved to heap: x
//   ./m.go:11:30: ... argument does not escape
//   ./m.go:11:31: v escapes to heap
//   ./m.go:12:19: moved to heap: x
//   ./m.go:12:34: func literal escapes to heap
//   ./m.go:13:27: make([]byte, n) does not escape
//   ./m.go:14:27: make([]byte, 4096) does not escape
//   ./m.go:15:8: p does not escape
//
// Про e(): «does not escape» тут значит только «указатель наружу не
// уходит». Размер n на компиляции неизвестен, кадр под него заранее
// не зарезервируешь. С Go 1.25 компилятор держит на стеке буфер в 32 байта
// и идёт в кучу, только если n больше. Целиком на стеке живёт f() с константой.
// Проверено на go1.27: e(16) - 0 аллокаций, e(64) - одна.

$ go build -gcflags="-m" ./...            # свои пакеты
$ go build -gcflags="-m -m" ./...         # с цепочкой причин
$ go build -gcflags="all=-m" ./...        # включая зависимости
$ go build -gcflags="-m -l" ./pkg         # без инлайна
$ go test -gcflags="-m" -bench=. ./pkg    # то же для бенчей
$ go build -gcflags="-m" ./... 2>&1 | grep 'escapes to heap' | sort | uniq -c | sort -rn

Что читать в выводе

Чем добить

Одного -m мало: он показывает решения, а не стоимость. В пару к нему берут:

• go test -bench=. -benchmem покажет allocs/op и B/op, то есть сколько это стоит на самом деле.
• go build -gcflags="-m=2" эквивалентен -m -m.
• -gcflags="-d=ssa/check_bce/debug=1" найдёт, где остались проверки границ.
• go tool pprof -alloc_objects ответит, кто реально аллоцирует в проде, а не в теории.

Приёмы, которые реально работают

1. Отдавать буфер снаружи. func F(dst []byte, ...) []byte вместо func F(...) []byte. Так устроены strconv.AppendInt, time.Time.AppendFormat, fmt.Appendf (Go 1.19).
2. Принимать указатель на результат вместо возврата указателя: func Parse(b []byte, out *Msg) error.
3. Не пропускать значение через any в горячем пути: fmt.Sprintf боксит каждый аргумент. Вместо него бери strconv, strings.Builder, дженерики (для типов с одинаковой GC-формой инстанцирование не создаёт интерфейс).
4. Ограничить область жизни: не сохранять указатель в глобальную структуру «на всякий случай», не передавать в горутину то, что можно передать копией.
5. Константные размеры: make([]byte, 4096) остаётся на стеке, а make([]byte, n) больше 32 байт нет. Иногда помогает верхняя граница: var buf [256]byte; b := buf[:n] при n <= 256.

Чего делать не надо

• Для оптимизации Go-кода //go:noescape не годится. Это обещание компилятору про ассемблерную функцию (объявленную без тела), что она не сохраняет переданные указатели. Если соврать, при перемещении стека память испортится.
• sync.Pool не отменяет побег: объект по-прежнему в куче, он просто переиспользуется.
• unsafe ради «оставить на стеке» почти всегда хуже аллокации, которую ты пытался убрать.

Три силы

1. Стоимость копии. С Go 1.17 на amd64 (с Go 1.18 и на arm64) работает register-based ABI: на amd64 9 целочисленных регистров и 15 float-регистров под аргументы и результаты, на arm64 по 16. Структура из 2–4 машинных слов возвращается вообще без записи в память.
2. Стоимость аллокации. Возврат *T из функции почти всегда заканчивается строкой escapes to heap, а за ней стоят mallocgc и будущая работа сборщика.
3. Стоимость для GC потом. Слайс []T из структур без указателей помечен как noscan и не сканируется вообще. []*T на миллион элементов даёт сборщику миллион объектов, которые он обходит каждый цикл. Разница тут на порядки, и она важнее копий.

type Point struct {
    X, Y float64
}   // 16 байт, noscan

// хорошо: возврат в регистрах, аллокаций 0
func Mid(a, b Point) Point { return Point{(a.X+b.X)/2, (a.Y+b.Y)/2} }

// плохо в горячем пути: что ни вызов, то mallocgc и работа GC
func MidPtr(a, b *Point) *Point { return &Point{...} }

// а ещё важнее, как хранить:
pts := make([]Point,  1_000_000)  // 1 объект, спан noscan, GC его не обходит
ptr := make([]*Point, 1_000_000)  // 1_000_001 объект, каждый цикл GC обходит миллион

Механика

1. Пролог почти каждой функции сравнивает SP с полем stackguard0 в структуре g. Проверка занимает пару инструкций, ветка предсказуемая.
2. Места не хватило: вызывается runtime.morestack, горутина попадает в newstack.
3. Выделяется новый блок как минимум вдвое большего размера (стеки берутся из пулов по размерам: 2, 4, 8, 16 КБ и дальше из mheap).
4. memmove копирует старые кадры в новый блок.
5. Рантайм проходит по кадрам, по stack maps находит все слоты-указатели и прибавляет дельту к тем, что указывали внутрь старого стека. Плюс правит указатели в defer-записях и в g.
6. Старый блок освобождается, выполнение продолжается с того же места.

Сжатие тоже есть: если при сканировании стека в фазе маркировки занято меньше четверти, рантайм может скопировать стек в блок вдвое меньше (shrinkstack). Верхний предел задаёт runtime/debug.SetMaxStack, по умолчанию 1 ГБ на 64 битах; превысишь его и получишь fatal error: stack overflow (это не паника, её не поймать).

Почему это возможно в Go и невозможно в C

В Go указатели точно типизированы, а адресной арифметики нет. Компилятор для каждой точки вызова знает, какие слоты кадра содержат указатели, и записывает это в метаданные, так что рантайм может найти и переписать каждую ссылку. В C указатель неотличим от long: «починить» его невозможно, поэтому размер стека фиксируется заранее (типично 8 МБ на поток), а переместить его нельзя. Отсюда прямое следствие: миллион горутин по 2 КБ реален, а миллион потоков по 8 МБ нет.